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

these terms {inline progression dimension, block progression dimension} are
well established, at least in the XSL-FO domain, and we use them 20 times
in the TTML1 spec;

if folks don't like the abbreviated names, I can expand to the full names,
which would end up being

tts:inlineProgressionDimension
tts:blockProgressionDimension

i don't want to rename them due to their existing usage and presence of
formal definitions, as that may lead to further confusion

the abbreviated names seemed a good compromise to me; given they will be
used only infrequently, authors should be able to handle this usage


On Tue, Jan 27, 2015 at 9:34 AM, David Singer <singer@apple.com> wrote:

>
> > On Jan 27, 2015, at 17:12 , Glenn Adams <glenn@skynav.com> wrote:
> >
> > ipd = inline progression dimension
> > bpd = block progression dimension
>
> ah, sorry, I thought d = direction.
>
> >
> > 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
>
> OK, but what is wrong with something a little less terse, such as
> inlineLength and stackingLength?
>
> >
> > 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.
> >
> >
> >
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>