Re: [ft] Carbon-free fonts support for Mac OS X 10.5 (Leopard) compatibility

[mpsuzuki]

Hi all,

On Tue, 11 Dec 2007 15:57:08 +0900
address@hidden wrote:
>However, still some Adobe Type1 PS fonts for MacOS may not be
>supported. According to Adobe TechNote #5040, there is a font
>format that changes the storage of fragments from resource fork
>to data fork in mid-way. To support such, Mac_Read_POST_Resource()
>or IsMacResource() should be fixed. I will try when I could
>obtain sample font.

I searched my several CDs of MacOS fonts, I couldn't find.

I tried to make an Adobe PS Type1 font whose PFB stream
is splitted in data and resource fork, but I couldn't success.
I attached failed samples I made (ditto archive format).

--

The common resource-fork based Adobe PS Type1 font has
a POST table in its resource fork, its structure is an
array of small chunks (upto 0x800 octet?) and each
chunks has a 16bit flag. The first 8bit is used to
mark the content type of chunk.

type 0x01 means ASCII, type 0x02 means binary,
and type 0x05 means the end of file.
According to Adobe TechNote #5040, type 0x04 means
the content should be loaded from data fork, and
parser should not read resource fork anymore.


      length        type    content
    +=============+=======+=======================+ 
#0  | 00 00 08 00 | 01 00 | %!PS-AdobeFont...     |
    +-------------+-------+-----------------------+ ASCII header
#1  | 00 00 08 00 | 01 00 | dup /32 space put...  |
    +-------------+-------+-----------------------+
#2  | 00 00 0x xx | 01 00 | ... eexec |
    +=============+=======+=======================+
#3  | 00 00 08 00 | 02 00 | address@hidden@address@hidden@j0...     |
    +-------------+-------+-----------------------+ binary body
#4  | 00 00 08 00 | 02 00 | ...                   |
    +-------------+-------+-----------------------+
 :  | : : :                                       |
    +-------------+-------+---------+-------------+
    | 00 00 0x xx | 02 00 | ...     |
    +=============+=======+===================+
#N-2| 00 00 0x xx | 01 00 |    ...{restore}if |     ASCII trailer
    +=============+=======+===================+
#N-1| 00 00 00 02 | 05 00 |                         EOF mark
    +-------------+-------+

resource map tells "N", the number how many chunks
are refered by "POST" table.

I created a few variats by changing the position to
insert type 0x04 chunk. I changed the font file
by binary editor (bvi), so the unrefered contents
are left.

case 1) whole content is stored in data fork.

I concatenated all chunk contents (without 32bit
length, 16bit type) and wrote it to datafork.
The resource fork chunks are rewritten as following

      length        type    content
    +=============+=======+=======================+ 
#0  | 00 00 00 02 | 04 00 | >>>> GO TO DATA FORK
    +-------------+-------+-----------------------+ 
 :  | : : :                                       |
    +-------------+-------+---------+-------------+

N is rewriten to zero, to declare there is only 1 chunk.

case 2) binary and later are stored in data fork.

I concatenated all chunk contents except of ASCII header
and wrote it to datafork. The resource fork chunks are
rewritten as following

      length        type    content
    +=============+=======+=======================+ 
#0  | 00 00 08 00 | 01 00 | %!PS-AdobeFont...     |
    +-------------+-------+-----------------------+ ASCII header
#1  | 00 00 08 00 | 01 00 | dup /32 space put...  |
    +-------------+-------+-----------------------+
#2  | 00 00 0x xx | 01 00 | ... eexec |
    +=============+=======+=======================+
#3  | 00 00 00 02 | 04 00 | >>>> GO TO DATA FORK
    +-------------+-------+-----------------------+ 
 :  | : : :                                       |
    +-------------+-------+---------+-------------+

N is rewritten to 3, to declare the first 4 chunks
should be refered.

case 3) ASCII trailer and later are stored in data fork.

I concatenated ASCII trailer contents and wrote it
to data fork, the resource fork chunks are rewritten
as following

      length        type    content
    +=============+=======+=======================+ 
#0  | 00 00 08 00 | 01 00 | %!PS-AdobeFont...     |
    +-------------+-------+-----------------------+ ASCII header
#1  | 00 00 08 00 | 01 00 | dup /32 space put...  |
    +-------------+-------+-----------------------+
#2  | 00 00 0x xx | 01 00 | ... eexec |
    +=============+=======+=======================+
#3  | 00 00 08 00 | 02 00 | address@hidden@address@hidden@j0...     |
    +-------------+-------+-----------------------+ binary body
#4  | 00 00 08 00 | 02 00 | ...                   |
    +-------------+-------+-----------------------+
 :  | : : :                                       |
    +-------------+-------+---------+-------------+
    | 00 00 0x xx | 02 00 | ...     |
    +=============+=======+=========+
#N-2| 00 00 00 02 | 04 00 | >>>> GO TO DATA FORK    ASCII trailer


N is rewritten to N-1, to declare the first N-2 chunks
should be refered.

--

I tested these fonts under Classic MacOS + ATM Light environment.
As a result: case 1 & 2 don't work, only case 3 works.
I'm suspicious if my variant in case 3 is parsed as expected,
because ASCII trailer won't include vital information.
Again I have to postpone the support of type4 chunk support until
the day I have an example.

Regards,
mpsuzuki

rfork-type4.cpz
Description: Binary data