Re: [TTML2] tts:{width,height} rename

On Tue, Jan 27, 2015 at 10:02 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> 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".
>

that is a special case of the specified feature


>
> Is the idea to use an empty <span> with tts:inlineLength/ipd equal to
> the desired amount of space?
>

yes


>
> Why is the block progression attribute needed?
>

symmetry


>
> 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.
> >> >>
> >> >>
> >> >
> >
> >
>