Re: Interdependency between fontSize, lineHeight and cellResolution in TTML

On Tue, Jul 16, 2013 at 9:34 AM, John Birch <John.Birch@screensystems.tv>wrote:

>  Re: Rather, TTML assumes the author will choose a font that works for
> their purposes****
>
> ** **
>
> Unfortunately in some cases it is the browser that makes this choice!
>

Actually, that is always the case, since we don't define a normative
mapping from either generic or non-generic font families to device fonts.
So my above statement was a bit tongue in cheek I'm afraid.


> ****
>
> In essence therein lies the problem! A mechanism to refer to a font that
> can be downloaded would be useful to ensure that the correct (author
> chosen) font is used.
>

Barring us defining a very specific mapping, e.g., *default* must map to
Tiresias, etc., then that would be the only way to guarantee some degree of
certainty.


> ****
>
> ** **
>
> 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:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* 16 July 2013 16:26
> *To:* Nigel Megitt
> *Cc:* Andreas Tai; public-tt; John Birch; Pierre-Anthony Lemieux
> *Subject:* Re: Interdependency between fontSize, lineHeight and
> cellResolution in TTML****
>
> ** **
>
> ** **
>
> 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 (in****
>
> http://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. ****
>
>   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.****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> Ultimately, we may wish to consider adding support for referring to
> downloaded font resources.****
>
> ** **
>
>   ** **
>
> 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 (in****
>
> http://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.****
>
> ---------------------****
>
>  ** **
>
>  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
>    ­­
>