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

> correct; that use case (dubious at best) is not supported by this feature;

Well... this feature is presumably in use (ST 428-7 being in use
worldwide), so I do not think TTWG can reasonably call it dubious. If
TTWG has concerns/questions, TTWG should simply ask SMPTE. In the
meantime, I have reopened ticket #237.

>it specifies a fixed dimension in inline or block progression;

What does "inline dimensions" do for a <div>, which is in block progression?

Thanks,

-- Pierre

On Tue, Jan 27, 2015 at 9:28 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>
> On Tue, Jan 27, 2015 at 10:17 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>>
>> > 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.
>
>
> correct; that use case (dubious at best) is not supported by this feature;
> you could use negative letter spacing between glyphs as an alternative
>
>>
>>
>> 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?
>
>
> it doesn't add/subtract space; it specifies a fixed dimension in inline or
> block progression; it applies to all content elements;
>
>>
>>
>> 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:34:25 UTC