Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution

Alexei Podtelezhnikov <[email protected]> Wed, 15 Oct 2025 12:41:04 -0400
Newsgroups gmane.comp.fonts.freetype.devel
Message-ID <[email protected]> 
--Apple-Mail-A94591AF-1D9D-4103-8794-FE15E6F2F578
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


>=20
> On Oct 15, 2025, at 12:29, Alexei Podtelezhnikov <[email protected]> wrot=
e:
>=20
> =EF=BB=BF
>=20
>> =20
>> Given that this is a font issue and we don=E2=80=99t want to compensate f=
or it. Is it possible to reset exec->backward_compatibility to known state e=
very time a glyph is loaded since that is the root cause of the inconsistenc=
y in rendering of the glyph(irrespective of whether is correct or not).
>> =20
>=20
> It is already reset each time tt_loader_init is executed, which is for eac=
h glyph.

Therefore, I doubt that you identified the problem correctly. What is legal a=
nd problematic are the twilight point. Those can be moved by glyf and persis=
t, which can create interesting effects.=

--Apple-Mail-A94591AF-1D9D-4103-8794-FE15E6F2F578
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"><br id=3D"lineBreakAtBeginningOfSignature">=
<div dir=3D"ltr"><blockquote type=3D"cite"><br>On Oct 15, 2025, at 12:29, Al=
exei Podtelezhnikov &lt;[email protected]&gt; wrote:<br><br></blockquote></=
div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<meta http-equiv=3D"=
content-type" content=3D"text/html; charset=3Dutf-8"><br id=3D"lineBreakAtBe=
ginningOfSignature"><div dir=3D"ltr"><br></div><blockquote type=3D"cite"><di=
v dir=3D"ltr"><div class=3D"WordSection1"><p class=3D"MsoNormal"><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>&nbsp;</o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">Given that this is a=
 font issue and we don=E2=80=99t want to compensate for it. Is it possible t=
o reset exec-&gt;backward_compatibility to known state every time a glyph is=
 loaded since that is the root cause of the
 inconsistency in rendering of the glyph(irrespective of whether is correct o=
r not).</span></p><p class=3D"MsoNormal"><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>&nbsp;</o:p></s=
pan></p><div id=3D"mail-editor-reference-message-container"><div><div><div>
</div>
</div>
</div>
</div>
</div>


</div></blockquote><br><style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Aptos; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 10pt; fon=
t-family: Aptos, sans-serif; }
span.EmailStyle19 { font-family: Aptos, sans-serif; color: windowtext; }
.MsoChpDefault { font-size: 10pt; }
@page WordSection1 { size: 8.5in 11in; margin: 1in; }
div.WordSection1 { page: WordSection1; }</style><div>It is already reset eac=
h time tt_loader_init is executed, which is for each glyph.</div></div></blo=
ckquote><br><div>Therefore, I doubt that you identified the problem correctl=
y. What is legal and problematic are the twilight point. Those can be moved b=
y glyf and persist, which can create interesting effects.</div></body></html=
>=

--Apple-Mail-A94591AF-1D9D-4103-8794-FE15E6F2F578--