ISSUE-294: Style attribute to prevent overflow by shrinking text to fit on a line
Shrink text to fit on a line
Style attribute to prevent overflow by shrinking text to fit on a line
- State:
- OPEN
- Product:
- TTML.next
- Raised by:
- Nigel Megitt
- Opened on:
- 2013-11-05
- Description:
- 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. - Related Actions Items:
- No related actions
- Related emails:
- {minutes} TTWG Meeting 2015-03-05 (from nigel.megitt@bbc.co.uk on 2015-03-05)
- {agenda} TTWG Meeting 2015-03-05 (from nigel.megitt@bbc.co.uk on 2015-03-04)
- {agenda} TTWG Meeting 2015-02-26 (from nigel.megitt@bbc.co.uk on 2015-02-25)
- {agenda} TTWG Meeting 2015-02-19 (from nigel.megitt@bbc.co.uk on 2015-02-18)
- {agenda} TTWG Meeting 2015-02-12 (from nigel.megitt@bbc.co.uk on 2015-02-11)
- {agenda} TTWG Meeting 2015-02-05 (from nigel.megitt@bbc.co.uk on 2015-02-04)
- {agenda} TTWG Meeting 2015-01-29 (from nigel.megitt@bbc.co.uk on 2015-01-28)
- {agenda} TTWG Meeting 2015-01-22 (from nigel.megitt@bbc.co.uk on 2015-01-21)
- {agenda} TTWG Meeting 2015-01-15 (from nigel.megitt@bbc.co.uk on 2015-01-14)
- {agenda} TTWG Meeting 2015-01-08 (from nigel.megitt@bbc.co.uk on 2015-01-07)
- {agenda} TTWG Meeting 2014-12-18 (from nigel.megitt@bbc.co.uk on 2014-12-17)
- RE: {minutes} TTWG Meeting 2014-12-04 (from John.Birch@screensystems.tv on 2014-12-04)
- Re: {minutes} TTWG Meeting 2014-12-04 (from glenn@skynav.com on 2014-12-04)
- {minutes} TTWG Meeting 2014-12-04 (from nigel.megitt@bbc.co.uk on 2014-12-04)
- {agenda} TTWG Meeting 2014-12-04 (from nigel.megitt@bbc.co.uk on 2014-12-03)
- TTML Minutes for 11/11/13 (from nigel.megitt@bbc.co.uk on 2013-11-21)
- Re: Clarification needed regarding tts:overflow (from nigel.megitt@bbc.co.uk on 2013-11-05)
- ISSUE-294 (Shrink text to fit on a line): Style attribute to prevent overflow by shrinking text to fit on a line [TTML2] (from sysbot+tracker@w3.org on 2013-11-05)
Related notes:
Related to ISSUE-283
Nigel Megitt, 5 Nov 2013, 11:25:40Notes from Sean Hayes email 5/11/2013 11:4 "RE: New Features and CSS Compatibility::
CSS does in fact have a shrink-to-fit concept http://www.w3.org/TR/CSS21/visudet.html#shrink-to-fit-float:
10.3.5 Floating, non-replaced elements
If 'margin-left', or 'margin-right' are computed as 'auto', their used value is '0'.
If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width.
Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not define the exact algorithm. Thirdly, find the available width: in this case, this is the width of the containing block minus the used values of 'margin-left', 'border-left-width', 'padding-left', 'padding-right', 'border-right-width', 'margin-right', and the widths of any relevant scroll bars.
Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).
And so there is *a* mapping, if not ideal, as these pages demonstrate:
http://www.brunildo.org/test/shrink-to-fit.html
http://www.brunildo.org/test/shrink_center_3.html
However it may require some amount of creativity to apply to the TTML mapping.
I believe the CSS WG have attempted to reuse this concept elsewhere in CSS3.
Note that there is a difference between shrink to fit and content fitting. In the former, the containing block is sized such that it fits around content without producing overflow. In the latter, the content itself is altered to fit the containing block. John's proposal talks about changing font size and line height to fit the content to the region, so I assume he is talking about the latter, and not the former.
In any case, there are two ways to reduce the chance of overflow without doing full blown content fitting: (1) use the new 'font' element to ensure the player uses the fonts that were used to layout the text at authoring time; (2) use the new measure expression's fitContent value in a tts:extent expression, e.g., tts:extent='fitContent auto' to fit the width to the content.
Given these two new techniques to reduce overflow, I propose closing this issue without any further action, since adding true content fitting introduces too much complexity, and is not yet handled by any CSS mechanism or implementation.
[Meeting 2015-03-05] Reopening and moving to v.next.
Nigel Megitt, 5 Mar 2015, 15:43:14Display change log
