Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
Hi Werner, I cannot provide the font to you due to legal reasons. However, I looked at issue #1262 you mentioned in your earlier email and the reproduction steps, and the symptoms look very similar. You can try my proposed fix on that example and see if that fixes the issue. From: Werner LEMBERG Date: Thursday, October 16, 2025 at 12:03 PM To: [email protected] Cc: Honnesh Ramachandra , [email protected] Subject: Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution EXTERNAL: Use caution when clicking on links or opening attachments. > Besides the change below or something similar. How should we handle > the flag *during* the CV execution? Right now the CV program does > not change it until it is complete. In other wards, should we care > about it while moving twilight points in the CV program? Right now > we ignore the flag presumably. Good question. I don't know what the right behaviour is, so I suggest that we wait for reports :-) Werner
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
> Our automated testing infrastructure flagged an issue with FreeType > code where at low font size, certain glyph was scaled incorrectly. What font exactly, and which glyphs of it? If this is a proprietary font, please send the font to us privately for further inspection, not to the list. If it is a large one, please send a link. > The root cause was found to be delay in setting the > backward_compatibility flag on the execution 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 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. As Alexei said, this is problematic – at least this is what I get from your description. A glyph must not rely on the graphics state; as soon as a new glyph gets loaded, this state is reset. If backward compatibility is requested, it must be activated per-glyph or in the the CV program. > The reexecute flag is not currently affected by > exec->backward_compatibility flag which, as you can see, can clearly > affect the output. 'Can see'? What? You haven't shown us an image of the font output at all. Did you miss to attach something? Werner
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
Great. Here is a diff of the proposed changes in that case in ttgload.c @@ -2201,7 +2201,6 @@ TT_Driver driver= (TT_Driver)FT_FACE_DRIVER( glyph->face ); #endif - if ( size->bytecode_ready > 0 ) return size->bytecode_ready; if ( size->bytecode_ready < 0 ) @@ -2215,6 +2214,7 @@ } exec = size->context; + exec->backward_compatibility = 0; #ifdef TT_SUPPORT_SUBPIXEL_HINTING_MINIMAL if ( driver->interpreter_version == TT_INTERPRETER_VERSION_40 ) From: Alexei Podtelezhnikov Date: Wednesday, October 15, 2025 at 8:39 PM To: Honnesh Ramachandra Cc: Werner LEMBERG , [email protected] Subject: Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution EXTERNAL: Use caution when clicking on links or opening attachments. It is reset but, after CV program execution. Is it possible to reset it before CV program execution? Agreed. It makes sense to clear it before CV execution.
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
> It is reset but, after CV program execution. Is it possible to reset it > before CV program execution? > Agreed. It makes sense to clear it before CV execution.
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
> > Given that this is a font issue and we don’t want to compensate for it. Is it > possible to reset exec->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 or not). > It is already reset each time tt_loader_init is executed, which is for each glyph.
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
> Besides the change below or something similar. How should we handle > the flag *during* the CV execution? Right now the CV program does > not change it until it is complete. In other wards, should we care > about it while moving twilight points in the CV program? Right now > we ignore the flag presumably. Good question. I don't know what the right behaviour is, so I suggest that we wait for reports :-) Werner
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
Werner, Besides the change below or something similar. How should we handle the flag *during* the CV execution? Right now the CV program does not change it until it is complete. In other wards, should we care about it while moving twilight points in the CV program? Right now we ignore the flag presumably. Alexei > On Oct 15, 2025, at 21:32, Honnesh Ramachandra wrote: > > > Great. Here is a diff of the proposed changes in that case in ttgload.c > > @@ -2201,7 +2201,6 @@ >TT_Driver driver= (TT_Driver)FT_FACE_DRIVER( glyph->face ); > #endif > > - >if ( size->bytecode_ready > 0 ) > return size->bytecode_ready; >if ( size->bytecode_ready < 0 ) > @@ -2215,6 +2214,7 @@ >} > >exec = size->context; > + exec->backward_compatibility = 0; > > #ifdef TT_SUPPORT_SUBPIXEL_HINTING_MINIMAL >if ( driver->interpreter_version == TT_INTERPRETER_VERSION_40 ) > >
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
It is reset but, after CV program execution. Is it possible to reset it before CV program execution? From: Alexei Podtelezhnikov Date: Wednesday, October 15, 2025 at 12:41 PM To: Honnesh Ramachandra Cc: Werner LEMBERG , [email protected] Subject: Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution EXTERNAL: Use caution when clicking on links or opening attachments. On Oct 15, 2025, at 12:29, Alexei Podtelezhnikov wrote: Given that this is a font issue and we don’t want to compensate for it. Is it possible to reset exec->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 or not). It is already reset each time tt_loader_init is executed, which is for each glyph. Therefore, I doubt that you identified the problem correctly. What is legal and problematic are the twilight point. Those can be moved by glyf and persist, which can create interesting effects.
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
> Great. Here is a diff of the proposed changes in that case in > ttgload.c [...] Thanks – I leave it to Alexei to handle that, since he modified the code last :-) BTW, maybe issue #1262 is connected? Werner PS: Thanks also for the image. However, it would be still nice to get the font file so that code changes can actually be tested.
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
> > On Oct 15, 2025, at 12:29, Alexei Podtelezhnikov wrote: > > > >> >> Given that this is a font issue and we don’t want to compensate for it. Is >> it possible to reset exec->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 or not). >> > > It is already reset each time tt_loader_init is executed, which is for each > glyph. Therefore, I doubt that you identified the problem correctly. What is legal and problematic are the twilight point. Those can be moved by glyf and persist, which can create interesting effects.
Re: Bug report: Set exec->backward_compatibility flag before TT CV program re-execution
Hi Honnesh See https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions#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 explicit. In other words, what you describe is a font bug. which we are not going to address. Alexei > > On Oct 14, 2025, at 15:56, Honnesh Ramachandra wrote: > > > Hello, > > Our automated testing 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 in setting the backward_compatibility flag on the > execution 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 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. > > The issue happens when the CV program contains operators that rely on the > value of exec->backward_compatibility to determine the adjustment of points. > > Here is a snapshot of one such function in ttinterp.c. > > > > In ttgload.c, there is facility to re-execute the CV program if some of the > parameters change since the first execution. Here is a snapshot of that: > > > > The reexecute flag is not currently affected by exec->backward_compatibility > flag which, as you can see, can clearly affect the output. My proposal is to > include that as well. > > 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. > > > > The functionality has been refactored out to a function called > change_backward_compatibility because of repeated calls to it. I am calling > change_backward_compatibility second time because CV program execution may > have changed exec->backward_compatibility. I am not sure if CV program can > execute such instructions(Ins_IUP, Ins_INSTCTRL, etc.). > > Thanks, > Honnesh >
