Re: Change Proposal 21 review

On Wed, Jan 28, 2015 at 7:38 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Glenn et al.,
>
> Thanks for the additional details.
>
> > elaborated handling of potential overflow of line area [1]
>
> As far as I can tell this is substantially different than the HGroup
> feature in ST 428-7. Specifically, the horizontal text in ST 428-7 is
> not "combin[ed] into an em square of the surrounding vertical text,"
> but rather set horizontally with a font size selected by the author.
>
> > [2] http://www.w3.org/AudioVideo/TT/tracker/issues/231
> > [...]
> > the described liaison cites as a use case the handling of
> > horizontal text in a vertical writing mode context
>
> The liaison (Section 6.11 of ST 428-7) does not contain this
> limitation, but merely notes that "this is most commonly used to
> present special characters in a text string that is being displayed
> vertically."
>
> I recommend TTWG ultimately communicates to SMPTE its disposition on
> these requests.
>

My position is that the SMPTE example is wrong or an exceptionally bad
example. It certainly does not reflect common practice in Japanese or
Chinese layout. The spec'd feature leaves it up to the client to decide how
to fit the content, including the possibility that if it overflows by a
client specific limit, it can simply set it sideways. The goal remains to
set it into a nominal EM square.

In any case, there is no reason that the author can't specify a distinct
font size on the horizontal span portion, and the client to utilize that
information to assist in fitting.


>
> Best,
>
> -- Pierre
>
> On Sun, Jan 25, 2015 at 1:01 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > On Wed, Jan 21, 2015 at 11:45 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Below is my input on Change Proposal 21 [1] per  AI #365 [2].
> >>
> >> - ISSUE-229. The SMPTE liaison [3] shows an example where the width of
> >> the horizontal character group is larger than the width of the
> >> bounding box of the associated vertical characters. Under
> >> "tts:textCombine" (as referenced in ISSUE-219), the latest ED [4]
> >> states that "the tts:textCombine attribute is used to specify a style
> >> property that determines whether and how multiple nominally
> >> non-combining characters are combined so that their glyph areas
> >> consume the nominal bounding box of a single em square." Is the ED
> >> consistent with the SMPTE liaison?
> >
> >
> > elaborated handling of potential overflow of line area [1]
> >
> > [1] https://dvcs.w3.org/hg/ttml/rev/46a91ba16236
> >
> >>
> >>
> >> - ISSUE-231. Did the editor respond to the last question on the issue?
> >
> >
> > just responded [2]
> >
> > [2] http://www.w3.org/AudioVideo/TT/tracker/issues/231
> >
> >>
> >>
> >> Looks good to me otherwise.
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> [1] https://www.w3.org/wiki/TTML/changeProposal021
> >> [2] https://www.w3.org/AudioVideo/TT/tracker/actions/365
> >> [3] https://lists.w3.org/Archives/Member/w3c-archive/2012Sep/0214.html
> >> [4]
> >>
> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-attribute-textCombine
> >>
> >
>