- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Tue, 5 Nov 2013 11:27:10 +0000
- To: John Birch <John.Birch@screensystems.tv>, Andreas Tai <tai@irt.de>, "Glenn Adams" <glenn@skynav.com>
- CC: public-tt <public-tt@w3.org>
- Message-ID: <CE9E8416.14298%nigel.megitt@bbc.co.uk>
Thanks John, I've raised this as Issue-294 [1] including the text from your proposal email and from the follow-up re how to implement and the relationship to CSS etc. [1] https://www.w3.org/AudioVideo/TT/tracker/issues/294 I've assigned myself as owner however this is a placeholder for the time being. I'll also add it to the agenda for TPAC because it's closely related to ISSUE-283 [2] which is already on the agenda. [2] https://www.w3.org/AudioVideo/TT/tracker/issues/283 Kind regards, Nigel -- Nigel Megitt Lead Technologist, BBC Technology, Distribution & Archives Telephone: +44 (0)208 0082360 BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP On 04/11/2013 22:36, "John Birch" <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> wrote: Following Nigel’s last email I’d like to make the following proposal for consideration in TTML 2.0 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? Best regards, John John Birch | Strategic Partnerships Manager | Screen Main Line : +44 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532 Mobile : +44 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems Visit us at CCW, 13 – 14th November, Stand 1343, Javits Convention Center, New York P Before printing, think about the environment From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] Sent: 04 November 2013 17:55 To: John Birch; Andreas Tai; Glenn Adams Cc: public-tt Subject: Re: Clarification needed regarding tts:overflow We closed action-59 (https://www.w3.org/AudioVideo/TT/tracker/actions/59) that described shrink to fit, which was actually about shrinking regions to fit text, rather than the other way around. There's an opportunity to create a new issue describing 'shrink text to fit on a line' if you want to draft a proposal. This would be a useful contribution to the 'deterministic text rendering discussion at TPAC next week'. Kind regards, Nigel On 04/11/2013 17:06, "John Birch" <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> wrote: On a related topic I have recently been revisiting TTML 1.0 SE. With regards to lineheight the following algorithm is described: If a computed value of the property associated with this attribute is not supported, then a presentation processor must use the closest supported value. Note: In this context, the phrase closest supported value means the value for which the Euclidean distance between the computed line height and the supported line height is minimized. If there are multiple closest supported values equally distant from the computed value, then the value most distant from 0, i.e., the largest line height, is used. Whilst I understand and applaud the effort to explicitly state expected behaviour I am concerned that choosing a larger lineHeight than the computed value will in some cases lead to overflow. Clearly, as discussion shows, in certain contexts (e.g. especially in subtitling), overflow is very undesirable…. In fact IMHO it is difficult to conceive of any situation where an author would prefer the clipping or loss of their text! Or prefer the wrapping of their text, over the presentation of their text in a smaller font but with their authored line presentation preserved ( Note: I’m assuming this cautious author has used separate p elements or br elements to force line breaks). I can imagine that some justifications for not ALWAYS reducing the font size might be that this impacts readability… but research shows that appropriate phrasing (i.e. line layout) and missing words have a far greater impact upon comprehension! I can hope that the addition of a ‘shrink to fit’ modality to TTML will resolve my concerns. Best regards, John John Birch | Strategic Partnerships Manager | Screen Main Line : +44 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532 Mobile : +44 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems Visit us at CCW, 13 – 14th November, Stand 1343, Javits Convention Center, New York P Before printing, think about the environment From: Andreas Tai [mailto:tai@irt.de] Sent: 03 November 2013 18:27 To: Glenn Adams Cc: public-tt Subject: Re: Clarification needed regarding tts:overflow Apalogies if I did not made my intention clear enough. It was to prove that my interpretation is not correct and that the use of the feature is as defined in XSL:FO and CSS. My original interpretation of tts:overflow was always that it has the same semantics as in CSS. But in a conversation the part highlighted below was mentioned and I needed some clarification. In general I see it as a huge benefit that the layout and formatting of TTML is nearly fully compatible with CSS. This allows a smooth integration in web technologies like HTML 5. Thanks and best regards, Andreas Am 03.11.2013 07:10, schrieb Glenn Adams: Basically, TTML is doing precisely what XSL-FO and CSS both do here, as defined by the preliminary material in [1]. If you find yourself interpreting TTML style properties in a way that is distinct from CSS semantics, then you should question your interpretation first. We never intentionally diverge except in noted extensions, particularly the use of 'c' metric and the potential use of an anamorphic font size. [1] http://www.w3.org/TR/CSS2/visufx.html#overflow-clipping On Sat, Nov 2, 2013 at 12:00 PM, Andreas Tai <tai@irt.de<mailto:tai@irt.de>> wrote: Thanks Glenn for the clarification! >From the TTML Spec: "If the value of this attribute is visible [...] region composition and layout must be performed as if the region's width and height were unconstrained" [1] >From my reading content that overflows the region extents the "box" of the region. No. It merely goes outside of that box (and is not clipped by it). That is different what is shown in the first example of tts:overflow where the background color is only applied to the contrained region extent. Only the text content is rendered outside of the regions box. The size of the box should not be changed for the purpose of drawing its background. OK. Seems that I misunderstood it. But from the conversation I had with others I am not the only one. From my view the text marked in red (and '*') leads to this misreading. From my view it would be better to omit it (but possibly it is to late for a change). "If the value of this attribute is visible, then content should not be clipped outside of the affected region*, and region composition and layout must be performed as if the region's width and height were unconstrained, but with a well-defined origin*. " - Andreas Am 01.11.2013 18:56, schrieb Glenn Adams: On Fri, Nov 1, 2013 at 10:30 AM, Andreas Tai <tai@irt.de<mailto:tai@irt.de>> wrote: I need some clarification regarding the tts:overflow [1] attribute in TTML 1.0 (2nd edition). 1) Is this attribute only an indicator how presentation processors should handle content that overflows a region? In the description of the desired presentation behaviour for "visible" and "hidden" the key word "should" and not "must" is used. (This seems to reflect the usage of overflow in XSL 1.1 and CSS) Yes. I suspect we used "should not be clipped" because other semantics outside the scope of interpreting this property may cause clipping. 2) Does tts:overflow "hidden" create a "dynamic sized region" where width and height adopts to the size of the content? No. It simply behaves as if the region into which this content is selected is unconstrained in width (or height) in the inline progression dimension. >From the TTML Spec: "If the value of this attribute is visible [...] region composition and layout must be performed as if the region's width and height were unconstrained" [1] >From my reading content that overflows the region extents the "box" of the region. No. It merely goes outside of that box (and is not clipped by it). That is different what is shown in the first example of tts:overflow where the background color is only applied to the contrained region extent. Only the text content is rendered outside of the regions box. The size of the box should not be changed for the purpose of drawing its background. Furthermore I believe that if the constrain is meant in that way it is not compatible with CSS. I'm not sure what you mean here. Could you be more precise, and provide an example (in both TTML and HTML/CSS)? - Andreas [1] http://www.w3.org/TR/ttaf1-dfxp/#style-attribute-overflow -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389<tel:%2B49%2089%2032399-389> | Fax: +49 89 32399-200<tel:%2B49%2089%2032399-200> http: www.irt.de<http://www.irt.de> | Email: tai@irt.de<mailto:tai@irt.de> ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------ -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389 | Fax: +49 89 32399-200 http: www.irt.de<http://www.irt.de> | Email: tai@irt.de<mailto:tai@irt.de> ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------ 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 ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. --------------------- 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 ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ---------------------
Received on Tuesday, 5 November 2013 11:27:44 UTC