- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 19 Aug 2013 09:45:05 -0600
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: "De Muyter, Yves (Contractor)" <Yves.DeMuyter@eu.sony.com>, "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <CACQ=j+cKEmWCCwUGYbK-150j1NtBB5sGn-mBERLoxMfwJiViDw@mail.gmail.com>
On Mon, Aug 19, 2013 at 8:19 AM, Nigel Megitt <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> wrote: > > > > > On Mon, Aug 19, 2013 at 5:11 AM, Nigel Megitt <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 >> *Subject:* RE: fontSize and percentages >> >> ------------------------------ >> *From:* De Muyter, Yves (Contractor) [Yves.DeMuyter@eu.sony.com] >> *Sent:* 19 August 2013 08:30 >> *To:* 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<Vincent.Gaillez@eu.sony.com> >> >> Internet: 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 >> >> >> >> >> >> [image: 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. > > --------------------- >
Attachments
- image/jpeg attachment: image001.jpg
Received on Monday, 19 August 2013 15:45:54 UTC