Re: Interdependency between fontSize, lineHeight and cellResolution in TTML

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"

>
>  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.


>
>  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 | Ext : 270 | Direct Dial : +44 1473
>>>> 834532
>>>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>>> 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 | Ext : 270 | Direct Dial : +44 1473
>>>> 834532
>>>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>>> 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****
>>>>
>>>> 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 | Ext : 270 | Direct Dial : +44 1473
>>>> 834532
>>>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>>> 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.
>
> ---------------------
>