Re: Comments on the WOFF 2.0 Working Draft 9 October 2015
Roderick Sheeter <[email protected]> Tue, 3 Nov 2015 08:32:23 -0800
| Newsgroups | gmane.comp.web.fonts |
|---|---|
| Message-ID | <CABscrrH4ZX-a18YJ6jrTWjUNFaYss-uokGhnPJHkOsE4e=j7jA@mail.gmail.com> |
--001a11421a503fd8d40523a570ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In the line 844/852 diff it looks like something unfortunate happened to the character encoding. The right hand side - 4 * =C3=A2=C5=92=C5=A0(numGly= phs + 31) / 32=C3=A2=C5=92=E2=80=B9. - looks off. l find (1 << 8) clearer than (bit 8). If we are going to say "bit 8" did we define somewhere how to interpret that or is there a standard interpretation? On Mon, Nov 2, 2015 at 2:18 PM, Levantovsky, Vladimir < [email protected]> wrote: > Dear Fr=C3=A9d=C3=A9ric, > > > > Thank you very much for taking the time to review the WOFF2 spec and > providing your comments, please see the disposition notes inline. The mos= t > recent version of the Editor=E2=80=99s Draft WOFF2 specification is avail= able at > 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 > > > > With kind regards, > > Vladimir > > > > > > *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 > > > > 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 wil= l > 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 n= ew > MATH table is mentioned in the "Known Table Tags". > > [VL] Accepted, the link was updated to point to the 2015 (3rd edition) of > the ISO document. > > > > 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. > > There are new lines after "private" and after "compressed". I'm not sure > whether it's on purpose. > > [VL] Edited to remove them. > > > > 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 correspo= nd > to hexadecimal values. > > [VL] Accepted > > > > An encoder should choose shorter encodings, and must be consistent in > choice of encoding for the same value, as this will tend to compress bett= er. > > I have the impression that the specification should explicitly provide a > way to get a shortest encoding. For example some pseudo code describing t= he > following transformation: > > 0 =E2=89=A4 value < lowestUCode ---> [value on 1 byte] > > lowestUCode =E2=89=A4 value < 2*lowestUCode ---> [oneMoreByteCode1][value= - > lowestUCode on 1 byte] > > 2*lowestUCode =E2=89=A4 value < 2*lowestUCode + 256 ---> [oneMoreByteCode= 2][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 s= o > that code1 & code2 encodings won't overlap. Does the encoding proposed in > the spec tend to compress better? > > [VL] Deferred for WG discussion > > > > 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. > > 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 fiv= e > 7-bit blocks (even if that's obvious once you think about it). > > [VL] Deferred for WG discussion > > > > 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 > > > > The font directory section consist of > > consists > > [VL] Fixed, thank you > > > > 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 tab= le > 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 tabl= e > directory is not compressed anyway, but that would be consistent with oth= er > places of the spec where it tries to get the optimal encoding when possib= le. > > [VL] Deferred for WG discussion > > > > 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 > > > > The decompressed and reconstructed table data MUST be stored in the forma= t > 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 i= t > 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 th= at > 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 t= he > 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 re= ndering > 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 eac= h > of the streams referenced in the Transformed glyf Table . > > There are extra spaces before the comma and the period. > > [VL] Fixed, thank you > > > > 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). Agai= n, > C bit shifting operator is used without prior mention. As a comparison, t= he > font specifications use "bit 0", "bit 1" etc > > [VL] Fixed, thank you > > > > 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 me= t > for each of the proportional or monospaced glyph runs the encoder MUST se= t > 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 fil= e > 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 ma= ke much > difference in terms of compression efficiency. > > > > > --001a11421a503fd8d40523a570ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">In the line 844/852 diff it looks like something unfortuna= te happened to the character encoding. The right hand side -=C2=A0<span sty= le=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13.3333px;backgroun= d-color:rgb(255,255,102)">4 * =C3=A2=C5=92=C5=A0(numGlyphs + 31) / 32=C3=A2= =C5=92=E2=80=B9.</span>=C2=A0- looks off.<div><br></div><div>l find (1 <= < 8) clearer than (bit 8). If we are going to say "bit 8" did = we define somewhere how to interpret that or is there a standard interpreta= tion?</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On Mon, Nov 2, 2015 at 2:18 PM, Levantovsky, Vladimir <span dir=3D"ltr"><= ;<a href=3D"mailto:[email protected]" target=3D"_blank">Vla= [email protected]</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","= ;sans-serif";color:#1f497d">Dear Fr=C3=A9d=C3=A9ric,<u></u><u></u></sp= an></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","= ;sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","= ;sans-serif";color:#1f497d">Thank you very much for taking the time to= review the WOFF2 spec and providing your comments, please see the disposit= ion notes inline. The most recent version of the Editor=E2=80=99s Draft WOFF2 specification is available at <a href=3D"http://dev.w3.org/web= fonts/WOFF2/spec/" target=3D"_blank"> http://dev.w3.org/webfonts/WOFF2/spec/</a> and the implemented changes are = at <a href=3D"http://dev.w3.org/cvsweb/webfonts/WOFF2/spec/Overview.html.di= ff?r1=3D1.69;r2=3D1.70;f=3Dh" target=3D"_blank"> http://dev.w3.org/cvsweb/webfonts/WOFF2/spec/Overview.html.diff?r1=3D1.69;r= 2=3D1.70;f=3Dh</a><u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","= ;sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","= ;sans-serif";color:#1f497d">With kind regards,<u></u><u></u></span></p= > <p class=3D"MsoNormal"><span style=3D"font-family:"Calibri","= ;sans-serif";color:#1f497d">Vladimir<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></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><spa= n style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif= ";color:windowtext"> Fr=C3=A9d=C3=A9ric WANG [mailto:<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>] <br> <b>Sent:</b> Sunday, October 18, 2015 4:20 PM<br> <b>To:</b> <a href=3D"mailto:[email protected]" target=3D"_blank">www-font@w3= .org</a><br> <b>Subject:</b> Comments on the WOFF 2.0 Working Draft 9 October 2015<u></u= ><u></u></span></p> </div> </div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></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> <u></u><u></u></p> <p class=3D"MsoNormal">The input font file may contain a number of various = font data tables described in the clause 5 of the [OFF] specification.<u></= u><u></u></p> <p class=3D"MsoNormal">Could you please update the reference link to use ed= ition 3 of the Open Font Format specification now that it is released? Espe= cially since the new MATH table is mentioned in the "Known Table Tags&= quot;.<br> <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-= serif";color:#1f497d">[VL] Accepted, the link was updated to point to = the 2015 (3<sup>rd</sup> edition) of the ISO document.<u></u><u></u></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></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 compr= essed for storage in the WOFF2 file.=C2=A0<u></u><u></u></p> <p class=3D"MsoNormal">There are new lines after "private" and af= ter "compressed". I'm not sure whether it's on purpose.<b= r> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Edited to remove the= m.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal">The pseudo-code describing how to read the 255UInt16= format is presented below:<u></u><u></u></p> <p class=3D"MsoNormal">I think it should be mentioned that this is "C-= like" pseudo-code to make clear that bitwise operators <<, &= are used.<br> <br> <span style=3D"color:#1f497d"><u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Accepted<u></u><u></= u></span></p> <p class=3D"MsoNormal"><br> In general maybe it should probably be said somewhere in the introduction t= hat the "0x..." notations used everywhere in this specification c= orrespond to hexadecimal values.<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Accepted<u></u><u></= u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></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.<u></u><u></u></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 pseud= o 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][v= alue - lowestUCode on 1 byte]<br> <br> 2*lowestUCode =E2=89=A4 value < 2*lowestUCode + 256 ---> [oneMoreByte= Code2][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 t= end to compress better?<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Deferred for WG disc= ussion<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal">Thus, a decoding procedure for a UIntBase128 is: sta= rt 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 o= f byte is false.<u></u><u></u></p> <p class=3D"MsoNormal">I personally feel that this paragraph would be bette= r presented with pseudo-code.<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal">An encoder must not allow this to happen and must pr= oduce shortest possible encoding.<u></u><u></u></p> <p class=3D"MsoNormal">Here too I believe there should be some simple pseud= o-code to explain the canonical & optimal way to write the 32bits of th= e integer on at most five 7-bit blocks (even if that's obvious once you= think about it).<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Deferred for WG disc= ussion<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal">The interpretation of the WOFF2 Header is the same a= s the WOFF Header in [WOFF1].<u></u><u></u></p> <p class=3D"MsoNormal">Maybe it should be highlighted that the only new fie= ld with respect to WOFF version 1 is totalCompressedSize?<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Accepted<u></u><u></= u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal">The font directory section consist of<u></u><u></u><= /p> <p class=3D"MsoNormal">consists<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Fixed, thank you<u><= /u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal">Whether a table tag is encoded with a known table ta= g or explicitly including the four-byte tag has no semantic significance; i= t is simply a choice of encoding intended to improve compression efficiency= .<u></u><u></u></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">The known table flag values should not be relied upo= n in determining the presence of the transformed tables, it is feasible tha= t 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.<u></u><u></u></p> </blockquote> <p class=3D"MsoNormal">I wonder why the encoder is not forced to use the kn= own flag when it is available for a table? Of course the size gain is negli= gible and the table directory is not compressed anyway, but that would be c= onsistent with other places of the spec where it tries to get the optimal encoding when possible.<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Deferred for WG disc= ussion<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></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<= u></u><u></u></p> <p class=3D"MsoNormal">significant<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Fixed, thank you<u><= /u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal">The decompressed and reconstructed table data MUST b= e stored in the format specified by the [OFF] specification. Each reconstru= cted table directory entry MUST contain a valid 'checkSum' value, t= he 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 va= lue of the entire font and MUST store the updated value in the head table.<= u></u><u></u></p> <p class=3D"MsoNormal">"checkSumAdjustmentglyf" should be "c= heckSumAdjustment", I guess.<br> <br> <span style=3D"color:#1f497d"><u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Fixed, thank you<u><= /u><u></u></span></p> <p class=3D"MsoNormal"><br> I find that this paragraph is a bit confusing. It seems to suggest that onl= y the checkSumAdjustment may change and that it is only 'due to modifyi= ng transforms applied to glyf and loca tables'. At the same time it see= ms to ask the decoders to recalculate all the checksums without any verification for possible unchanged checksums.<b= r> <br> <span style=3D"color:#1f497d"><u></u><u></u></span></p> <p class=3D"MsoNormal">My understanding is that only transformed tables tha= t can not be reconstructed identically to the original will have the checks= um invalidated (i.e. 'glyf' and 'loca' but not 'hmtx= 9; or other tables). And that in general the overall checkSumAdjustment will be invalidated. Is that correct?<br> <br> <span style=3D"color:#1f497d"><u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Yes, this is correct= .<u></u><u></u></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 on= e, maybe this section should be reordered a bit or this decoder+checksum pa= ragraph 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> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Deferred for WG disc= ussion</span><br> <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-= serif";color:#1f497d"><u></u><u></u></span></p> <p class=3D"MsoNormal">The total number of bytes in <span>bboxBitmap</span>= is equal to 4 * ((numGlyphs + 31) / 32).<u></u><u></u></p> <p class=3D"MsoNormal">Again, C integer-division is implicit here. I would = suggest writing "4 * <span style=3D"font-family:"Cambria Math","serif"">=E2= =8C=8A</span> (numGlyphs + 31) / 32 <span style=3D"font-family:"Cambri= a Math","serif""> =E2=8C=8B</span>" or even better if you want to enhance rendering in s= ome web engines and assistive technologies:<br> <br> <math><semantics><mrow><mn>4</mn><mrow>= <mo><span style=3D"font-family:"Cambria Math","serif&q= uot;">=E2=8C=8A</span></mo><mfrac><mrow><mtext>numG= lyphs</mtext><mo>+</mo><mn>31</mn></mrow&g= t;<mn>32</mn></mfrac><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 + 31) / 3= 2 <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&qu= ot;,"serif"">=E2=8C=8B</span>4 * <span style=3D"font-family:"Cambria Math","serif"">=E2= =8C=8A</span> (numGlyphs + 31) / 32 <span style=3D"font-family:"Cambri= a Math","serif""> =E2=8C=8B</span><br> <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-= serif";color:#1f497d">[VL] I modified the notation to reflect the natu= re of implicit integer division.</span><br> <br> <u></u><u></u></p> <p class=3D"MsoNormal">Upon reading the Transformed glyf Table , the decodi= ng process iterates one glyph at a time. For each glyph, it reads zero or m= ore bytes from each of the streams referenced in the Transformed glyf Table= .<u></u><u></u></p> <p class=3D"MsoNormal">There are extra spaces before the comma and the peri= od.<br> <br> <u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Fixed, thank you<u><= /u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal">FLAG_MORE_COMPONENTS bit (1 << 5), FLAG_WE_HAV= E_INSTRUCTIONS bit (1 << 8)<u></u><u></u></p> <p class=3D"MsoNormal">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<br> <br> <span style=3D"font-size:11.0pt;font-family:"Calibri","sans-= serif";color:#1f497d"><u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] Fixed, thank you<u><= /u><u></u></span></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">If the hmtx table transform is both applicable and d= esired, the encoder MUST check that leftSideBearing values match the xMin v= alues 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 fro= m the hmtx table and MUST set the appropriate Flags bits.<u></u><u></u></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I guess "leftSid= eBearing" must be understood as lsb[] and/or leftsideBearing[] ; and t= hat "desired" means "desired by the encoder".<u></u><u>= </u></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d">[VL] lsb[] and leftSideBe= aring[] here are the references to identically named arrays of the hmtx tab= le (<a href=3D"http://www.microsoft.com/typography/otspec/hmtx.htm" target= =3D"_blank">http://www.microsoft.com/typography/otspec/hmtx.htm</a>). Desirability of transform will most likely be determined by the outside co= ntext, 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.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa= n></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s= ize:11.0pt;font-family:"Calibri","sans-serif";color:#1f= 497d"><u></u>=C2=A0<u></u></span></p> </div> </div> </blockquote></div><br></div> --001a11421a503fd8d40523a570ab--