- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Fri, 11 Oct 2013 09:05:44 -0700
- To: Glenn Adams <glenn@skynav.com>
- Cc: Timed Text Working Group <public-tt@w3.org>
> Given the lack of definition of "Helvetica-like", I meant as in the following, which are referenced in IMSC: http://www.microsoft.com/typography/fonts/family.aspx?FID=8 (Arial) http://www.linotype.com/en/526/Helvetica-family.html (Helvetica) Thanks, -- Pierre On Fri, Oct 11, 2013 at 8:39 AM, Glenn Adams <glenn@skynav.com> wrote: > > On Fri, Oct 11, 2013 at 9:31 AM, Pierre-Anthony Lemieux <pal@sandflow.com> > wrote: >> >> Hi Glenn, >> >> Thanks for the information re: line breaking. >> >> > Further, there is no way in an XSL-FO or CSS mapping to >> > say the rendering engine that font Y should be used with the metrics of >> > font X. >> >> How much variation would you expect in the metrics of the various >> Helvetica-like fonts used by OWP-based presentation processors? > > > Given the lack of definition of "Helvetica-like", I would interpret that as > meaning any font that could be used to map the proportionalSansSerif generic > font family. As such, there is extremely wide range of fonts and metrics > that apply. > >> >> >> Thanks, >> >> -- Pierre >> >> On Thu, Oct 10, 2013 at 7:04 PM, Glenn Adams <glenn@skynav.com> wrote: >> > It is a weak version of OPTION 2, without a standard line breaking >> > algorithm. Further, there is no way in an XSL-FO or CSS mapping to say >> > the >> > rendering engine that font Y should be used with the metrics of font X. >> > So I >> > suspect that any OWP based presentation processor would simply ignore >> > that >> > requirement. >> > >> > >> > On Thu, Oct 10, 2013 at 7:48 PM, Pierre-Anthony Lemieux >> > <pal@sandflow.com> >> > wrote: >> >> >> >> Hi Glenn et al., >> >> >> >> > OPTION 2 - Difficult to specify concrete collection of fonts that >> >> > serves >> >> > all of Unicode, >> >> > or at least the subset of Unicode used in regional caption/subtitle >> >> > text. >> >> >> >> The IMSC draft uses ubiquitous fonts (Courier and Helvetica) to define >> >> specify reference font metrics for selected font families >> >> (monospaceSerif and proportionalSansSerif, respectively). Presentation >> >> processors are not required to render using the reference font (and >> >> can use a font of a different shape in fact), but must render using >> >> the font metrics of the reference font. >> >> >> >> Is that OPTION 2, or a new OPTION 5? >> >> >> >> Best, >> >> >> >> -- Pierre >> >> >> >> On Thu, Oct 10, 2013 at 12:52 PM, Glenn Adams <glenn@skynav.com> wrote: >> >> > We have discussed this many times in the past, going back to 2003, >> >> > and >> >> > within CSS and XSL WGs, where it is similarly a known problem. >> >> > >> >> > The only way to obtain interoperable deterministic line breaks is: >> >> > >> >> > OPTION 1 to manually break the line using <br/> and specify >> >> > wrapOption='noWrap' >> >> > >> >> > or >> >> > >> >> > OPTION 2 require every presentation processor to support at least one >> >> > concretely specified font, with effectively identical metrics on >> >> > every >> >> > platform, *and* require every presentation processor to support at >> >> > least >> >> > one >> >> > concrete line break implementation, with a way for the author to >> >> > express >> >> > that algorithm must be used; >> >> > >> >> > or >> >> > >> >> > OPTION 3 require support for downloadable fonts and at least one >> >> > specifiable, universally supported line break implementation; >> >> > >> >> > or >> >> > >> >> > OPTION 4 use only image based captions, where rendering is done once >> >> > during >> >> > authoring. >> >> > >> >> > Comments >> >> > >> >> > OPTION 1 - May lead to region overflow (and possible clipping) >> >> > OPTION 2 - Difficult to specify concrete collection of fonts that >> >> > serves >> >> > all >> >> > of Unicode, or at least the subset of Unicode used in regional >> >> > caption/subtitle text. >> >> > OPTION 3 - Probably best option in theory, most likely solution would >> >> > require support for (1) OpenType fonts delivered by WOFF, (2) >> >> > freetype >> >> > font >> >> > rasterizer, and (3) ICU implementation of UAX14. >> >> > OPTION 4 - Makes timed "text" rather pointless, unless both image and >> >> > text >> >> > formats delivered together. >> >> > >> >> > >> >> > On Thu, Oct 10, 2013 at 11:31 AM, Timed Text Working Group Issue >> >> > Tracker >> >> > <sysbot+tracker@w3.org> wrote: >> >> >> >> >> >> ISSUE-283 (Deterministic Presentation): Deterministic text wrapping >> >> >> and >> >> >> presentation [TTML2] >> >> >> >> >> >> http://www.w3.org/AudioVideo/TT/tracker/issues/283 >> >> >> >> >> >> Raised by: Nigel Megitt >> >> >> On product: TTML2 >> >> >> >> >> >> There's a complex interaction between lineHeight, fontSize, overflow >> >> >> and >> >> >> wrapOption that determines, for the font that the display processor >> >> >> chooses, >> >> >> how much text will fit on a line and whether any text that doesn't >> >> >> fit >> >> >> overflows or is truncated. This creates a problem for document >> >> >> authors >> >> >> if >> >> >> they can not be certain of the metrics of the font used to present >> >> >> their >> >> >> content. >> >> >> >> >> >> The goal from an audience perspective is that the on-screen text is >> >> >> readable and complete. Nobody wants missing words (that could change >> >> >> the >> >> >> editorial meaning) or text that is visible but unreadable. >> >> >> >> >> >> TTML offers little by way of solution to this real world problem at >> >> >> the >> >> >> moment. The IMSC submission presents a 'reference font' mechanism, >> >> >> which >> >> >> should be considered. Is there anything more that we can do natively >> >> >> in >> >> >> TTML >> >> >> to allow deterministic rendering to be defined at the point of >> >> >> authoring? >> >> >> >> >> >> Raising this issue for discussion at TPAC. >> >> >> >> >> >> Note that there are related issues (to be filed separately) around >> >> >> lineHeight=normal being related to the height of the text actually >> >> >> flowed >> >> >> onto a line (is it? or is it related to the descendent elements of >> >> >> the >> >> >> <p>?) >> >> >> and being set to a percentage of the font size - should it be 100%, >> >> >> 120%, >> >> >> 125% etc. for compatibility with CSS etc. >> >> >> >> >> >> >> >> >> >> >> > >> > >> > > >
Received on Friday, 11 October 2013 16:06:33 UTC