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

Most of the uses of "inline progression dimension" and "block progression dimension" refer to the axis or direction, not the length along it.

How about tts:inlineLength and tts:blockLength, being the length of the area in the inline progression dimension and the block progression dimension respectively?



From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Tuesday, 27 January 2015 16:42
To: "David (Standards) Singer" <singer@apple.com<mailto:singer@apple.com>>
Cc: TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: Re: [TTML2] tts:{width,height} rename
Resent-From: <public-tt@w3.org<mailto:public-tt@w3.org>>
Resent-Date: Tuesday, 27 January 2015 16:43

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<mailto:singer@apple.com>> wrote:

> On Jan 27, 2015, at 17:12 , Glenn Adams <glenn@skynav.com<mailto: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<mailto: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<mailto: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.