[Devel] Re: Problem with caching and CFF fonts

[Tom Kacvinsky]

I agree with Eric's assesment.  I got the ft2demos-beta8 tools up an
runiing, and had no problems.  I noticed how beta8 was handling the
step_y variable, and I changed the ft2demos-current code to mimic that
(namely, step_y = size->metrics.y_ppem + 10) and had no problems with
display.

I will look deeper into the caching code to see why
size->metrics.height is getting zeroed out when working with CFF
fonts.  It might not be in the caching code; it could be elsewhere.
But, as we set step_y almost immediately after returning from
FTC_Manager_Lookup_Size, I have to start in the caching code and trace
backwards...

I am also going to try compiling with no optimization and see what
that does.  This has worked miracles before, so why not try it now. :)

Tom

On Tue, 28 Nov 2000, Blinn, Eric W wrote:

>
> I actually hadn't noticed this problem until Tom pointed it
> out... probably because I'd only recently jumped up from Beta 8 and
> newer versions of ftview were not opening CFF fonts (until Tom's
> recent fixes).
>
> I just tried Werner's suggestion, and used the ftview from the Beta
> 8 demos, but linked it against the current library snapshot. The
> lines do advance fine under that scenario. So that would seem to
> isolate the problem to the changes made to allow ftview to use the
> cache module (or else some other change to ftview or how it is
> built).
>
> >
> > > So, I suspect this is a problem with the caching subsystem of
> > > FreeType 2.  As for the font in question (CMEX10Pro.cff), that is a
> > > CFF font made by extracting the `CFF ' table from an OpenType/CFF
> > > font I made with Adobe's OpenType FDK.  The full-on OpenType font
> > > (CMEX10Pro-Regular.otf) views just fine, and the fprintf prints out:
> > >
> > >     Render_All: step_y: 138, size->metrics.height: 8576.
> >
> > Maybe you can dig out (either from the CVS or from a beta version) an
> > older version of ftview for testing which doesn't use the cache
> > module.
> >
>