W3C home > Mailing lists > Public > public-tt@w3.org > January 2015

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

From: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Tue, 27 Jan 2015 09:02:55 -0800
Message-ID: <CAF_7JxA_1pJe+Lz1rPOa0ZhE298R26L3_F7BTFi=CL1RzAiqVA@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: David Singer <singer@apple.com>, TTWG <public-tt@w3.org>
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".

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

Why is the block progression attribute needed?

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:03:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:20 UTC