- From: Glenn Adams <glenn@skynav.com>
- Date: Wed, 17 Jul 2013 10:51:09 -0600
- To: Andreas Tai <tai@irt.de>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, public-tt <public-tt@w3.org>, John Birch <John.Birch@screensystems.tv>, Pierre-Anthony Lemieux <pal@sandflow.com>
- Message-ID: <CACQ=j+ftGyO_M_f_9omtOSqz-Wvp7uy51n-8XbLc4BEv9RShLg@mail.gmail.com>
On Wed, Jul 17, 2013 at 10:01 AM, Andreas Tai <tai@irt.de> wrote: > Doesn´t it make sense for TTML to adopt the meaning from XSL 1.1 and to > let the rendering application choose a line-height that results in readable > text? Isn´t it the missing control of the author which font will be used > for display exactly the reason to give the rendering application the > control? > > Of course with this semantics of line-height "normal" the author can not > predict the exact presentation but this assumption is for some use cases > (as stated below) of theoretical nature anyway. > > From German broadcaster perspective the requirement that text is > accessible and readable is more important than that the text has an exact > font-size or line-height. > > As a perfect solution does not exist I would vote to align the definition > of normal with XSL 1.1 or to adopt an option brought in by Glenn and "to > define normal as 1.2*max descendant em square". > The XSL-FO 1.X definition of normal matches CSS2 (1998): normal Tells user agents to set the computed value to a "reasonable" value based on the font size of the element. The value has the same meaning as <number>. We recommend a computed value for "normal" between 1.0 to 1.2. We diverged from this slightly by specifying the the largest font size that applies to any descendant element , though this perhaps should have said the largest font size that applies to any descendant element or self (this element). > > Best regards, > > Andreas > > > Am 17.07.2013 09:39, schrieb Nigel Megitt: > > > > On 16/07/2013 17:49, "Glenn Adams" <glenn@skynav.com> wrote: > > > > On Tue, Jul 16, 2013 at 10:25 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote: > >> Current wording in 8.2.12 tts:lineHeight: >> >> If the value of this attribute is normal, then the initial value of the >> style property must be considered to be the same as the largest font size >> that applies to any descendant element. >> >> >> Suggested wording, taking into account the previous amendment on this >> thread: >> >> If the value of this attribute is normal, then the initial value of the >> style property must be considered to be the same as the height of the >> largest em square of the fonts that apply to any descendant element in >> the intermediate synchronic document instance. >> > > Sounds reasonable, though better to say "the maximum height of the EM > squares of the fonts that apply" > > > Thanks, yes, that's better. > > >> Add a note: >> >> If lineHeight is normal and a font is selected for presentation with an >> em square whose height does not include ascents, descents and any other >> spacing needed for creating a default line spacing then the resulting text >> is likely to be difficult to read. >> > > Sounds reasonable. I will make these changes in the 10SE ED and the 11 > ED. > > > Thanks. > > >> Nigel >> >> >> On 16/07/2013 17:08, "Glenn Adams" <glenn@skynav.com> wrote: >> >> >> >> On Tue, Jul 16, 2013 at 9:51 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote: >> >>> CIL >>> >>> On 16/07/2013 16:26, "Glenn Adams" <glenn@skynav.com> wrote: >>> >>> >>> >>> On Tue, Jul 16, 2013 at 8:47 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote: >>> >>>> Thanks Glenn, >>>> >>>> I'd also appreciate your views on the suggested clarifications I >>>> proposed in the thread, copied again here to save your scroll mechanism: >>>> >>>> 1. State that we (TTML) assume that any presentation device will apply >>>> appropriate rules to generate a font of the required size, regardless of >>>> what algorithm is used either to scale or select a pre-defined font of a >>>> similar size. >>>> >>>> The problem with the current TTML wording is that it says (inhttp://www.w3.org/TR/ttaf1-dfxp/#style-attribute-fontSize) both "font size >>>> is interpreted as a scaling transform to the font's design EM square" and >>>> "horizontal and vertical scaling of a glyph's em square" which seem to >>>> conflict. Is it each individual glyph that should be scaled, or the entire >>>> font? As I understand it the font has an em square and each glyph has it's >>>> own width and height that may be different from the em square. >>>> >>>> I can see how this could be confusing, but in my estimation there is >>> no conflict because a glyph's em square is the font's em square. That is, a >>> glyph's em square is not the glyph's width and height (in current font >>> technology terminology). However, it wouldn't hurt to state this in an >>> informative note. >>> >>> >>> I agree – the concept of a glyph's em square is a bit meaningless. >>> Really what's meant is the glyph's font's em square. >>> >>> 2. State that TTML assumes that the em square unit is a suitable line >>>> spacing size for the chosen font, i.e. that it includes the ascent, >>>> descent and extra space needed above and below, left and right. The >>>> article http://www.microsoft.com/typography/otspec/TTCH01.htm includes a >>>> good picture of this in the section headed "FUnits and the em square". >>>> >>>> Unfortunately, this is not the case in practice. There is no >>> requirement on fonts that a glyph's marks be contained in the font's em >>> square. There are many fonts where this is not true. >>> >>> >>> Agreed however the main point is the assumption that the em square >>> height is a suitable line spacing size, embodied in the concept of a >>> 'normal' line height. >>> >> >> Well, 'normal' must be defined to mean something. Another possibility >> is to define normal as 1.2*max descendant em square. >> >> Regarding the term 'suitable', it is overly subjective, and not >> particularly useful in a technical spec, wouldn't you agree? Go ask a room >> full of font designers what is a 'suitable' line height based on a known >> font metric, and I suspect you will get a number of different answers. >> >> >> >>> >>> I think TTML doesn't make any assumptions about suitability re: >>> line spacing for a given font. Rather, TTML assumes the author will choose >>> a font that works for their purposes. >>> >>> >>> The consequence of that would be that lineHeight=normal would convey >>> no useful information. >>> >> >> The useful information is that we define 'normal' in a precise way. >> >> >>> But I don't think that's what the TTML spec intends. As it stands some >>> implementations might assume that the em square needs a bit 'extra' to make >>> the line spacing look nice, whereas others may not. >>> >> >> I suspect those implementations could be considered non-compliant, >> since they are interpreting normal differently than we specify in TTML. >> >> >>> Implementation consistency here would be desirable, to the extent >>> possible given that the font used for authoring may not be the font used >>> for display (though I note the suggestion of an external font reference >>> which would help). Clarification in the TTML spec would really help here. >>> >> >> Please propose some specific text you'd like to see added, then we can >> discuss it. >> >> >>> >>> I think the best we could do is to make a recommendation that the >>> monospace* generic font families be mapped to device fonts that have the >>> above property. >>> >>> >>> I don't understand how being selective about whether fonts are >>> monospaced or proportionally spaced [horizontally] affects the [vertical] >>> line height problem. >>> >> >> It doesn't. I was referring to the issue of having glyph marks fall >> outside the em square. >> >> >>> >>> >>> Ultimately, we may wish to consider adding support for referring to >>> downloaded font resources. >>> >>> >>> That would certainly help with font choices and authoring consistency, >>> though not the line height calculation. >>> >>> I think both of these could be inferred from the current spec but by >>>> making them explicit it would help to avoid the confusion. >>>> >>>> The result should be that each row in a cell grid is 1c and there's no >>>> need for 80%s and 120%s here and there (unless a particular visual effect >>>> squeezing or stretching the baseline spacing is desired!). >>>> >>>> >>>> Obviously I've not gone to the trouble of coming up with precise >>>> wording for the spec yet as we're still at the 'in principle' stage. >>>> >>>> Kind regards, >>>> >>>> Nigel >>>> >>>> >>>> On 16/07/2013 15:24, "Glenn Adams" <glenn@skynav.com> wrote: >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 7:09 AM, Andreas Tai <tai@irt.de> wrote: >>>> >>>>> Dear all, >>>>> >>>>> We had an extensive discussion on the EBU mailing list regarding the >>>>> relationship between cell resolution, font-size and line-height. At some >>>>> point we found out that the TTML mailing list is possibly the better place >>>>> to discuss some of the question that came up. >>>>> >>>>> For completeness I include part of the mailing list thread below. >>>>> >>>>> Some questions are highlighted below: >>>>> >>>>> ---------------------------- >>>>> Font-Size >>>>> ---------------------------- >>>>> In TTML scaling is applied to the glyph's EM square. As Nigel noted >>>>> below "the font has an EM square and each glyph has its own width and >>>>> height that may be different from the EM square". So possibly there is >>>>> clarification needed. >>>>> >>>>> As I understand the rendering processor would choose a font that best >>>>> matches the specified font characteristics (including the font-size) and >>>>> then scale the font/the EM square to the computed font-size. Is this >>>>> correct? >>>>> >>>> >>>> Yes. >>>> >>>> >>>>> So, assumed there is no ancestor element with a specified font-size, >>>>> the root container height is 720px, the grid is "32 15" and you choose a >>>>> font-size of 100% then the computed font-size would be 720px/15 = 48px? >>>>> >>>> >>>> Yes. Since the initial font size, as applied to the outermost element >>>> (of the intermediate synchronic document instance) of the style inheritance >>>> process [1], namely tt, is 1c, and since, given a 720px height(RC), >>>> then the computed cell height is as you say: 48px. Therefore, 100% or 48px >>>> is 48px. >>>> >>>> [1] >>>> http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#semantics-style-inheritance >>>> >>>> >>>>> >>>>> Another question is how this will be mapped into CSS. Assumed the >>>>> font-family is specified as Arial, should the calculated value of the CSS >>>>> property font-size be 48px? Would the scaling in current browser >>>>> implementation work as intended by the TTML definition and scale the EM >>>>> square of the chosen Arial font? >>>>> >>>> >>>> If we define TTML pixels to be equivalent to CSS pixels, then yes, or >>>> at least, yes, I expect that will be the mapping we define. However, we >>>> haven't yet defined TTML pixels, so we'll have to progress the mapping >>>> definition before we have a definitive answer. Even if we choose a >>>> different definition of pixels (and it is unlikely we would do so), then >>>> TTML pixels could be further scaled as required to map to CSS pixels. >>>> >>>> >>>>> >>>>> >>>>> ---------------------------- >>>>> Line height >>>>> ---------------------------- >>>>> Obviously the relationship between font-size and line-height is very >>>>> important for subtitling. In legacy formats subtitles are positioned on an >>>>> exact number of lines. To control the grid of lines in TTML the line-height >>>>> has to be specified explicitly. But as the font-size would not shrink or >>>>> increase automatically according to a fixed line-height this has to be done >>>>> with care (e.g. to avoid colliding glyphs). >>>>> >>>>> If you give up the control over the rendered line height you could >>>>> choose the initial value of "normal". The computed value for the >>>>> line-height would be the same as the largest font size that applies to any >>>>> descendant element[1]. So if the font-size is 48px, the value of >>>>> line-height will be 48px as well. >>>>> >>>>> This could actually result in unwanted presentation because as I >>>>> understood there will be no white space between the content of two adjacent >>>>> line (so there will be no leading?). >>>>> >>>>> In XSL:FO 1.1 (same as XSL 1.1) the value of “normal” for line-height >>>>> is defined as follows [2]: >>>>> >>>>> > 7.16.4 "line-height" >>>>> > [Normal] tells user agents to set the computed value to a >>>>> "reasonable" value based on the font size of the element. [...] We >>>>> recommend a computed value for "normal" between 1.0 to 1.2. >>>>> >>>>> The same definition can be found in the CCS 2 spec. >>>>> >>>>> This user agent dependent behaviour is reflected in current browser >>>>> implementations. The author cannot assume a specific line-height when >>>>> setting the value to “normal” even if he knows font-family and font-size. >>>>> So they may be a problem when mapping TTML lineHeight with the value >>>>> of “normal” to the CSS property line-height and the value “normal”?! >>>>> >>>> >>>> Since TTML uses a more specific definition of line height [2]: >>>> >>>> If the value of this attribute is normal, then the initial value of >>>> the style property must be considered to be the same as the largest font >>>> size that applies to any descendant element. >>>> >>>> It would be incorrect to map the value normal to the CSS value normal >>>> (unless we revise the TTML definition to use the vague definition of CSS). >>>> >>>> [2] >>>> http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#style-attribute-lineHeight >>>> >>>> I see also that we need to slightly clarify the TTML definition to >>>> read: >>>> >>>> If the value of this attribute is normal, then the initial value of >>>> the style property must be considered to be the same as the largest font >>>> size that applies to any descendant element in the intermediate >>>> synchronic document instance. >>>> >>>> The need for this clarification should be obvious, since a descendant >>>> in the original document may not be in a given intermediate document (e.g., >>>> because it was selected into a different region). >>>> >>>> >>>>> >>>>> ------------------------------- >>>>> Font-Size / Line Height >>>>> ------------------------------- >>>>> Currently the cell resolution is the only way to relate the font-size >>>>> to the height of the video (if the root container is set by a specification >>>>> explicitly to the size of the video). >>>>> >>>> >>>> Correct. >>>> >>>> >>>>> As Sean stated the “vh “ strategy for font-size is currently >>>>> evaluated to relate the font-size directly to the size of the video. I >>>>> assume that this should be similar (or same) to what is proposed for >>>>> viewport-relative-lengths in CSS3 [4] and defined as well in CSS files of >>>>> "Conversion of 608/708 captions to WebVTT" [5]. Possibly it can be >>>>> discussed on the list how this can be applied to TTML and if this would be >>>>> solution for the Issue-225. >>>>> >>>> >>>> I expect we will introduce vh/vw units into TTML.next, and, mutatis >>>> mutandis, use the definitions you cite from [4]. >>>> >>>> >>>>> >>>>> Best regards, >>>>> >>>>> Andreas >>>>> >>>>> [1] >>>>> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10/spec/ttaf1-dfxp.html?content-type=text/html%3bcharset=utf-8#style-attribute-lineHeight >>>>> [2] http://www.w3.org/TR/xsl/#line-height >>>>> [3] http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height >>>>> [4] http://www.w3.org/TR/css3-values/#viewport-relative-lengths >>>>> [5] >>>>> https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#browsers >>>>> [6] http://www.w3.org/AudioVideo/TT/tracker/issues/225 >>>>> >>>>> >>>>> -------- Original-Nachricht -------- Betreff: Re: [EBU-TT-D] Updated >>>>> list of proposed TTML features Datum: Mon, 8 Jul 2013 09:14:19 +0000 Von: >>>>> Nigel Megitt <nigel.megitt@bbc.co.uk> <nigel.megitt@bbc.co.uk> An: John >>>>> Birch <John.Birch@screensystems.tv> <John.Birch@screensystems.tv>, >>>>> Andreas Tai <tai@irt.de> <tai@irt.de>, "EBU-TT-D@list.ebu.ch"<EBU-TT-D@list.ebu.ch> >>>>> <EBU-TT-D@list.ebu.ch> <EBU-TT-D@list.ebu.ch> >>>>> >>>>> I agree the concepts of the line spacing and font height need to be >>>>> separately and clearly defined to allow implementations to be able to >>>>> render text as it's intended and to avoid the confusion you've described >>>>> John. I think this is what the TTML spec is trying to do by allowing >>>>> lineHeight and fontSize to be specified with a clear relationship. However >>>>> it falls short as you've pointed out. I'd propose the following remedial >>>>> steps, certainly in EBU-TT and hopefully in a future iteration of TTML: >>>>> >>>>> 1. State that we (TTML) assume that any presentation device will apply >>>>> appropriate rules to generate a font of the required size, regardless of >>>>> what algorithm is used either to scale or select a pre-defined font of a >>>>> similar size. >>>>> >>>>> The problem with the current TTML wording is that it says (inhttp://www.w3.org/TR/ttaf1-dfxp/#style-attribute-fontSize) both "font size >>>>> is interpreted as a scaling transform to the font's design EM square" and >>>>> "horizontal and vertical scaling of a glyph's em square" which seem to >>>>> conflict. Is it each individual glyph that should be scaled, or the entire >>>>> font? As I understand it the font has an em square and each glyph has it's >>>>> own width and height that may be different from the em square. >>>>> >>>>> 2. State that TTML assumes that the em square unit is a suitable line >>>>> spacing size for the chosen font, i.e. that it includes the ascent, >>>>> descent and extra space needed above and below, left and right. The >>>>> article http://www.microsoft.com/typography/otspec/TTCH01.htm includes a >>>>> good picture of this in the section headed "FUnits and the em square". >>>>> >>>>> I think both of these could be inferred from the current spec but by >>>>> making them explicit it would help to avoid the confusion. >>>>> >>>>> The result should be that each row in a cell grid is 1c and there's no >>>>> need for 80%s and 120%s here and there (unless a particular visual effect >>>>> squeezing or stretching the baseline spacing is desired!). >>>>> >>>>> Kind regards, >>>>> >>>>> Nigel >>>>> >>>>> >>>>> >>>>> -------- Original-Nachricht -------- Betreff: Re: [EBU-TT-D] Updated >>>>> list of proposed TTML features Datum: Wed, 3 Jul 2013 18:13:19 +0200 Von: >>>>> Andreas Tai <tai@irt.de> <tai@irt.de> An: John Birch >>>>> <John.Birch@screensystems.tv> <John.Birch@screensystems.tv> Kopie >>>>> (CC): EBU-TT-D@list.ebu.ch<EBU-TT-D@list.ebu.ch><EBU-TT-D@list.ebu.ch> >>>>> >>>>> Thanks for the comments, John. In general I think that we won´t >>>>> constrain the supported TTML feature list for EBU-TT-D. This is more about >>>>> a best practice recommendation. >>>>> >>>>> See further comments in-line. >>>>> >>>>> Best regards, >>>>> >>>>> Andreas >>>>> >>>>> >>>>> *From:* Andreas Tai [mailto:tai@irt.de <tai@irt.de>] >>>>> *Sent:* 02 July 2013 15:10 >>>>> *To:* John Birch >>>>> *Cc:* Nigel Megitt; EBU-TT-D@list.ebu.ch >>>>> *Subject:* Re: [EBU-TT-D] Updated list of proposed TTML features >>>>> >>>>> >>>>> >>>>> Hi John, >>>>> >>>>> I see some problem if both, font-size and line-height, are specified >>>>> explicitly . Given the uncertainties (e.g. the chosen font) from my view >>>>> there is a high probability of unwanted presentation. Worst case would be >>>>> that the lines overlap because of a font that is not appropriate for the >>>>> line-height. >>>>> >>>>> >>>>> >>>>> >> I see the opposite. By specifying both line height and font size >>>>> you are defining exactly the desired outcome. There is NO interpretation >>>>> possible. If the font size is less than the line height then the EM cell >>>>> must be smaller than the line height. If a ‘badly designed font’ where the >>>>> glyph exceeds the em square by a large amount is specified, then that >>>>> problem exists regardless of whether you are explicit about line height or >>>>> choose a value of ‘normal’. Fonts that exceed the em square are unlikely to >>>>> be used in subtitling, as (at least in my experience) they are usually >>>>> those that represent cursive styles. >>>>> >>>>> >>>>> >>>>> I am not sure if you would have problems in current CSS browser >>>>> implementations even if you have a "badly designed font". I would still >>>>> expect that the displayed font will not exceed the line. >>>>> >>>>> >>>>> To set the line-height to "normal" is a common solution in CSS and >>>>> the default value in CSS as in TTML. I therefore think that this concept >>>>> would be understood by the web community. Of course it will be far better, >>>>> if you had a reverse dependency: you set a fixed line-height and the >>>>> rendering machine has to choose the appropriate font/font-size to fit in >>>>> this line. But I do not expect that this will be chosen solution in future >>>>> editions of TTML or CSS. >>>>> >>>>> >>>>> >>>>> >> The problem is that CSS does not typically use a concept of >>>>> directly controlling line positions… the use of ‘normal’ effectively leaves >>>>> the line height up to the renderer, based on the font size and text >>>>> content. This is absolutely contrary to what is required for subtitling, >>>>> where the extent of the text MUST be controlled. >>>>> >>>>> I would not take this for granted. The input I get from our >>>>> broadcasters is that exact line-height and exact positions are no hard >>>>> requirements, while colours are of high importance. >>>>> >>>>> The fact that this effect is ‘understood by the community’ in >>>>> itself creates a problem. The community needs to re-understand that, in the >>>>> context of subtitling, controlling the exact text size and position is more >>>>> important. >>>>> >>>>> >>>>> I am sceptical about "educating" the web community. In the past (and >>>>> in the present) this was not very successful. What I get from our >>>>> discussions is that a good integration in HTML and CSS is important for >>>>> EBU-TT-D. I don´t think that these standards and implementations will worry >>>>> to much about specific subtitling and captioning requirements. >>>>> >>>>> I agree exactly, that shrinking to fit a line (or maybe a region) >>>>> would be far better, but this again is an unknown concept within CSS. In >>>>> fact I am not sure I would like this any better, since the likelihood is >>>>> that you would then get subtitles of varying text sizes throughout a >>>>> presentation. However, I’m pretty sure most implementations will support >>>>> line height values other than ‘normal’. >>>>> >>>>> As said above: I think both strategies (line-height = normal or choose >>>>> exact line-height) will be allowed in EBU-TT-D. >>>>> >>>>> >>>>> I agree, that we should not change mapping of the root container to >>>>> the size of the video. I think that this interpretation has become >>>>> accepted. From an interoperability perspective this is of high value : ) >>>>> >>>>> Yes, absolutely. >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Andreas >>>>> >>>>> Am 02.07.2013 14:16, schrieb John Birch: >>>>> >>>>> Hi Andreas, >>>>> >>>>> >>>>> >>>>> Yes, these are important considerations… For me, both the line height >>>>> and the font-size would be specified as percentages (the line height would >>>>> be slightly larger than the font-size). >>>>> >>>>> E.g. line height 7%, font size 6%. This would mean 12 rows of >>>>> characters would occupy 84% of the root container. Roughly equivalent to a >>>>> Teletext presentation. A 6% / 7% font to line ratio is approx. 116%. >>>>> >>>>> >>>>> >>>>> Personally I find the alternative approach to be more difficult to >>>>> comprehend. Particularly when you factor in the ‘safe area’ concept. >>>>> >>>>> If the cell resolution could be applied to a ‘super region’ (i.e. one >>>>> that could be defined as the safe area) then it might be more straight >>>>> forward. In other words conceptually the root container is not the full >>>>> extent of the active video… but I don’t really want to go there – you then >>>>> have problems when you want (and need) to write outside of the safe area >>>>> (e.g. speech marks). >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> *John Birch | Strategic Partnerships Manager | Screen >>>>> *Main Line : +44 1473 831700 <%2B44%201473%20831700> | Ext : 270 | >>>>> Direct Dial : +44 1473 834532 <%2B44%201473%20834532> >>>>> Mobile : +44 7919 558380 <%2B44%207919%20558380> | Fax : +44 1473 >>>>> 830078 <%2B44%201473%20830078> >>>>> John.Birch@screensystems.tv | www.screensystems.tv | >>>>> https://twitter.com/screensystems >>>>> >>>>> *Visit us at >>>>> SMPTE conference & exhibition, Stand G35, Sydney Exhibition Centre, >>>>> Darling Harbour, 23-26th July* >>>>> >>>>> *P** Before printing, think about the environment* >>>>> >>>>> >>>>> >>>>> *From:* Andreas Tai [mailto:tai@irt.de <tai@irt.de>] >>>>> *Sent:* 02 July 2013 12:32 >>>>> *To:* John Birch >>>>> *Cc:* Nigel Megitt; EBU-TT-D@list.ebu.ch >>>>> *Subject:* Re: [EBU-TT-D] Updated list of proposed TTML features >>>>> >>>>> >>>>> >>>>> I don´t want to let go cell resolution for EBU-TT-D so easily ; ) I >>>>> think there is value in this concept regardless of the legacy argument. For >>>>> font-size it gives you a tool to design a grid of lines and decide how many >>>>> lines you "intent" to address. After that you can choose the appropriate >>>>> font-size in relation to this grid. >>>>> >>>>> The height of the font-size matches not exactly 1c. The rows should >>>>> define the height of the line in the intended grid, not the height of the >>>>> font. >>>>> >>>>> An important use case will be to translate the values for line-height >>>>> and font-size to CSS. As in TTML the relationship between font-size and >>>>> line-height can be expressed in CSS through the value "normal" for >>>>> line-height. Then a line height that fits the font-size will be set through >>>>> the renderer (the browser in the case of CSS). The recommended line-height >>>>> in the CSS spec is 110 to 130% of the font-size. After some Browser tests I >>>>> found that a font-size of 0.8c or 80% would be a good choice so that the >>>>> grid will be filled but not extend the root container. >>>>> >>>>> This approach has some in computable variables (not only the concrete >>>>> font that is used for presentation but as well for HTML/CSS the browser >>>>> behaviour). Nevertheless I think this can be a good and transparent guide >>>>> to select a font-size that is independent from the size of the video and >>>>> preservers the concept of "lines". >>>>> >>>>> Best regards, >>>>> >>>>> Andreas >>>>> >>>>> >>>>> Am 02.07.2013 12:16, schrieb John Birch: >>>>> >>>>> I have no problem at all with retaining cell resolution and grid based >>>>> philosophies in Part 1 files… i.e. in archived exchanged subtitle files. >>>>> >>>>> Where I think the cell resolution grid strategy falls down is in the >>>>> delivered distribution format, where arguably having a single way of >>>>> expressing the presentation, in as simple a way as possible, is desirable. >>>>> >>>>> >>>>> >>>>> In my world there would (almost always) be a computer based conversion >>>>> *from Part 1 to EBU-TT-D*. This conversion is not (necessarily) >>>>> reversible. >>>>> >>>>> So, for example, we can translate from ‘cell resolution / grid’ into >>>>> ‘percentage of root container’ when we move from a (part 2 style) Part 1 >>>>> document to an EBU-TT-D document. >>>>> >>>>> A conversion away from mono spaced fonts might also be performed here >>>>> too. Loss of some metadata is expected. Addition of some metadata (e.g. >>>>> language track identification) might be necessary since although in the >>>>> Part 1 world we talk about an external asset management system, that may >>>>> not exist in the distribution context. >>>>> >>>>> >>>>> >>>>> Best, >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> *John Birch | Strategic Partnerships Manager | Screen >>>>> *Main Line : +44 1473 831700 <%2B44%201473%20831700> | Ext : 270 | >>>>> Direct Dial : +44 1473 834532 <%2B44%201473%20834532> >>>>> Mobile : +44 7919 558380 <%2B44%207919%20558380> | Fax : +44 1473 >>>>> 830078 <%2B44%201473%20830078> >>>>> John.Birch@screensystems.tv | www.screensystems.tv | >>>>> https://twitter.com/screensystems >>>>> >>>>> *Visit us at >>>>> SMPTE conference & exhibition, Stand G35, Sydney Exhibition Centre, >>>>> Darling Harbour, 23-26th July* >>>>> >>>>> *P** Before printing, think about the environment* >>>>> >>>>> >>>>> >>>>> *From:* Nigel Megitt [mailto:nigel.megitt@bbc.co.uk<nigel.megitt@bbc.co.uk>] >>>>> >>>>> *Sent:* 02 July 2013 10:56 >>>>> *To:* John Birch; Andreas Tai >>>>> *Cc:* EBU-TT-D@list.ebu.ch >>>>> *Subject:* Re: [EBU-TT-D] Updated list of proposed TTML features >>>>> >>>>> >>>>> >>>>> Hi John, >>>>> >>>>> >>>>> >>>>> Thanks for the welcome back! >>>>> >>>>> >>>>> >>>>> On the authoring for legacy argument I don't particularly *like* it >>>>> either but I think we have to recognise it as a stage that a lot of >>>>> adopters will feel they have to go through. If it looks as though they're >>>>> blocked at that stage they may never get any further. And if they're doing >>>>> that then they need to ensure that if the subtitles will be presented using >>>>> a mono-spaced font there is enough space to fit the text on each row. >>>>> Happily TTML supports mono-spaced fonts and there's been no suggestion so >>>>> far that we should remove this support. >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> >>>>> Nigel >>>>> >>>>> *--* >>>>> >>>>> >>>>> >>>>> *Nigel Megitt* >>>>> >>>>> Lead Technologist, BBC Technology, Distribution & Archives >>>>> >>>>> Telephone: +44 (0)208 0082360 <%2B44%20%280%29208%200082360> >>>>> >>>>> BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 02/07/2013 10:25, "John Birch" <John.Birch@screensystems.tv> wrote: >>>>> >>>>> >>>>> >>>>> Hi Nigel, >>>>> >>>>> >>>>> >>>>> Welcome back J >>>>> >>>>> >>>>> >>>>> Yep, definitely an elephant… and I agree that we should very much move >>>>> away from grid based mentalities. In fact I don’t really have much >>>>> ‘sympathy’ with the authoring for legacy argument, since realistically the >>>>> required constraints are in the number of characters a line and the number >>>>> of rows per screen. I don’t think there is a strong requirement for >>>>> retaining a mono-spaced font concept. >>>>> >>>>> >>>>> >>>>> In terms of multiples, 160 by 360 also works, (with a rather strange >>>>> higher resolution in the vertical dimension), giving a 4 by 9 cell for 40 x >>>>> 24, and a 5 by 15 cell for 32 by 15. >>>>> >>>>> >>>>> >>>>> Personally though,* for EBU-TT-D*, I actually favour a default cell >>>>> resolution of ‘1c 1c’ across the root container, and using (potentially >>>>> fractional) percentages for font size. *In effect this abandons grids >>>>> altogether.* >>>>> >>>>> * * >>>>> >>>>> I completely agree with your comment on font selection. I believe an >>>>> implementation should be guide to choose a closest fit font ‘point size’ >>>>> that fits the scaled font box, even if it is ‘slightly’ smaller or larger >>>>> than calculated. >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> *John Birch | Strategic Partnerships Manager | Screen >>>>> *Main Line : +44 1473 831700 <%2B44%201473%20831700> | Ext : 270 | >>>>> Direct Dial : +44 1473 834532 <%2B44%201473%20834532> >>>>> Mobile : +44 7919 558380 <%2B44%207919%20558380> | Fax : +44 1473 >>>>> 830078 <%2B44%201473%20830078> >>>>> John.Birch@screensystems.tv | www.screensystems.tv | >>>>> https://twitter.com/screensystems >>>>> >>>>> *Visit us at >>>>> SMPTE conference & exhibition, Stand G35, Sydney Exhibition Centre, >>>>> Darling Harbour, 23-26th July* >>>>> >>>>> *P** Before printing, think about the environment* >>>>> >>>>> >>>>> >>>>> *From:* Nigel Megitt [mailto:nigel.megitt@bbc.co.uk<nigel.megitt@bbc.co.uk>] >>>>> >>>>> *Sent:* 02 July 2013 10:05 >>>>> *To:* John Birch; Andreas Tai >>>>> *Cc:* EBU-TT-D@list.ebu.ch >>>>> *Subject:* Re: [EBU-TT-D] Updated list of proposed TTML features >>>>> >>>>> >>>>> >>>>> It's been interesting to read this thread on returning from holiday. A >>>>> few thoughts from me: >>>>> >>>>> ? The 'elephant in the room' that everyone has been politely >>>>> avoiding is that the cell resolution grid is derived from pre-existing >>>>> standards that carry the emotional baggage of 'this is what we're used to >>>>> and therefore like'. In the US it was convenient to choose one cell >>>>> resolution, presumably to make translating from existing documents easier >>>>> (I don't know the exact reasons). In much of the rest of the world a >>>>> different cell resolution has historically been used, so the US choice is >>>>> somewhat less convenient. If we're interested in driving adoption then we >>>>> have to understand the negative impact of sticking with the US resolution >>>>> as a default, especially if we then put barriers in the way to changing it >>>>> on a document by document basis. The simple maths described earlier shows >>>>> that this is not a technical issue but a perception problem. >>>>> >>>>> ? However there is also a technical problem: If authors also >>>>> wish to use cell resolution for positioning, perhaps to make downstream >>>>> conversion to teletext subtitles straightforward (still likely to be in use >>>>> in a lot of countries for several years), then the choice of cell >>>>> resolution becomes a significant constraint. In this case the 32 by 15 grid >>>>> would be very unhelpful indeed for anyone targeting a 40 by 24 grid >>>>> downstream. Similarly it would be inconvenient the other way around. I >>>>> think we do need to consider this 'stepping stone' use case even though >>>>> it's not where we want to end up, i.e. without the dependency on legacy >>>>> representations for subtitles. >>>>> >>>>> ? Three strategies that might make it equally convenient for >>>>> both 'histories' are, in no particular order: >>>>> >>>>> o A) Create a new initial cell resolution that has integer >>>>> multiples of both current grids, which would be 32x40 by 15x24 = 1280 by >>>>> 360, to allow an equally complex or simple mapping from whatever prior >>>>> standard has been in use, anywhere. >>>>> >>>>> o B) Abandon grids altogether and relate font size directly to the >>>>> root container dimension. This would make the 'stepping stone' use case >>>>> described above more complicated but still feasible. >>>>> >>>>> o C) Require the cell grid to be explicitly specified if used >>>>> directly or by implication, i.e. make the concept of initial value carry no >>>>> meaning. So if fontSize is not specified, a cell resolution for the root >>>>> container *must* be specified, or alternatively is a fontSize is >>>>> specified by not in units of c and cell resolution is not used for >>>>> positioning purposes elsewhere in the document then the cell resolution may >>>>> be omitted as it isn't used anywhere. >>>>> >>>>> ? I can't see how in a global context we could require that >>>>> the root cell resolution is only permitted to have a single value, be it 32 >>>>> by 15 or 40 by 24 or anything else, except perhaps for 1 by 1 as the >>>>> mechanism for abandoning grids altogether. >>>>> >>>>> Something else to note: >>>>> >>>>> ? Typographical scaling of fonts is not straightforward, and >>>>> can't be done linearly without impacting readability: the use of >>>>> percentages suggests that an implementation might use a single master font >>>>> and scale it. We should be clear that, regardless of the mechanism for >>>>> specifying the EM-square size (ultimately to be in pixels), the font size >>>>> is a guide for the implementation to select an appropriate font to fit that >>>>> box. >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> >>>>> Nigel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------ >>>>> 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 | Email: tai@irt.de >>>>> ------------------------------------------------ >>>>> >>>>> registration court& managing director: >>>>> Munich Commercial, RegNo. B 5191 >>>>> Dr. Klaus Illgner-Fehns >>>>> ------------------------------------------------ >>>>> >>>>> >>>> >>>> >>>> ---------------------------- >>>> >>>> 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. >>>> >>>> --------------------- >>>> >>> >>> >>> >>> ---------------------------- >>> >>> 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. >>> >>> --------------------- >>> >> >> >> >> ---------------------------- >> >> 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. >> >> --------------------- >> > > > > ---------------------------- > > 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. > > --------------------- > > > > -- > ------------------------------------------------ > 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 | Email: tai@irt.de > ------------------------------------------------ > > registration court& managing director: > Munich Commercial, RegNo. B 5191 > Dr. Klaus Illgner-Fehns > ------------------------------------------------ > >
Received on Wednesday, 17 July 2013 16:52:01 UTC