- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Tue, 27 Jan 2015 09:02:55 -0800
- To: Glenn Adams <glenn@skynav.com>
- Cc: David Singer <singer@apple.com>, TTWG <public-tt@w3.org>
Hi Glenn, Thanks for the pointer. The SMPTE liaison referenced in the ticker described "a mechanism to insert a variable amount of space in the middle of a rendered text string". Is the idea to use an empty <span> with tts:inlineLength/ipd equal to the desired amount of space? Why is the block progression attribute needed? Thanks, -- Pierre On Tue, Jan 27, 2015 at 8:46 AM, Glenn Adams <glenn@skynav.com> wrote: > > On Tue, Jan 27, 2015 at 9:38 AM, Pierre-Anthony Lemieux <pal@sandflow.com> > wrote: >> >> > tts:{ipd,bpd} are used to specify constraints on the dimensions of areas >> > generated by content elements >> >> This is in addition to region height/width, or instead, or something else? >> >> Is there a ticket related to this feature? > > > not a new feature: just a name change from what was introduced as the > solution for ISSUE-237 [1] > > [1] http://www.w3.org/AudioVideo/TT/tracker/issues/237 > >> >> >> Best, >> >> -- Pierre >> >> On Tue, Jan 27, 2015 at 8:12 AM, Glenn Adams <glenn@skynav.com> wrote: >> > ipd = inline progression dimension >> > bpd = block progression dimension >> > >> > they are the writing mode relative counterparts to width and height; the >> > problem with the latter is that they are strongly associated with >> > absolute >> > axes (horizontal and vertical), while the former {ipd,bpd} don't suffer >> > from >> > that association >> > >> > it also requires less spec text and results in less confusion in the >> > spec, >> > since in all places at present (except for line height), width and >> > height >> > are interpreted in an absolute sense independent of writing mode >> > >> > tts:{ipd,bpd} are used to specify constraints on the dimensions of areas >> > generated by content elements >> > >> > On Tue, Jan 27, 2015 at 7:37 AM, David Singer <singer@apple.com> wrote: >> >> >> >> yikes >> >> >> >> it’s nice if the terms are readable. Linewidth and Lineheight have >> >> some … >> >> recognition, albeit mostly in writing systems that use horizontal lines >> >> assembled into vertical blocks. >> >> >> >> ipd and bpd are directions, not measurements, aren’t they? and they >> >> don’t >> >> exactly roll off the tongue or leap to mind in terms of recognizability >> >> >> >> > On Jan 26, 2015, at 1:01 , Glenn Adams <glenn@skynav.com> wrote: >> >> > >> >> > The use of width and height as writing mode relative properties is >> >> > confusing. Change their names to ipd and bpd, abbreviations for >> >> > inline >> >> > progression dimension and block progression dimension, respectively, >> >> > and >> >> > document convention that width and height (as well as horizontal and >> >> > vertical) are always absolute and not writing mode relative. The only >> >> > exception being that 'height' in lineHeight remains writing mode >> >> > relative, >> >> > i.e., specifies the nominal bpd of a line area. >> >> > >> >> > Change image to use tts:extent instead of the former >> >> > tts:{width,height} >> >> > in order to use absolute axes in expressing explicit image >> >> > dimensions. >> >> > >> >> > Addressed above comments in [1]. >> >> > >> >> > [1] https://dvcs.w3.org/hg/ttml/rev/69877acd9380 >> >> >> >> David Singer >> >> Manager, Software Standards, Apple Inc. >> >> >> >> >> > > >
Received on Tuesday, 27 January 2015 17:03:47 UTC