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

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. "

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
>>     ­­
>>
>
>