RE: Subtitle/caption styling + TTML + CSS

Hi both ☺

In a subtitling context w.r.t. multiRowAlign I would certainly anticipate explicit line breaks to set the length of the lines.
The ‘correct’ positioning of line breaks is an important part of subtitling… e.g.

http://bbc.github.io/subtitle-guidelines/#Line-breaks


best,
John

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>

Visit us at
BVE, Excel London, 28 Feb - 2 Mar, Booth N25

[http://www.subtitling.com]<http://www.subtitling.com/>  [https://www.linkedin.com/company/screen-subtitling-systems-ltd] <https://www.linkedin.com/company/screen-subtitling-systems-ltd>   [https://www.youtube.com/channel/Screen Subtitling Systems] <https://www.youtube.com/channel/UCBp2nyUeNbIFz9cD66Ym3AQ>   [https://twitter.com/ScreenSystems] <https://twitter.com/ScreenSystems>

[cid:BuyNowButtonBanner450x128_f51819c7-6de4-47de-8a98-b6f818ff5db0.jpg]<http://subtitling.com/products/subtitle-create/create/wincaps-q4-subtitling-software/>
P Before printing, think about the environment
From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 13 December 2016 02:09
To: Pierre-Anthony Lemieux <pal@sandflow.com>
Cc: public-tt@w3.org
Subject: Re: Subtitle/caption styling + TTML + CSS



On Mon, Dec 12, 2016 at 6:58 PM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>> wrote:
> for example, you might specify min-width: 50% and max-width: 80% to ensure that
> length of lines in the inline-block are more balanced (in length); i haven't actually
> tried this, but it sounds like it should work

I am not sure how this maps to multiRowAlign which AFAIK says "align
longest line against the region according to textAlign, and all other
lines against the longest line according to multiRowAlign".

but it doesn't say how to determine the longest line; and, in particular it doesn't say that the longest line must be the arrangement (of breakable units) that produces the maximum measure; so, e.g., an implementation could break as follows:

Hello
my
name
is
No
One

Hello my
name
is
No
One

Hello my name
is
No
One

Hello my name is
No
One

Hello my name is No
One

etc.

Given this, I think there may be insufficient reason to fault a mapping to inline-block. In other words, you may have to use <br> to obtain the breaks you want within the inner block.


On Mon, Dec 12, 2016 at 5:55 PM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
>
>
> On Mon, Dec 12, 2016 at 6:43 PM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>>
> wrote:
>>
>> > have you tried a combination of {min,max}-width on the span
>>
>> No. How would it work?
>
>
> for example, you might specify min-width: 50% and max-width: 80% to ensure
> that length of lines in the inline-block are more balanced (in length); i
> haven't actually tried this, but it sounds like it should work
>
>>
>>
>> > you probably should include references to these examples in your message
>> > to CSS; let's see what input they might have
>>
>> Ok.
>>
>> On Mon, Dec 12, 2016 at 5:26 PM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
>> >
>> >
>> > On Mon, Dec 12, 2016 at 6:11 PM, Pierre-Anthony Lemieux
>> > <pal@sandflow.com<mailto:pal@sandflow.com>>
>> > wrote:
>> >>
>> >> Hi Glenn,
>> >>
>> >> > since both of the examples you give, multiRowAlign and linePadding
>> >> >are in fact supported (semantically) by CSS.
>> >>
>> >> I am not so sure.
>> >>
>> >> >display: inline-block on span to obtain multiRowAlign semantics
>> >>
>> >> I have not found a way to make this work without explicit <br>
>> >> elements -- see [1].
>> >>
>> >> [1] https://codepen.io/palemieux/pen/yVxZWm

>> >
>> >
>> > have you tried a combination of {min,max}-width on the span
>> >
>> >>
>> >>
>> >>
>> >> >use box-decoration-break: clone to obtain linePadding semantics.
>> >>
>> >> I have not found a way to make this work if nested spans are used --
>> >> see [2] for HTML and attached for TTML. Specifically, linePadding
>> >> requires that the background of the first/last character of each line
>> >> be extended.
>> >>
>> >> - "box-decoration-break: clone" extends the background of the <span>
>> >> at the end of each line, so the background of both outer and inner
>> >> spans are extended.
>> >>
>> >> - CSS padding adds padding to both left and right of a span,
>> >> introducing additional spaces in the text
>> >>
>> >> [2] https://codepen.io/palemieux/pen/vyzbqW

>> >>
>> >> Perhaps you see another way. I would love to be proven wrong!
>> >
>> >
>> > hmm, you may have a counterexample here
>> >
>> > you probably should include references to these examples in your message
>> > to
>> > CSS; let's see what input they might have
>> >
>> >>
>> >>
>> >> Best,
>> >>
>> >> -- Pierre
>> >>
>> >> On Mon, Dec 12, 2016 at 4:12 PM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
>> >> > You are likely to receive pushback on your email, since both of the
>> >> > examples
>> >> > you give, multiRowAlign and linePadding, are in fact supported
>> >> > (semantically) by CSS.
>> >> >
>> >> > Use display: inline-block on span to obtain multiRowAlign semantics
>> >> > and
>> >> > use
>> >> > box-decoration-break: clone to obtain linePadding semantics.
>> >> >
>> >> > As far as I know, none of TTML1 or IMSC1 presentation semantics is
>> >> > not
>> >> > supported by some CSS mapping (whether simple or complex), but that
>> >> > doesn't
>> >> > hold for TTML2, where there are indeed some semantic gaps in CSS.
>> >> >
>> >> > On Mon, Dec 12, 2016 at 3:21 PM, Pierre-Anthony Lemieux
>> >> > <pal@sandflow.com<mailto:pal@sandflow.com>>
>> >> > wrote:
>> >> >>
>> >> >> FYI. My input to the www-style list re: TTML and CSS.
>> >> >>
>> >> >> Best,
>> >> >>
>> >> >> -- Pierre
>> >> >>
>> >> >>
>> >> >> ---------- Forwarded message ----------
>> >> >> From: Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>>
>> >> >> Date: Sun, Dec 11, 2016 at 9:04 PM
>> >> >> Subject: Subtitle/caption styling + TTML + CSS
>> >> >> To: "L. David Baron" <dbaron@dbaron.org<mailto:dbaron@dbaron.org>>
>> >> >> Cc: Thierry MICHEL <tmichel@w3.org<mailto:tmichel@w3.org>>, Bert Bos <bert@w3.org<mailto:bert@w3.org>>, Chris
>> >> >> Lilley <chris@w3.org<mailto:chris@w3.org>>, www-style list <www-style@w3.org<mailto:www-style@w3.org>>, Nigel
>> >> >> Megitt
>> >> >> <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
>> >> >>
>> >> >>
>> >> >> Hi David et al.,
>> >> >>
>> >> >> > I don't think TTML1 was designed in a
>> >> >> > way that would fit well in browser implementations.
>> >> >>
>> >> >> I have been working on an open source JavaScript library [1] for
>> >> >> rendering TTML1 documents to HTML5 fragments.
>> >> >>
>> >> >> [1] https://github.com/sandflow/imscJS

>> >> >>
>> >> >> TTML is based on XSL, which is based on CSS, and so the mapping has
>> >> >> been straightforward. [ed.: I am not sure what you mean by "does not
>> >> >> fit well", perhaps you can elaborate.]
>> >> >>
>> >> >> The most significant challenge has been supporting two features
>> >> >> (linePadding and multiRowAlign [2]), which are not supported in CSS,
>> >> >> but have been identified as essential to captioning in Europe by the
>> >> >> TTWG (and EBU).
>> >> >>
>> >> >> [2] https://www.w3.org/TR/ttml-imsc1/#linepadding

>> >> >>
>> >> >> I would think that features that are important to
>> >> >> subtitling/captioning should be considered for CSS, regardless of
>> >> >> the
>> >> >> ultimate timed text format (TTML, WebVTT, etc...)
>> >> >>
>> >> >> Best,
>> >> >>
>> >> >> -- Pierre
>> >> >>
>> >> >> On Wed, Nov 23, 2016 at 3:33 PM, L. David Baron <dbaron@dbaron.org<mailto:dbaron@dbaron.org>>
>> >> >> wrote:
>> >> >> > On Friday 2016-11-18 17:48 +0100, Thierry MICHEL wrote:
>> >> >> >> CSS colleagues,
>> >> >> >>
>> >> >> >> The Timed Text Working Group (TTWG) published yesterday an
>> >> >> >> ordinary
>> >> >> >> Working
>> >> >> >> Draft of Timed Text Markup Language 2 (TTML2)
>> >> >> >> W3C Working Draft 17 November 2016
>> >> >> >> https://www.w3.org/TR/2016/WD-ttml2-20161117/

>> >> >> >>
>> >> >> >> FYI, this publication is not the last publication before
>> >> >> >> requesting
>> >> >> >> transition to Candidate Recommendation. The TTWG plans to publish
>> >> >> >> a
>> >> >> >> final WD
>> >> >> >> soon. We will let you know.
>> >> >> >>
>> >> >> >> Meanwhile, the TTWG invites you to review this TTML2 WD.
>> >> >> >>
>> >> >> >> The horizontal review should focus only on the new features
>> >> >> >> introduced in TTML2.
>> >> >> >> Please refer to the section for changes between Timed Text Markup
>> >> >> >> Language
>> >> >> >> (TTML) Version 1 (TTML1) and Version 2 (TTML2).
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> https://www.w3.org/TR/2016/WD-ttml2-20161117/#changes-from-ttml1-vocabulary

>> >> >> >>
>> >> >> >> Please send your comments to  TTWG Public mailing list
>> >> >> >> <public-tt@w3.org<mailto:public-tt@w3.org>>.
>> >> >> >
>> >> >> > So it's worth noting that the styling section of the draft:
>> >> >> >   https://w3c.github.io/ttml2/spec/ttml2.html#styling

>> >> >> > has considerable new additions relative to TTML1.  This section
>> >> >> > contains a vocabulary that is rather similar to many CSS
>> >> >> > properties,
>> >> >> > but also contains significant divergence.
>> >> >> >
>> >> >> > In particular, TTML1 had in
>> >> >> > https://www.w3.org/TR/ttaf1-dfxp/#styling-attribute-vocabulary

>> >> >> > the following styling attributes that appear to match CSS at first
>> >> >> > glance, at least in semantics:
>> >> >> >   backgroundColor
>> >> >> >   color
>> >> >> >   direction
>> >> >> >   display (only auto vs. none)
>> >> >> >   extent (a shorthand for width and height)
>> >> >> >   fontFamily
>> >> >> >   fontSize
>> >> >> >   fontStyle
>> >> >> >   fontWeight
>> >> >> >   lineHeight
>> >> >> >   opacity
>> >> >> >   overflow
>> >> >> >   padding
>> >> >> >   textAlign
>> >> >> >   textDecoration (but with extra values)
>> >> >> >   unicodeBidi
>> >> >> >   visibility
>> >> >> >   wrapOption (like text-wrap in css-text-4)
>> >> >> >   writingMode (but using old values)
>> >> >> >   zIndex
>> >> >> > and the following styling attributes that do not match CSS:
>> >> >> >   displayAlign
>> >> >> >   origin (a bit like x and y in SVG)
>> >> >> >   showBackground
>> >> >> >   textOutline
>> >> >> >
>> >> >> > TTML2 introduces the following new properties that appear to have
>> >> >> > similar CSS properties at first glance:
>> >> >> >   backgroundClip (with different names for the values)
>> >> >> >   backgroundExtent (equivalent to background-size)
>> >> >> >   backgroundImage
>> >> >> >   backgroundOrigin (with different names for the values)
>> >> >> >   backgroundPosition
>> >> >> >   backgroundRepeat
>> >> >> >   border (with border-radius included in the property)
>> >> >> >   bpd (equivalent to block-size in css-logical-properties)
>> >> >> >   fontKerning (though without CSS's initial value, which is auto!)
>> >> >> >   ipd (equivalent to inline-size in css-logical-properties)
>> >> >> >   letterSpacing
>> >> >> >   ruby (this is done using the display property in CSS)
>> >> >> >   rubyAlign (with additional auto, end, and withBase values)
>> >> >> >   rubyPosition (with before/after names instead of over/under)
>> >> >> >   textCombine (equivalent to CSS text-combine-horizontal)
>> >> >> >   textEmphasis
>> >> >> >   textOrientation (but retaining the sidewaysLeft and
>> >> >> > sidewaysRight
>> >> >> >     values that CSS removed)
>> >> >> >   textShadow
>> >> >> > and the following that appear not to have corresponding CSS
>> >> >> > properties:
>> >> >> >   disparity
>> >> >> >   fontSelectionStrategy
>> >> >> >   fontShear
>> >> >> >   fontVariant (this is a property name used in CSS, but with a
>> >> >> >     different meaning!)
>> >> >> >   position (this is a property name used in CSS, but with a
>> >> >> >     different value, "center", although one that has been proposed
>> >> >> >     to be added to the CSS property)
>> >> >> >   rubyOffset
>> >> >> >   rubyOverflow
>> >> >> >   rubyOverhang
>> >> >> >   rubyOverhangClass
>> >> >> >   rubyReserve
>> >> >> >
>> >> >> >
>> >> >> > My opinion on this is that this seems like a lot of divergence
>> >> >> > from
>> >> >> > CSS.  It's divergence in naming (using different names for the
>> >> >> > same
>> >> >> > thing and the same names for different things), divergence in
>> >> >> > value
>> >> >> > spaces, and given that everything is redefined in the TTML spec
>> >> >> > (although often non-normatively "based on" CSS specs), almost
>> >> >> > certainly massive divergence in semantics.
>> >> >> >
>> >> >> > I think TTML and CSS have largely been implemented in separate
>> >> >> > implementations (which means that TTML has largely not been
>> >> >> > implemented in browsers), and I don't think TTML1 was designed in
>> >> >> > a
>> >> >> > way that would fit well in browser implementations.  That's why
>> >> >> > browsers implemented WebVTT instead.  I think continuing to
>> >> >> > diverge
>> >> >> > from CSS to this degree simply makes TTML implementation in
>> >> >> > browsers
>> >> >> > even less likely than it already was (which was already unlikely).
>> >> >> >
>> >> >> > On the flip side, I don't think fixing that divergence is
>> >> >> > particularly valuable (at least to browsers) since the communities
>> >> >> > are already separate, and I think the chance of getting
>> >> >> > substantial
>> >> >> > TTML implementation in browsers is low even without additional
>> >> >> > divergence.
>> >> >> >
>> >> >> > -David
>> >> >> >
>> >> >> > --
>> >> >> > 𝄞   L. David Baron                         http://dbaron.org/

>> >> >> > 𝄂
>> >> >> > 𝄢   Mozilla                          https://www.mozilla.org/

>> >> >> > 𝄂
>> >> >> >              Before I built a wall I'd ask to know
>> >> >> >              What I was walling in or walling out,
>> >> >> >              And to whom I was like to give offense.
>> >> >> >                - Robert Frost, Mending Wall (1914)
>> >> >>
>> >> >
>> >
>> >
>
>


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