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

Oops - got that wrong... I meant bpd... Not ipd! (In fact it looks like I invented my own TLA when I wrote ibd.)

LetterSpacing would work for ipd.

Apologies for any confusion.

Best,
John


From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Tuesday, January 27, 2015 06:26 PM
To: John Birch
Cc: pal@sandflow.com <pal@sandflow.com>; singer@apple.com <singer@apple.com>; public-tt@w3.org <public-tt@w3.org>
Subject: Re: [TTML2] tts:{width,height} rename



On Tue, Jan 27, 2015 at 11:21 AM, John Birch <John.Birch@screensystems.tv<mailto: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.


But my memory may be faulty...

Best regards,
John

From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: Tuesday, January 27, 2015 06:11 PM
To: Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>>
Cc: David Singer <singer@apple.com<mailto:singer@apple.com>>; TTWG <public-tt@w3.org<mailto: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<mailto: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<mailto:glenn@skynav.com>> wrote:
>
>
> On Tue, Jan 27, 2015 at 10:33 AM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>> wrote:
>> >
>> >
>> > On Tue, Jan 27, 2015 at 10:17 AM, Pierre-Anthony Lemieux
>> > <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>> wrote:
>> >> >
>> >> > On Tue, Jan 27, 2015 at 10:02 AM, Pierre-Anthony Lemieux
>> >> > <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>>
>> >> >> wrote:
>> >> >> >
>> >> >> > On Tue, Jan 27, 2015 at 9:38 AM, Pierre-Anthony Lemieux
>> >> >> > <pal@sandflow.com<mailto: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<mailto: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<mailto: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<mailto: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<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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

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

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<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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

P Before printing, think about the environment