[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
- [ft] Debugging a failing API call (FT_Load_Glyph),
Alex Taylor <=