freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft] Debugging a failing API call (FT_Load_Glyph)


From: Alex Taylor
Subject: [ft] Debugging a failing API call (FT_Load_Glyph)
Date: Sun, 01 Jun 2014 19:43:52 +0900 (JST)
User-agent: PMMail/3.15 (os/2; U; Warp 4.5; en-CA; i386; ver 3.15.01.2242)

I'm continuing to work on my OS/2 system font support module that I 
mentioned last year.  It works fairly well so far, with one main problem.

There are certain specific fonts with which the loading of particular
glyphs fails for reasons which I cannot determine.  (Such fonts include
all TTF and OTF versions of the LinuxLibertine fonts newer than v4.75; 
also, several Adobe OTF fonts like Adobe Garamond Pro Regular.)

What happens is that calling FT_Load_Glyph consistently fails on particular 
glyph indices, returning error code 3.  When this happens, my code 
automatically falls back to trying to load the default glyph (which always 
succeeds).

Attempting to render the string "10.AGaramondPro-Regular" in the eponymous 
font, I always end up with "*0.**a*a*o*d**o-Regu***" where * is actually 
the default glyph (X'd square).  The failure with those specific characters 
is consistent.

What I do is retrieve the face object from a cache of recently used ones, 
double-check that the underlying stream is open, translate the requested 
glyph index from the system glyphlist to the face's active CMAP (normally 
MS/Unicode), then set the load flags (in the normal case) to 
FT_LOAD_DEFAULT.

   error = FT_Load_Glyph( face, gindex, load_format );
   if (error)
   {
       // {dump some info to a log}
       // try to load the default glyph as a fallback
       error = FT_Load_Glyph( face->face, 0, load_format );
       if (error) {
            // {log the error and abort}
       }
   }

Looking at the log, the face values all look correct, including charmap 0 
being active, and gindex seems to be correct. 

Most frustratingly, I cannot replicate the error in a standalone program. 
Using the same OTF file, the same charmap and character values (resolving 
to the same glyph index) in a small test program, FT_Load_Glyph returns the 
glyph without any trouble and I can render it. 

So there must presumably be something specific to the (complex) environment 
of my full program that triggers it.  But how can I effectively debug 
what's going on?  

The input to FT_Load_Glyph APPEARS to be entirely correct, but it simply 
returns the error code 3 with these particular glyph indices.  Is there any 
relatively straightforward way for me to debug what's going on inside the 
API?

Thanks...
-- 
Alex Taylor <address@hidden>
http://www.altsan.org






reply via email to

[Prev in Thread] Current Thread [Next in Thread]