- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Wed, 17 Jul 2013 07:39:02 +0000
- To: Glenn Adams <glenn@skynav.com>
- CC: Andreas Tai <tai@irt.de>, public-tt <public-tt@w3.org>, John Birch <John.Birch@screensystems.tv>, Pierre-Anthony Lemieux <pal@sandflow.com>
- Message-ID: <CE0C0884.F512%nigel.megitt@bbc.co.uk>
On 16/07/2013 17:49, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote: On Tue, Jul 16, 2013 at 10:25 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote: Current wording in 8.2.12 tts:lineHeight: If the value of this attribute is normal, then the initial value of the style property must be considered to be the same as the largest font size that applies to any descendant element. Suggested wording, taking into account the previous amendment on this thread: If the value of this attribute is normal, then the initial value of the style property must be considered to be the same as the height of the largest em square of the fonts that apply to any descendant element in the intermediate synchronic document instance. Sounds reasonable, though better to say "the maximum height of the EM squares of the fonts that apply" Thanks, yes, that's better. Add a note: If lineHeight is normal and a font is selected for presentation with an em square whose height does not include ascents, descents and any other spacing needed for creating a default line spacing then the resulting text is likely to be difficult to read. Sounds reasonable. I will make these changes in the 10SE ED and the 11 ED. Thanks. Nigel On 16/07/2013 17:08, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote: On Tue, Jul 16, 2013 at 9:51 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote: CIL On 16/07/2013 16:26, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote: On Tue, Jul 16, 2013 at 8:47 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto: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. 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<mailto:glenn@skynav.com>> wrote: On Tue, Jul 16, 2013 at 7:09 AM, Andreas Tai <tai@irt.de<mailto: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><mailto:nigel.megitt@bbc.co.uk> An: John Birch <John.Birch@screensystems.tv><mailto:John.Birch@screensystems.tv>, Andreas Tai <tai@irt.de><mailto:tai@irt.de>, "EBU-TT-D@list.ebu.ch"<mailto:EBU-TT-D@list.ebu.ch> <EBU-TT-D@list.ebu.ch><mailto: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><mailto:tai@irt.de> An: John Birch <John.Birch@screensystems.tv><mailto:John.Birch@screensystems.tv> Kopie (CC): EBU-TT-D@list.ebu.ch<mailto:EBU-TT-D@list.ebu.ch><EBU-TT-D@list.ebu.ch><mailto: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] Sent: 02 July 2013 15:10 To: John Birch Cc: Nigel Megitt; EBU-TT-D@list.ebu.ch<mailto: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<tel:%2B44%201473%20831700> | Ext : 270 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532> Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078> John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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] Sent: 02 July 2013 12:32 To: John Birch Cc: Nigel Megitt; EBU-TT-D@list.ebu.ch<mailto: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<tel:%2B44%201473%20831700> | Ext : 270 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532> Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078> John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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] Sent: 02 July 2013 10:56 To: John Birch; Andreas Tai Cc: EBU-TT-D@list.ebu.ch<mailto: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<tel:%2B44%20%280%29208%200082360> BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP On 02/07/2013 10:25, "John Birch" <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> wrote: Hi Nigel, Welcome back ☺ 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<tel:%2B44%201473%20831700> | Ext : 270 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532> Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078> John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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] Sent: 02 July 2013 10:05 To: John Birch; Andreas Tai Cc: EBU-TT-D@list.ebu.ch<mailto: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<tel:%2B49%2089%2032399-389> | Fax: +49 89 32399-200<tel:%2B49%2089%2032399-200> http: www.irt.de<http://www.irt.de> | Email: tai@irt.de<mailto:tai@irt.de> ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------ ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. --------------------- ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. --------------------- ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. --------------------- ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ---------------------
Received on Wednesday, 17 July 2013 07:39:37 UTC