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

On Tue, Jan 27, 2015 at 11:35 AM, Glenn Adams <glenn@skynav.com> wrote:

>
>
> On Tue, Jan 27, 2015 at 11:26 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>>
>>
>> On Tue, Jan 27, 2015 at 11:21 AM, John Birch <John.Birch@screensystems.tv
>> > wrote:
>>
>>>  IIRC negative space in SMPTE use case is for use predominantly in the
>>> ibd (!)... I.e. To impact upon line spacing by bringing lines of text
>>> closer than font metrics dictate.
>>>
>>
>> If that is the case, then the new tts:letterSpacing property should be
>> used with negative tracking to tighten the fit. Positive tracking can be
>> used to loosen the fit.
>>
>
> FYI, my reading of the initial request was for a way to insert an
> arbitrary fixed width space inline.
>
> "It shall be possible to introduce inline space of arbitrary linear
> dimension in the current progression direction. The space shall be
> expressed in units of em and shall be no less than -1 em. "
>
>
Note also that this does not state a requirement that negative space from 0
to 1em should be supported. It only says the dimension should be no less
than -1 em.


> It may be that this was just a poorly written description, and that what
> really was being asked for was letter spacing, but since that was requested
> explicitly in a separate issue 236 [2], I assumed this one was really
> asking for insertion of arbitrary (non-negative) inline space, as the title
> and description says.
>
> [2] http://www.w3.org/AudioVideo/TT/tracker/issues/236
>
>
>>
>>>
>>> But my memory may be faulty...
>>>
>>> Best regards,
>>> John
>>>
>>>  *From*: Glenn Adams [mailto:glenn@skynav.com]
>>> *Sent*: Tuesday, January 27, 2015 06:11 PM
>>> *To*: Pierre-Anthony Lemieux <pal@sandflow.com>
>>> *Cc*: David Singer <singer@apple.com>; TTWG <public-tt@w3.org>
>>> *Subject*: Re: [TTML2] tts:{width,height} rename
>>>
>>>
>>> On Tue, Jan 27, 2015 at 10:51 AM, Pierre-Anthony Lemieux <
>>> pal@sandflow.com> wrote:
>>>
>>>> > SMPTE needs to present a viable use case for such a feature
>>>>
>>>> The fact that this is a specification in use today should be
>>>> sufficient, a priori. In other words, ST 428-7 could be wrong, but I
>>>> would not assume that without clear evidence.
>>>>
>>>> > add a new issue specifically requesting negative space along with use
>>>> case documentation
>>>>
>>>> Hmmmm. the tts:{ipd,bpd} feature was proposed with the SMPTE liaison
>>>> as the sole documented requirement, but fails to meet it... so I do
>>>> not think closing the issue can be a reasonable course of action.
>>>>
>>>
>>>  I don't agree. The proposed feature handles insertion of fixed width
>>> space. That is the only requirement that I see as being viable here. I
>>> assume the opposite as you regarding negative space, i.e., that absent of
>>> proof of use it is a non-requirement.
>>>
>>>
>>>>
>>>> If TTWG has concerns/questions about this and other ST 428-7 features,
>>>> TTWG should simply collect them and ask for SMPTE's input. ITTWG can
>>>> incorporate SMPTE's feedback (if any) in its final disposition.
>>>>
>>>> Best,
>>>>
>>>> -- Pierre
>>>>
>>>> On Tue, Jan 27, 2015 at 9:38 AM, Glenn Adams <glenn@skynav.com> wrote:
>>>> >
>>>> >
>>>> > On Tue, Jan 27, 2015 at 10:33 AM, Pierre-Anthony Lemieux <
>>>> pal@sandflow.com>
>>>> > wrote:
>>>> >>
>>>> >> > 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.
>>>> >
>>>> >
>>>> > SMPTE needs to present a viable use case for such a feature before
>>>> I'll
>>>> > consider it; it would be better to leave 237 closed, and add a new
>>>> issue
>>>> > specifically requesting negative space along with use case
>>>> documentation
>>>> >
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> >it specifies a fixed dimension in inline or block progression;
>>>> >>
>>>> >> What does "inline dimensions" do for a <div>, which is in block
>>>> >> progression?
>>>> >
>>>> >
>>>> > every area generated by content elements has both inline and block
>>>> > progression dimensions; constraining the ipd of a div would constrain
>>>> it in
>>>> > the horizontal axis in a horizontal writing mode
>>>> >
>>>> >>
>>>> >>
>>>> >> 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.
>>>> >> >> >> >> >>
>>>> >> >> >> >> >>
>>>> >> >> >> >> >
>>>> >> >> >> >
>>>> >> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
>>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>> John.Birch@screensystems.tv | www.screensystems.tv |
>>> https://twitter.com/screensystems
>>>
>>>
>>> *Visit us at BVE, Excel London 24-26 February 2015 Stand No. N19*
>>> *For our HbbTV Products visit our specialist site: http://www.hbbtv.co
>>> <http://www.hbbtv.co> *
>>> P * Before printing, think about the environment*
>>>
>>>
>>>  This message may contain confidential and/or privileged information.
>>> If you are not the intended recipient you must not use, copy, disclose or
>>> take any action based on this message or any information herein. If you
>>> have received this message in error, please advise the sender immediately
>>> by reply e-mail and delete this message. Thank you for your cooperation.
>>> Screen Subtitling Systems Ltd. Registered in England No. 2596832.
>>> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
>>> Suffolk, IP6 0EQ
>>>     ­­
>>>
>>
>>
>