Re: Comments on the WOFF 2.0 Working Draft 9 October 2015
Frédéric WANG <[email protected]> Mon, 02 Nov 2015 23:33:57 +0100
| Newsgroups | gmane.comp.web.fonts |
|---|---|
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Hdvmj8V3sQbUo1cMTidMisCDVbexw9oWi Content-Type: multipart/alternative; boundary="------------050101010607050201020102" This is a multi-part message in MIME format. --------------050101010607050201020102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you for your reply and for updating the draft. I actually had found one more typo: > Fo more details on table order constraints see subclause 5.5. This should be "For" Le 02/11/2015 23:18, Levantovsky, Vladimir a =C3=A9crit : > > Dear Fr=C3=A9d=C3=A9ric, > > =20 > > Thank you very much for taking the time to review the WOFF2 spec and > providing your comments, please see the disposition notes inline. The > most recent version of the Editor=E2=80=99s Draft WOFF2 specification i= s > available at http://dev.w3.org/webfonts/WOFF2/spec/ > <http://dev.w3.org/webfonts/WOFF2/spec/> and the implemented changes > are at > http://dev.w3.org/cvsweb/webfonts/WOFF2/spec/Overview.html.diff?r1=3D1.= 69;r2=3D1.70;f=3Dh > > =20 > > With kind regards, > > Vladimir > > =20 > > =20 > > *From:*Fr=C3=A9d=C3=A9ric WANG [mailto:[email protected]] > *Sent:* Sunday, October 18, 2015 4:20 PM > *To:* [email protected] > *Subject:* Comments on the WOFF 2.0 Working Draft 9 October 2015 > > =20 > > Dear WebFonts Working Group, > > Please find below my personal comments after a first reading of the > WOFF 2.0 specification (without any attempts to implement it). I hope > they will be helpful. > > Cheers, > > Fr=C3=A9d=C3=A9ric Wang > > > The input font file may contain a number of various font data tables > described in the clause 5 of the [OFF] specification. > > Could you please update the reference link to use edition 3 of the > Open Font Format specification now that it is released? Especially > since the new MATH table is mentioned in the "Known Table Tags". > > [VL] Accepted, the link was updated to point to the 2015 (3^rd > edition) of the ISO document. > > =20 > > File header with basic font type and version, along with offsets to > metadata and private data blocks. > An optional block of extended metadata, represented in XML format and > compressed for storage in the WOFF2 file.=20 > > There are new lines after "private" and after "compressed". I'm not > sure whether it's on purpose. > > [VL] Edited to remove them. > > =20 > > The pseudo-code describing how to read the 255UInt16 format is > presented below: > > I think it should be mentioned that this is "C-like" pseudo-code to > make clear that bitwise operators <<, & are used. > > [VL] Accepted > > > In general maybe it should probably be said somewhere in the > introduction that the "0x..." notations used everywhere in this > specification correspond to hexadecimal values. > > [VL] Accepted > > =20 > > An encoder should choose shorter encodings, and must be consistent in > choice of encoding for the same value, as this will tend to compress > better. > > I have the impression that the specification should explicitly provide > a way to get a shortest encoding. For example some pseudo code > describing the following transformation: > > 0 =E2=89=A4 value < lowestUCode ---> [value on 1 byte] > > lowestUCode =E2=89=A4 value < 2*lowestUCode ---> [oneMoreByteCode1][val= ue - > lowestUCode on 1 byte] > > 2*lowestUCode =E2=89=A4 value < 2*lowestUCode + 256 ---> > [oneMoreByteCode2][value - 2*lowestUCode on one byte] > > value =E2=89=A5 2*lowestUCode + 256 ---> [wordCode][value on 2 bytes] > > Actually, this is probably insignificant but I wonder why > [oneMoreByteCode2][code] is not interpreted as lowestUCode + 256 + > code so that code1 & code2 encodings won't overlap. Does the encoding > proposed in the spec tend to compress better? > > [VL] Deferred for WG discussion > > =20 > > Thus, a decoding procedure for a UIntBase128 is: start with value =3D 0= =2E > Consume a byte, setting value =3D old value times 128 + (byte > bitwise-and 127). Repeat last step until the most significant bit of > byte is false. > > I personally feel that this paragraph would be better presented with > pseudo-code. > > An encoder must not allow this to happen and must produce shortest > possible encoding. > > Here too I believe there should be some simple pseudo-code to explain > the canonical & optimal way to write the 32bits of the integer on at > most five 7-bit blocks (even if that's obvious once you think about it)= =2E > > [VL] Deferred for WG discussion > > =20 > > The interpretation of the WOFF2 Header is the same as the WOFF Header > in [WOFF1]. > > Maybe it should be highlighted that the only new field with respect to > WOFF version 1 is totalCompressedSize? > > [VL] Accepted > > =20 > > The font directory section consist of > > consists > > [VL] Fixed, thank you > > =20 > > Whether a table tag is encoded with a known table tag or explicitly > including the four-byte tag has no semantic significance; it is simply > a choice of encoding intended to improve compression efficiency. > > The known table flag values should not be relied upon in > determining the presence of the transformed tables, it is feasible > that e.g. the glyf table can be represented in the table directory > with either flag =3D 10 and no tag, or with flag =3D 63 and 'glyf' = tag > that follows. > > I wonder why the encoder is not forced to use the known flag when it > is available for a table? Of course the size gain is negligible and > the table directory is not compressed anyway, but that would be > consistent with other places of the spec where it tries to get the > optimal encoding when possible. > > [VL] Deferred for WG discussion > > =20 > > if the table is transformed, then the version number of the applied > transform is defined by the two most significatn flag bits > > significant > > [VL] Fixed, thank you > > =20 > > The decompressed and reconstructed table data MUST be stored in the > format specified by the [OFF] specification. Each reconstructed table > directory entry MUST contain a valid 'checkSum' value, the decoder > MUST recalculate the checkSum value for each decoded table. Also, due > to modifying transforms applied to glyf and loca tables, the decoder > MUST recalculate the checkSumAdjustmentglyf value of the entire font > and MUST store the updated value in the head table. > > "checkSumAdjustmentglyf" should be "checkSumAdjustment", I guess. > > [VL] Fixed, thank you > > > I find that this paragraph is a bit confusing. It seems to suggest > that only the checkSumAdjustment may change and that it is only 'due > to modifying transforms applied to glyf and loca tables'. At the same > time it seems to ask the decoders to recalculate all the checksums > without any verification for possible unchanged checksums. > > My understanding is that only transformed tables that can not be > reconstructed identically to the original will have the checksum > invalidated (i.e. 'glyf' and 'loca' but not 'hmtx' or other tables). > And that in general the overall checkSumAdjustment will be > invalidated. Is that correct? > > [VL] Yes, this is correct. > > > The possible binary changes are better explained in the "The WOFF 2.0 > transformations applied to certain tables...." paragraph below that > one, maybe this section should be reordered a bit or this > decoder+checksum paragraph should point to the paragraph below? > > Why isn't the decoder asked to verify the checksum that are guaranteed > to be preserved and to just recalculate everything? Is it a > requirement of the OFF specification when bit 11 of the 'flags' field > of the head is set? > > [VL] Deferred for WG discussion > > The total number of bytes in bboxBitmap is equal to 4 * ((numGlyphs + > 31) / 32). > > Again, C integer-division is implicit here. I would suggest writing "4 > * =E2=8C=8A (numGlyphs + 31) / 32 =E2=8C=8B" or even better if you want= to enhance > rendering in some web engines and assistive technologies: > > <math><semantics><mrow><mn>4</mn><mrow><mo>=E2=8C=8A</mo><mfrac><mrow><= mtext>numGlyphs</mtext><mo>+</mo><mn>31</mn></mrow><mn>32</mn></mfrac><mo= >=E2=8C=8B</mo></mrow></mrow><annotation > encoding=3D"text/plain">4 * =E2=8C=8A (numGlyphs + 31) / 32 > =E2=8C=8B</annotation></semantics></math> > > 4=E2=8C=8AnumGlyphs+3132=E2=8C=8B4 * =E2=8C=8A (numGlyphs + 31) / 32 =E2= =8C=8B > > [VL] I modified the notation to reflect the nature of implicit integer > division. > > Upon reading the Transformed glyf Table , the decoding process > iterates one glyph at a time. For each glyph, it reads zero or more > bytes from each of the streams referenced in the Transformed glyf Table= . > > There are extra spaces before the comma and the period. > > [VL] Fixed, thank you > > =20 > > FLAG_MORE_COMPONENTS bit (1 << 5), FLAG_WE_HAVE_INSTRUCTIONS bit (1 << = 8) > > Note that the Open Font Format (and TTF and OpenType) specifications > use MORE_COMPONENTS and WE_HAVE_INSTRUCTIONS (without the FLAG_ > prefix). Again, C bit shifting operator is used without prior mention. > As a comparison, the font specifications use "bit 0", "bit 1" etc > > [VL] Fixed, thank you > > =20 > > If the hmtx table transform is both applicable and desired, the > encoder MUST check that leftSideBearing values match the xMin values > of the glyph bounding box for every glyph in a font file and, if the > conditions are met for each of the proportional or monospaced glyph > runs the encoder MUST set hmtx transform version number to "1", MUST > eliminate the corresponding array from the hmtx table and MUST set the > appropriate Flags bits. > > I guess "leftSideBearing" must be understood as lsb[] and/or > leftsideBearing[] ; and that "desired" means "desired by the encoder". > > [VL] lsb[] and leftSideBearing[] here are the references to > identically named arrays of the hmtx table > (http://www.microsoft.com/typography/otspec/hmtx.htm). Desirability of > transform will most likely be determined by the outside context, e.g. > one may want to apply all applicable transforms when encoding a full > font file but skip the transforms and improve performance if a small > font subset is encoded as WOFF2 and optimizing already reduced tables > doesn=E2=80=99t make much difference in terms of compression efficiency= =2E > > =20 > > =20 > --------------050101010607050201020102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty= pe"> </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> <div class=3D"moz-cite-prefix">Thank you for your reply and for updating the draft. I actually had found one more typo:<br> <blockquote type=3D"cite">Fo more details on table order constraint= s see subclause 5.5.</blockquote> <br> This should be "For"<br> <br> Le 02/11/2015 23:18, Levantovsky, Vladimir a =C3=A9crit=C2=A0:<br> </div> <blockquote cite=3D"mid:[email protected]= rg" type=3D"cite"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Du= tf-8"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.tt {mso-style-name:tt;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} =2EMsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","sans-serif";color:#1F= 497D">Dear Fr=C3=A9d=C3=A9ric,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","sans-serif";color:#1F= 497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","sans-serif";color:#1F= 497D">Thank you very much for taking the time to review the WOFF2 spec and providing your comments, please see the disposition notes inline. The most recent version of the Editor=E2=80=99s= Draft WOFF2 specification is available at <a moz-do-not-send=3D"true" href=3D"http://dev.w3.org/webfonts/WOFF2/spec/"> http://dev.w3.org/webfonts/WOFF2/spec/</a> and the implemented changes are at <a moz-do-not-send=3D"true" href=3D"http://dev.w3.org/cvsweb/webfonts/WOFF2/spec/Overview.html.diff?r= 1=3D1.69;r2=3D1.70;f=3Dh">http://dev.w3.org/cvsweb/webfonts/WOFF2/spec/Ov= erview.html.diff?r1=3D1.69;r2=3D1.70;f=3Dh</a><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","sans-serif";color:#1F= 497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","sans-serif";color:#1F= 497D">With kind regards,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","sans-serif";color:#1F= 497D">Vladimir<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif= ";color:windowtext">From:</span></b><span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif= ";color:windowtext"> Fr=C3=A9d=C3=A9ric WANG [<a class=3D"moz-txt-link-freetex= t" href=3D"mailto:[email protected]">mailto:[email protected]</a>] <br> <b>Sent:</b> Sunday, October 18, 2015 4:20 PM<br> <b>To:</b> <a class=3D"moz-txt-link-abbreviated" href=3D"= mailto:[email protected]">[email protected]</a><br> <b>Subject:</b> Comments on the WOFF 2.0 Working Draft 9 October 2015<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p> <p class=3D"MsoNormal">Dear WebFonts Working Group,<br> <br> Please find below my personal comments after a first reading of the WOFF 2.0 specification (without any attempts to implement it). I hope they will be helpful.<br> <br> Cheers,<br> <br> Fr=C3=A9d=C3=A9ric Wang<br> <br> <br> <o:p></o:p></p> <p class=3D"MsoNormal">The input font file may contain a number o= f various font data tables described in the clause 5 of the [OFF] specification.<o:p></o:p></p> <p class=3D"MsoNormal">Could you please update the reference link= to use edition 3 of the Open Font Format specification now that it is released? Especially since the new MATH table is mentioned in the "Known Table Tags".<br> <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Accepted, the link was updated to point to the 2015 (3<sup>rd= </sup> edition) of the ISO document.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">File header with basic font type and version, along with offsets to metadata and private data blocks.<br> An optional block of extended metadata, represented in XML format and compressed for storage in the WOFF2 file.=C2=A0<o:p>= </o:p></p> <p class=3D"MsoNormal">There are new lines after "private" and after "compressed". I'm not sure whether it's on purpose.<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Edited to remove them.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">The pseudo-code describing how to read the= 255UInt16 format is presented below:<o:p></o:p></p> <p class=3D"MsoNormal">I think it should be mentioned that this i= s "C-like" pseudo-code to make clear that bitwise operators <<, & are used.<br> <br> <span style=3D"color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Accepted<o:p></o:p></span></p> <p class=3D"MsoNormal"><br> In general maybe it should probably be said somewhere in the introduction that the "0x..." notations used everywhere in this specification correspond to hexadecimal values.<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Accepted<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">An encoder should choose shorter encodings= , and must be consistent in choice of encoding for the same value, as this will tend to compress better.<o:p></o:p></p> <p class=3D"MsoNormal">I have the impression that the specification should explicitly provide a way to get a shortest encoding. For example some pseudo code describing the following transformation:<br> <br> 0 =E2=89=A4 value < lowestUCode ---> [value on 1 byte]<br= > <br> lowestUCode =E2=89=A4 value < 2*lowestUCode ---> [oneMoreByteCode1][value - lowestUCode on 1 byte]<br> <br> 2*lowestUCode =E2=89=A4 value < 2*lowestUCode + 256 ---> [oneMoreByteCode2][value - 2*lowestUCode on one byte]<br> <br> value =E2=89=A5 2*lowestUCode + 256 ---> [wordCode][value on= 2 bytes]<br> <br> Actually, this is probably insignificant but I wonder why [oneMoreByteCode2][code] is not interpreted as lowestUCode + 256 + code so that code1 & code2 encodings won't overlap. Does the encoding proposed in the spec tend to compress better?<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Deferred for WG discussion<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">Thus, a decoding procedure for a UIntBase128 is: start with value =3D 0. Consume a byte, setting= value =3D old value times 128 + (byte bitwise-and 127). Repeat last step until the most significant bit of byte is false.<o:p>= </o:p></p> <p class=3D"MsoNormal">I personally feel that this paragraph woul= d be better presented with pseudo-code.<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal">An encoder must not allow this to happen and must produce shortest possible encoding.<o:p></o:p></p> <p class=3D"MsoNormal">Here too I believe there should be some simple pseudo-code to explain the canonical & optimal way to write the 32bits of the integer on at most five 7-bit blocks (even if that's obvious once you think about it).<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Deferred for WG discussion<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">The interpretation of the WOFF2 Header is the same as the WOFF Header in [WOFF1].<o:p></o:p></p> <p class=3D"MsoNormal">Maybe it should be highlighted that the only new field with respect to WOFF version 1 is totalCompressedSize?<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Accepted<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">The font directory section consist of<o:p>= </o:p></p> <p class=3D"MsoNormal">consists<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Fixed, thank you<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">Whether a table tag is encoded with a know= n table tag or explicitly including the four-byte tag has no semantic significance; it is simply a choice of encoding intended to improve compression efficiency.<o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">The known table flag values should not b= e relied upon in determining the presence of the transformed tables, it is feasible that e.g. the glyf table can be represented in the table directory with either flag =3D 10 an= d no tag, or with flag =3D 63 and 'glyf' tag that follows.<o:p>= </o:p></p> </blockquote> <p class=3D"MsoNormal">I wonder why the encoder is not forced to use the known flag when it is available for a table? Of course the size gain is negligible and the table directory is not compressed anyway, but that would be consistent with other places of the spec where it tries to get the optimal encoding when possible.<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Deferred for WG discussion<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">if the table is transformed, then the version number of the applied transform is defined by the two most significatn flag bits<o:p></o:p></p> <p class=3D"MsoNormal">significant<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Fixed, thank you<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">The decompressed and reconstructed table data MUST be stored in the format specified by the [OFF] specification. Each reconstructed table directory entry MUST contain a valid 'checkSum' value, the decoder MUST recalculate the checkSum value for each decoded table. Also, due to modifying transforms applied to glyf and loca tables, the decoder MUST recalculate the checkSumAdjustmentglyf value of the entire font and MUST store the updated value in the head table.<o:p></o:p></p> <p class=3D"MsoNormal">"checkSumAdjustmentglyf" should be "checkSumAdjustment", I guess.<br> <br> <span style=3D"color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Fixed, thank you<o:p></o:p></span></p> <p class=3D"MsoNormal"><br> I find that this paragraph is a bit confusing. It seems to suggest that only the checkSumAdjustment may change and that it is only 'due to modifying transforms applied to glyf and loca tables'. At the same time it seems to ask the decoders to recalculate all the checksums without any verification for possible unchanged checksums.<br> <br> <span style=3D"color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal">My understanding is that only transformed tables that can not be reconstructed identically to the original will have the checksum invalidated (i.e. 'glyf' and 'loca' but not 'hmtx' or other tables). And that in general the overall checkSumAdjustment will be invalidated. Is that correct?<br> <br> <span style=3D"color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Yes, this is correct.<o:p></o:p></span></p> <p class=3D"MsoNormal"><br> The possible binary changes are better explained in the "The WOFF 2.0 transformations applied to certain tables...." paragraph below that one, maybe this section should be reordered a bit or this decoder+checksum paragraph should point to the paragraph below?<br> <br> Why isn't the decoder asked to verify the checksum that are guaranteed to be preserved and to just recalculate everything? Is it a requirement of the OFF specification when bit 11 of the 'flags' field of the head is set?<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Deferred for WG discussion</span><br> <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal">The total number of bytes in <span class=3D"tt">bboxBitmap</span> is equal to 4 * ((numGlyphs + 31) / 32).<o:p></o:p></p> <p class=3D"MsoNormal">Again, C integer-division is implicit here= =2E I would suggest writing "4 * <span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8A</span> (numGlyphs + 3= 1) / 32 <span style=3D"font-family:"Cambria Math","serif""> =E2=8C=8B</span>" or even better if you want to enhance rende= ring in some web engines and assistive technologies:<br> <br> <math><semantics><mrow><mn>4</mn><mrow&g= t;<mo><span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8A</span></mo><= mfrac><mrow><mtext>numGlyphs</mtext><mo>+</= mo><mn>31</mn></mrow><mn>32</mn></mfr= ac><mo><span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8B</span></mo><= /mrow></mrow><annotation encoding=3D"text/plain">4 * <span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8A</span> (numGlyphs + 3= 1) / 32 <span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8B</span></annotation= ></semantics></math><br> <br> 4<span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8A</span>numGlyphs+3132<= span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8B</span>4 * <span style=3D"font-family:"Cambria Math","serif"">=E2=8C=8A</span> (numGlyphs + 3= 1) / 32 <span style=3D"font-family:"Cambria Math","serif""> =E2=8C=8B</span><br> <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] I modified the notation to reflect the nature of implicit integer division.</span><br> <br> <o:p></o:p></p> <p class=3D"MsoNormal">Upon reading the Transformed glyf Table , the decoding process iterates one glyph at a time. For each glyph, it reads zero or more bytes from each of the streams referenced in the Transformed glyf Table .<o:p></o:p></p> <p class=3D"MsoNormal">There are extra spaces before the comma an= d the period.<br> <br> <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Fixed, thank you<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal">FLAG_MORE_COMPONENTS bit (1 << 5), FLAG_WE_HAVE_INSTRUCTIONS bit (1 << 8)<o:p></o:p></p> <p class=3D"MsoNormal">Note that the Open Font Format (and TTF an= d OpenType) specifications use MORE_COMPONENTS and WE_HAVE_INSTRUCTIONS (without the FLAG_ prefix). Again, C bit shifting operator is used without prior mention. As a comparison, the font specifications use "bit 0", "bit 1" etc<br= > <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] Fixed, thank you<o:p></o:p></span></p> <p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p> <p class=3D"MsoNormal">If the hmtx table transform is both applicable and desired, the encoder MUST check that leftSideBearing values match the xMin values of the glyph bounding box for every glyph in a font file and, if the conditions are met for each of the proportional or monospaced glyph runs the encoder MUST set hmtx transform version number to "1", MUST eliminate the corresponding array from the hmtx table and MUST set the appropriate Flags bits.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I guess "leftSideBearing" must be understood as lsb[] and/or leftsideBearing[] ; and that "desired" means "desired by the encoder".<o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D">[VL] lsb[] and leftSideBearing[] here are the references to identically named arrays of the hmtx table (<a moz-do-not-send=3D"true" href=3D"http://www.microsoft.com/typography/otspec/hmtx.htm= ">http://www.microsoft.com/typography/otspec/hmtx.htm</a>). Desirability of transform will most likely be determined by the outside context, e.g. one may want to apply all applicable transforms when encoding a full font file but skip the transforms and improve performance if a small font subset is encoded as WOFF2 and optimizing already reduced tables doesn=E2=80=99t make much difference in terms of compr= ession efficiency.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0pt;font-family:"Calibri","sans-seri= f";color:#1F497D"><o:p>=C2=A0</o:p></span></p> </div> </blockquote> <br> </body> </html> --------------050101010607050201020102-- --Hdvmj8V3sQbUo1cMTidMisCDVbexw9oWi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWN+TeAAoJEL8nnpULUzQOVvsP/3Ypzour0cpd5REHchvupmPw ACCWQA1J7h5QknUQfbDX/mJ0rEjejEfeDlhYhNCG65u8gjVLv+iYM2ujQNABVoVv pdTKBjSfteUN6XAeoV5UwXIuX6JM0BlLJ1uV6OiJEDAigKH9qSXynjYoSEGTmiwF eEDWJMQYT7wD01qZwe+W3OglDz5JXiLrGYsiGCChz6dwwrM+aRLPfqvLDzV4ed2h XNnyn8/nTfXspm9lD0806QzJeq0dvON1SQLcKCxvjQZM/2f3/BDsZrPweC4oXKvn 9m3qfvhPFStCQvVnTGMdJJI7W4epvDqloW2mKvqI8/xmOwk4m2280sRx+7MMF4wK omjtGlUl2/c/QJvV0u8ye5gc6UakYrz8HNCaTdQXypaR8cCiJTfoTca25Ju30HwP RH8DXAoLFe8CGbdAuElBcPegxbt136ZMypnh1hujj5sE5dzE1lKOyeBxfepKEfog CnHnA50bGTBPqAEuFfgjuPQUXC7caIlAxY3VocJyM2RAcVkVeZfi+6+6oMsFnSXU GoOrCbRNX3hiHzqDLE8mP7KwrTqRI6R0oiBfVkC5pNmjc+Pem9AmvGU//Wg1CT3q ThbVcMTGaKHufRM3EGgGUbjwXGdPJxCaZYciif5/NQysA2Ko0aS4+hqK7FBOGmKr sTJw3JyC4u+ZnyZdTm+C =jkK0 -----END PGP SIGNATURE----- --Hdvmj8V3sQbUo1cMTidMisCDVbexw9oWi--