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

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