Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
Alexei Podtelezhnikov <[email protected]> Tue, 14 Oct 2025 22:05:28 -0400
| Newsgroups | gmane.comp.fonts.freetype.devel |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-F3B8F2F9-2E35-40B0-8F7B-75A6942725AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Honnesh See https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructio= ns#instruction-execution-control Selector flag 3 is the only correct way to control this either in CV program= or glut. No assumptions should be made otherwise. Everything should be expl= icit. In other words, what you describe is a font bug. which we are not goin= g to address. Alexei >=20 > On Oct 14, 2025, at 15:56, Honnesh Ramachandra <[email protected]> wr= ote: >=20 > =EF=BB=BF > Hello, > =20 > Our automated testing infrastructure flagged an issue with FreeType code w= here at low font size, certain glyph was scaled incorrectly. The root cause w= as found to be delay in setting the backward_compatibility flag on the execu= tion context. This issue is sensitive to the order of invocation of FT_Load_= Glyph on a set of glyph IDs. If the glyph that depends on the proper value f= or backward_compatibility is not the first one to be loaded, this issue does= not happen because the first glyph load would have set the field value corr= ectly. > =20 > The issue happens when the CV program contains operators that rely on the v= alue of exec->backward_compatibility to determine the adjustment of points. >=20 > Here is a snapshot of one such function in ttinterp.c. >=20 > <image001.png> > =20 > In ttgload.c, there is facility to re-execute the CV program if some of th= e parameters change since the first execution. Here is a snapshot of that: >=20 > <image002.png> > =20 > The reexecute flag is not currently affected by exec->backward_compatibili= ty flag which, as you can see, can clearly affect the output. My proposal is= to include that as well. >=20 > I have attached my version of ttgload.c based off of FreeType version 2.14= .1. Please incorporate a similarly effective change. Here is a snapshot of a= section of the difference. >=20 > <image003.png> > =20 > The functionality has been refactored out to a function called change_back= ward_compatibility because of repeated calls to it. I am calling change_back= ward_compatibility second time because CV program execution may have changed= exec->backward_compatibility. I am not sure if CV program can execute such i= nstructions(Ins_IUP, Ins_INSTCTRL, etc.). >=20 > Thanks, > Honnesh > <ttgload.c> --Apple-Mail-F3B8F2F9-2E35-40B0-8F7B-75A6942725AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto">Hi Honnesh<div><br></div><div>See <a h= ref=3D"https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instruc= tions#instruction-execution-control">https://learn.microsoft.com/en-us/typog= raphy/opentype/spec/tt_instructions#instruction-execution-control</a></div><= div><br></div><div>Selector flag 3 is the only correct way to control this e= ither in CV program or glut. No assumptions should be made otherwise. Everyt= hing should be explicit. In other words, what you describe is a font bug. wh= ich we are not going to address.</div><div><br></div><div>Alexei</div><div><= div><br></div><div><br id=3D"lineBreakAtBeginningOfSignature"><div dir=3D"lt= r"><blockquote type=3D"cite"><br>On Oct 14, 2025, at 15:56, Honnesh Ramachan= dra <[email protected]> wrote:<br><br></blockquote></div><blockqu= ote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">= <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style>@font-face { font-family: "Cambria Math"; } @font-face { font-family: Aptos; } p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 12pt; fon= t-family: Aptos, sans-serif; } .MsoChpDefault { font-size: 10pt; } @page WordSection1 { size: 8.5in 11in; margin: 1in; } div.WordSection1 { page: WordSection1; }</style> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">Hello,<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">Our automated testin= g infrastructure flagged an issue with FreeType code where at low font size,= certain glyph was scaled incorrectly. The root cause was found to be delay i= n setting the backward_compatibility flag on the execution context. This issue is sensitive to the order of invo= cation of FT_Load_Glyph on a set of glyph IDs. If the glyph that depends on t= he proper value for backward_compatibility is not the first one to be loaded= , this issue does not happen because the first glyph load would have set the field value correctly.<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">The issue happens wh= en the CV program contains operators that rely on the value of exec->back= ward_compatibility to determine the adjustment of points.<br> <br> Here is a snapshot of one such function in ttinterp.c.<br> <br> </span><span style=3D"font-size:11.0pt;mso-ligatures:none"><div><image001= .png></div></span><span style=3D"font-size:11.0pt"><o:p></o:p></span></p>= <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">In ttgload.c, there i= s facility to re-execute the CV program if some of the parameters change sin= ce the first execution. Here is a snapshot of that:<br> <br> </span><span style=3D"font-size:11.0pt;mso-ligatures:none"><div><image002= .png></div></span><span style=3D"font-size:11.0pt"><o:p></o:p></span></p>= <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">The reexecute flag i= s not currently affected by exec->backward_compatibility flag which, as y= ou can see, can clearly affect the output. My proposal is to include that as= well.<br> <br> I have attached my version of ttgload.c based off of FreeType version 2.14.1= . Please incorporate a similarly effective change. Here is a snapshot of a s= ection of the difference.<br> <br> <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-ligatures:none"><= div><image003.png></div></span><span style=3D"font-size:11.0pt"><o:p><= /o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">The functionality ha= s been refactored out to a function called change_backward_compatibility bec= ause of repeated calls to it. I am calling change_backward_compatibility sec= ond time because CV program execution may have changed exec->backward_compatibility. I am not sure if CV progr= am can execute such instructions(Ins_IUP, Ins_INSTCTRL, etc.).<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><br> Thanks,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">Honnesh<o:p></o:p></= span></p> </div> <div><ttgload.c></div></div></blockquote></div></div></body></html>= --Apple-Mail-F3B8F2F9-2E35-40B0-8F7B-75A6942725AD--