- From: Andreas Tai <tai@irt.de>
- Date: Thu, 22 Aug 2013 15:54:50 +0200
- To: Glenn Adams <glenn@skynav.com>
- CC: public-tt@w3.org
- Message-ID: <5216182A.2050904@irt.de>
Thanks for this very profound discussion on this issue. We now had a couple of discussions about font selection, font size and line-height and quite some typographic expertise is needed to answer these questions. That fact that questions pop up means that still some guidance is needed. I wonder how much the semantic formatting model of TTML, XSL 1.1 (XSL:FO ), can be the reference. Although XSL:FO is not an "easy to consume" specification it is a well established standard in the print industry and has a clear mapping to CSS. If this spec can be taken as reference some test rendering can be implemented with xsl:fo formatters (e.g. FOP [1]) or with CSS rendering in the browser. The later would also help the HMTL 5 mapping. Best regards, Andreas [1] http://xmlgraphics.apache.org/fop/ Am 20.08.2013 16:48, schrieb Glenn Adams: > Almost. See corrections/comments inline below. > > > On Tue, Aug 20, 2013 at 1:58 AM, De Muyter, Yves (Contractor) > <Yves.DeMuyter@eu.sony.com <mailto:Yves.DeMuyter@eu.sony.com>> wrote: > > I can make following conclusion: > > used tts:fontSize=”75%” > > default tts:fontSize=”1c” > > cellResolution=”16 32” > > > Keep in mind that the default cellResolution is "32 15", meaning 32 > columns and 15 rows. Columns is specified first, rows second. I will > assume that in this example you are specifying a non-default cell > resolution and that you reversed the values, i.e., you should have > said "32 16" if you meant 32 columns and 16 rows. > > tt extend=”640px 480px” > > > I assume that here you mean tts:extent="640px 480px" on the root <tt/> > element. > > scaleH = scaling factor to scale emH to 480/16 ( = 1c height ) > > > It would be better to restate this as follows: > > (1) tts:fontSize="75%" (on some content element E) is resolved to a > computed value of 22.5px as follows: > > * if the region R into which E is select in a synchronic > intermediate document does not specify a font size, then the > initial value of 1c applies to the region R, and, as a > consequence, the computed value of fontSize on R is 30px (480px/16); > * every other ancestor A of E up to (but not including) R, inherits > this value of 30px to form the computed value of fontSIze for A > (provided A does not specify a font size itself); > * the value 75% on E is resolved according to its immediate ancestor > A', to 30px * 75% = 22.5px; > > (2) scaleH = scaling factor to scale emH to 22.5px; > > font height: (scaleH * emH) * 75% > > font width: (*scaleH* * emW) * 75% > > > Given the above, best restate this as: > > (1) computed font height of E: 22.5px > (2) computed font width of E: 22.5px > (3) scale font isomorphically so that EM square is 22.5px in height > > where emH = em height and em W = em width, the constants from the > font chosen. > > Is it so that if I would use tts:fontSize=”75% 75%”, it would > mathematically mean it’s deducted from a default that is > tts:fontSize=”1c 1c” and hence have following formulas ? > > scaleW = scaling factor to scale emW to 640/32 ( = 1c width ) > > font height: (scaleH * emH) * 75% > > font width: (scaleW * emW) * 75% > > > Using the above corrections, this would be best stated as: > > (1) computed font height of E: 22.5px > (2) computed font width of E: 15px > (3) scale font anamorphically so that EM square is 22.5px in height > and 15px in width > > Thanks > > Yves > > *From:*Glenn Adams [mailto:glenn@skynav.com > <mailto:glenn@skynav.com>] > *Sent:* 19 August 2013 17:45 > *To:* Nigel Megitt > *Cc:* De Muyter, Yves (Contractor); public-tt@w3.org > <mailto:public-tt@w3.org> > *Subject:* Re: fontSize and percentages > > On Mon, Aug 19, 2013 at 8:19 AM, Nigel Megitt > <nigel.megitt@bbc.co.uk <mailto:nigel.megitt@bbc.co.uk>> wrote: > > Yves' question has highlighted that there's ambiguity in the > current spec. Before we raise this as an issue is there some > wording I've missed that says that EM cell aspect ratio should be > preserved when one length specification is provided? > > This is equivalent to saying "If a single <length> > <http://www.w3.org/TR/ttaf1-dfxp/#style-value-length> value is > specified, then this length applies equally to horizontal and > vertical scaling of a glyph's EM square". > > My search yielded zero results. > > For reference, my understanding of the words as currently > written in 8.2.9 is as follows: > > * When length is specified in percentage, this is (as in the > table in 8.2.9) "relative to parent element's font size, > or if no parent element, then relative to the /Computed > Cell Size"/ > * In this example there's no parent element font size so > it's relative to the cell size, which is 20px (width) x 32 > px (height). > > When you say "it's relative", it refers only to the process of > resolving percentage specifications. It does not imply that the EM > cell is the same as the TTML cell size, and also doesn't imply > anything about the aspect ratio of the EM cell. > > See the note in 6.2.1: > > "The use of a uniform grid is employed only for the purpose of > measuring lengths and expressing coordinates. In particular, it is > not assumed that the presentation of text or the alignment of > individual glyph areas is coordinated with this grid. Such > alignment is possible, but requires the use of a monospaced font > and a font size whose EM square exactly matches the cell size." > > * This sets the 100% size of the glyph's EM square, which in > this case is not square but rectangular. [I suspect this > is the point of divergence in the interpretation] > > I'm not exactly sure what you mean by "this" in "This sets ...". > > In the case of outline fonts, the EM square is always square. In > font files, e.g., OpenType, the EM square is associated with a > coordinates space by specifying a resolution on this square, for > OTF, this is unitsPerEm, defined in the 'head' table [1]. > > This resolution is always uniform in both dimensions. In many > Postscript based fonts, this is specified as 1000. In many > OpenType and TrueType fonts, this is specified as 2048; however, > the number can vary from 16 to 16384, as determined by font > designer. Each glyph's outline is specified in coordinates within > this coordinate space (but notes that outline points are not > constrained to be interior to the EM square). > > [1] http://www.microsoft.com/typography/otspec/head.htm > > In the case of bitmap fonts, one may have a non-square "EM > square", though here, the EM square is generally associated with a > font bounding box, whose width and height can be construed as the > EM square. For example, one might have for a BDF font [2] the > following: > > FONTBOUNDINGBOX 16 16 0 -2 > > [2] http://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format > > Here, one could create a double height font using a bounding box > of, say: > > FONTBOUNDINGBOX 16 32 0 0 > > or one that corresponds to the example "cell size" in this thread: > > FONTBOUNDINGBOX 15 24 0 0 > > So, let's say we are using a bitmap font whose bounding box is > 16px by 16px (square) with this example file whose cell size is > 15px by 32px (non-square). Then a fontSize="75%" is the same as > specifying font size of (32px * 75%) 24px. So, we need to scale > this font by (24/16) 150% in both width and height. > > Let's say that instead we had specified fontSize="75% 75%", then > this is the same as specifying of (15px * 75%) 11px (rounding to > nearest integer) width and (32px * 75%) 24px height, i.e., the > same as fontSize="11px 24px". So, we need to scale this font by > (11/16) 68.75% in width and (24/16) 150% in height. > > So, we have: > > fontSize="75%" : scale(24/16,24/16) : scale(150%,150%) > > fontSize="75% 75%" : scale(11/16,24/16) : scale(69%,150%) > > If instead, we used a bitmap font whose bounding box is 7px by > 16px (non-square), then we would arrive at: > > fontSize="75%" : scale(24/16,24/16) : scale(150%,150%) > > fontSize="75% 75%" : scale(11/7,24/16) : scale(157%,150%) > > * The wording "If a single <length> > <http://www.w3.org/TR/ttaf1-dfxp/#style-value-length> > value is specified, then this length applies equally to > horizontal and vertical scaling of a glyph's EM square" > for a percentage means that the same percentage scaling is > applied to both dimensions. > * The note "The expression |1c|means one cell, where > |'c'|expresses the /cell/ length unit as defined by *8.3.9 > <length>* > <http://www.w3.org/TR/ttaf1-dfxp/#style-value-length>. > When a single <length> is expressed using cell units, then > it refers to the height of the /Computed Cell Size/." does > /not/ apply because the length is expressed in percentages > not cell units. > * Therefore the width is 640/32 * 75%. > > I'd also note that I agree that the desired behaviour should > primarily be to select a font with the required height (or as > close to it as possible) and if any scaling is to be applied, > do so equally in both dimensions if the scaling factor is the > same in both dimensions, regardless of whether one or two > values are provided. > > No. If two values are specified, then scaling is independent in > width and height. > > The wording in 8.3.9 is perhaps a model for this: "When > specified relative to a font whose size is expressed as a > single length measure or as two length measures of equal > length, the unit of measure |em|is considered to be identical > to that defined by [XSL 1.1] > <http://www.w3.org/TR/ttaf1-dfxp/#xsl11>, § 5.9.13; however, > when specified relative to a font whose size is expressed as > two length measures of non-equal lengths, then one |em|is > equal to the inline progression dimension of the > anamorphically scaled font when used to specify lengths in the > inline progression direction and equal to the block > progression dimension of the scaled font when used to specify > lengths in the block progression direction." > > This text is correct, and defines how to interpret the meaning of > the 'em' unit in accordance to whether it applies in width or height. > > One could argue that the first paragraph in 8.2.9 sets up this > problem: > > The |tts:fontSize|attribute is used to specify a style > property that defines the font size for glyphs that are > selected for glyph areas generated by content flowed into a > region. > > Perhaps rewording this to be: > > The |tts:fontSize|attribute is used to specify a style > property that defines the desired font size for selecting and > scaling glyphs that are selected for glyph areas generated by > content flowed into a region. Where > |tts:fontSize| is non-anamorphic, i.e. has the same computed > value for height and width, glyphs should be selected > primarily to match as closely as possible their height to the > computed value, and any scaling should preserve the ratio of > height to width for each glyph. > > I'm not seeing a problem here. Perhaps your misunderstanding came > from an incorrect association with computed cell size and em > square, since I notice you didn't quote the language I noted from > 6.2.1 above. > > would remove the issue? > > Nigel > > On 19/08/2013 14:08, "Glenn Adams" <glenn@skynav.com > <mailto:glenn@skynav.com>> wrote: > > On Mon, Aug 19, 2013 at 5:11 AM, Nigel Megitt > <nigel.megitt@bbc.co.uk <mailto:nigel.megitt@bbc.co.uk>> > wrote: > > Hi Yves, > > The draft text for the next edition of the specification, > at > http://www.w3.org/TR/ttaf1-dfxp/#style-attribute-fontSize includes > a note that hopefully answers your question, as well as > making clear that when only one length value is specified > it applies equally to horizontal and vertical scaling, and > is proportional to the cell size when specifed as a > percentage. > > The answer to your first question is yes, the width is > 640/32 * 75% = 15. > > Actually, this is wrong, since it doesn't preserve EM cell > aspect ratio. If there is one length specification, it > applies uniformly to both dimensions, however, the > resolution of a percentage size is in accordance only with > the height of a cell (if resolved related to a cell unit). > > So, for example, if the intrinsic size of an EM square is > 1px (width) x 1px (height), then your example would scale > this EM square to 24px (width) x 24px (height). > > On the other hand, if you specified fontSize="75% 75%", > then this would scale the EM square to 15px (width) x 24px > (height). > > The relevant spec language is at 8.2.9: > > If a single <length> > <https://dvcs.w3.org/hg/ttml/raw-file/default/ttml10/spec/ttaf1-dfxp.html#style-value-length> value > is specified, then this length applies equally to > horizontal and vertical scaling of a glyph's EM square; if > two <length> > <https://dvcs.w3.org/hg/ttml/raw-file/default/ttml10/spec/ttaf1-dfxp.html#style-value-length> values > are specified, then the first expresses the horizontal > scaling and the second expresses vertical scaling. > > Non-proportional scaling is the expected behaviour to > allow font sizes that are 2 rows in height and 1 > column in width to be denoted. > > Nigel > > ------------------------------------------------------------------------ > > *From:*Nigel Megitt > *Sent:* 19 August 2013 12:02 > *To:* De Muyter, Yves (Contractor); public-tt@w3.org > <mailto:public-tt@w3.org> > *Subject:* RE: fontSize and percentages > > ------------------------------------------------------------------------ > > *From:*De Muyter, Yves (Contractor) > [Yves.DeMuyter@eu.sony.com > <mailto:Yves.DeMuyter@eu.sony.com>] > *Sent:* 19 August 2013 08:30 > *To:* public-tt@w3.org <mailto:public-tt@w3.org> > *Subject:* fontSize and percentages > > Hello, > > I have a question regarding percentages on fontSize > and having 1 or 2 values on the tts:fontSize attribute. > > Given this example (some unneeded attributes are > omitted for readability): > > <tt tts:extent="640px 480px" ttp:cellResolution="32 15"> > > <head> > > <layout> > > <region xml:id="r1" tts:fontFamily="monospace" > tts:fontSize="75%"> > > </layout> > > </head> > > <body> > > <div region="r1"> > > <p>This is text</p> > > </div> > > </body> > > </tt> > > It means the height of the fontsize is 480/15 * 75% = 24 > > Does it also mean the width of the fontsize is 640/32 > * 75% = 15 ? > > Or does it mean we need to use the scaling value of > the height and apply that equally to the width to have > proportional scaling ? The spec doesn¹t clearly say > that having a single scaling factor means you need to > have proportional scaling, that¹s why I¹m hesitating > right now for this detail. > > Yves De Muyter > > Techsoft Centre > > Technology and Software Centre Europe (TSCE) > > *Sony Belgium, bijkantoor van Sony Europe Ltd.* > > The Corporate Village Da Vincilaan 7-D1 B-1935 > Zaventem Belgium > > E-mail: Yves.DeMuyter@eu.sony.com > <mailto:Vincent.Gaillez@eu.sony.com> > > Internet: www.sony-europe.com > <http://www.sony-europe.com/> > > Sony Europe Limited. A company registered in England > and Wales. > > Registered Address: The Heights, Brooklands, > Weybridge, Surrey, KT13 0XW, United Kingdom. > > Bank Account Details: > > Account Name: Sony Europe Limited € Account number: > 624335508 € IBAN: BE63570624335508 > > BIC: CITIBEBX € RPR Brussel / RPM Bruxelles: > 0452161045 € VAT: BE0452161045 > > cid:image001.jpg@01CA1A63.F11B40A0 > > > ************************************************************************ > The information contained in this message or any of > its attachments may be confidential and is intended > for the exclusive use of the addressee(s). Any > disclosure, reproduction, distribution or other > dissemination or use of this communication is strictly > prohibited without the express permission of the > sender. The views expressed in this email are those of > the individual and not necessarily those of Sony or > Sony affiliated companies. Sony email is for business > use only. This email and any response may be monitored > by Sony to be in compliance with Sony's global > policies and standards > > ---------------------------- > > 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. > > --------------------- > > > ************************************************************************ > The information contained in this message or any of its > attachments may be confidential and is intended for the exclusive > use of the addressee(s). Any disclosure, reproduction, > distribution or other dissemination or use of this communication > is strictly prohibited without the express permission of the > sender. The views expressed in this email are those of the > individual and not necessarily those of Sony or Sony affiliated > companies. Sony email is for business use only. This email and any > response may be monitored by Sony to be in compliance with Sony's > global policies and standards > > -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389 | Fax: +49 89 32399-200 http: www.irt.de | Email: tai@irt.de ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------
Received on Thursday, 22 August 2013 13:56:21 UTC