ISSUE-294 (Shrink text to fit on a line): Style attribute to prevent overflow by shrinking text to fit on a line [TTML2]

ISSUE-294 (Shrink text to fit on a line): Style attribute to prevent overflow by shrinking text to fit on a line [TTML2]

http://www.w3.org/AudioVideo/TT/tracker/issues/294

Raised by: Nigel Megitt
On product: TTML2

Proposal from John Birch to implement ‘shrinking text to fit on a line’, optionally as a new style attribute for either <p> element and <region> elements. Purpose of this new attribute is to allow an implementation to preserve the intended authorial rendering size of the displayed text in the event that the exact font assumed by the authoring process is not available when rendering.
 
Currently, in the event that a computed line height / font size is not supported, and when the implementation would (under existing standard) choose a larger font size / line height, then text may overflow the region created by the author for the text. Depending upon the values of the tts:wrapOption and tts:overflow attributes this *may* (also depending upon the difference between the computed line height / font size and the font sizes actually used by the rendering implementation) result in text overflowing the region, in either or both of the block and inline progression directions. In some use cases, for example subtitling, any text ‘overflow’ is extremely undesirable, resulting potentially in text truncation, extra lines of text generated or text that is difficult to read because it is not drawn above the region background (to ensure high contrast).
 
The addition of a shrink to fit functionality, proposed as a new attribute, would give implementations the option to shrink one or more rendered lines of text down, until the text meets the size constraints of the region or p element (in the case of the region these size constraints would be the defined region dimensions, in the case of a p element, the size constraints would be exactly the computed size of the line from the authored value(s), before any substitution was made by an implementation not able to exactly support those values). For a region element both horizontal and vertical dimensions would be constraints on scaling (which might therefore need to be asymmetric), but for p elements it is envisaged that only simple uniform scaling to meet the constraint of the computed ‘height’ (in block progression terms) of the p element would be required.
 
It is proposed therefore that scaling of either individual <p> elements or regions would proceed as follows.
 
Processing of the Intermediate Synchronic Document proceeds as normal, all style attributes are processed and computed line heights and font sizes are determined. If the processor determines that substitution of ‘font’ (and thus adjustment of font size / line height is necessary because the requested size cannot be fulfilled by the implementation), then instead of making a substitution, the implementation renders with the next nearest largest font / line height, and subsequently scales the resulting rendered output (be it vectors or pixels) to meet the authored specified dimension. Initially the rendered output is scaled uniformly in both dimensions until the block progression constraint size is attained (for either the p or region) and then, if necessary, further scaled in the inline progression direction only, until the inline progression constraint size is also met.
 
I hope this makes some kind of sense… I suspect that better minds may have alternative (and probably better strategies to achieve my desired result. Indeed such concepts may already be under discussion with CSS or XSL:FO groups?

[This] is simply meant as a statement of desired functionality… I defer to those with better understanding of the supporting technologies to consider how it might be implemented. I accept that it is likely L that the (correct IMHO) choice by TTWG of CSS / XSL:FO as referenced standards may mean that my ‘shrink to fit’ desires are not possible. This being simply because those underlying frameworks were not constructed ‘with a mindset’ that would support such behaviour.

[Edit] ... I note with interest that CSS3 includes flex-box layout functionality – cursory inspection would suggest this might be relevant.

Received on Tuesday, 5 November 2013 11:20:39 UTC