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

> that is a special case of the specified feature

The mechanism specified in the SMPTE liaison allows for negative
dimensions and notes "Negative values shall be allowed but should be
used with care as characters could overlap."

The proposed tts:inlineLength/ipd does not allow negative dimensions.

Also, if tts:inlineLength/ipd is intended to add/substract space in
the inline progression, how would it work on <div>, which is in block
progression?

Thanks,

-- Pierre

On Tue, Jan 27, 2015 at 9:06 AM, Glenn Adams <glenn@skynav.com> wrote:
>
> 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.
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>

Received on Tuesday, 27 January 2015 17:18:18 UTC