> While investigating some odd behavior, I discovered that in FreeType
> if a TrueType glyf contains instructions which read/modify/write a
> CVT entry and the glyph is loaded more than once the modified values
> persist across calls. The persistence is in the (TT_SizeRec_)
> size.cvt since TT_Load_Context sets exec.cvt to size.cvt. [...]
This is definitely a bug, thanks for noticing it!
> I'm not sure if this is supposed to work this way. I don't think it
> should, but this doesn't seem to be addressed by any existing
> specification or documentation.
As so many things in the bytecode specification. It's always annoying
to have an implementation first from which the documentation is
derived...
Yeah, it's still not clear to me if instructions like WCVTP are supposed to be like FDEF and only appear in prep and fpgm, or more like IDEF which can appear anywhere but is ignored if trying to change anything existing, or if the write should work but only be effective while hinting this glyf (and what about composite glyf). I think WS has the same issue as WCVTP, in that changes in glyf instructions shouldn't persist. Need to check that one too.
Do you have time to provide a patch?
I don't have a patch at the moment. Since you've confirmed that this is something that should be fixed, I'll try to figure out how to fix this sometime soon. I assume it isn't very common for glyf instructions to modify cvt entries, so I might try marking as dirty first. On the other hand having a scratch copy of the size doesn't seem too bad either. I'll probably need to write an evil font that makes it more obvious when glyf instructions try to modify any persistent state.