Mon 06 Oct 2008 10:44:32 AM UTC, original submission:
During the tests for sfnt-wrapped CID-keyed font in
suitcase font format, it is found that some suitcase
font could not be loaded by the functions in ftmac.c.
Attached is a patch to generate detailed debug messages
for the functions in ftmac.c (both of src/base/ftmac.c
for Mac OS X, and builds/mac/ftmac.c for Classic Mac OS).
Also I attached the log for Adobe's HeiseiKakuGo-W3
(it's proprietary font and I cannot attach here -
if I find a free font to reproduce the problem,
I will add here).
Both of ftdump and ftoldmac open the font twice:
the 1st is to count the face in the file, and
the 2nd is to open the specified face in the file.
log.carbon shows the expected behaviour. In 2 accesses,
we can find exactly same pointer to the copied image of
sfnt resource in the font. The copied image starts from
the version number "typ1".
log.mpw-m68k and log.mpw-ppc show the unexpected behaviour.
In the 1st access, the pointer returned by GetResource()
points the memory image including the sfnt stream,
it starts with "type1". But in the 2nd access,
GetResource() returns different pointer, and the pointed
buffer does not contain valid sfnt stream. As a result,
the application will fall into very confusing scenario:
- application tries to open a file and check whether
it is valid font file, and how many faces are included.
- application tries to open a face from "successfully
opened font file", but it fails.
The Carbon-free implementation without GetResource() can
load such font files successfully, but it is not available
in Classic Mac OS. Further investigation is needed to detect
what is wrong in the procedure to access the resource in
the font file.
|