[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] Carbon-free fonts support for Mac OS X 10.5 (Leopard) compatibi
|
From: |
mpsuzuki |
|
Subject: |
Re: [ft] Carbon-free fonts support for Mac OS X 10.5 (Leopard) compatibility |
|
Date: |
Tue, 11 Dec 2007 00:17:22 +0900 |
Hi,
On Fri, 23 Nov 2007 16:22:58 +0900
address@hidden wrote:
>I recovered the functionalities on 2007-11-20.
>Some LaserWriter PS font (the pair of "Helvetica LT MM" and
>"HelvLTMM" etc) are not well supported yet, I will take a look
>again.
During the investigation on resource-fork Type1 fonts
bundled to Mac OS X 10.3(Panther), 10.4(Tiger) and 10.5(Leopard),
I found an interesting problem.
This issue may NOT be regression, it is NEW problem
occurs since new fonts bundled to Mac OS X 10.3.
TimesLTMM and HelvLTMM have "POST" resource to store
Adobe Type1 PS font in resource fork, but the resources
are fragmented.
The analysis of resource map in HelveLTMM is following:
[HEAD] offset to resource data: 0x00000100
[HEAD] offset to resource map: 0x0002c1aa
[MAP] offset to type list: 0x001c
[MAP] offset to name list: 0x0482 (length = 0x00000482 - 0x0482)
[MAP] entries of type list: 0x000d
[MAP] reftype:POST, 72 refs, offset 106
[MAP] reftype:BNDL, 0 refs, offset 982
[MAP] reftype:ICN#, 0 refs, offset 994
[MAP] reftype:icl4, 0 refs, offset 1006
[MAP] reftype:icl8, 0 refs, offset 1018
[MAP] reftype:ics#, 0 refs, offset 1030
[MAP] reftype:ics4, 0 refs, offset 1042
[MAP] reftype:ics8, 0 refs, offset 1054
[MAP] reftype:icns, 0 refs, offset 1066
[MAP] reftype:FREF, 0 refs, offset 1078
[MAP] reftype:FLDG, 0 refs, offset 1090
[MAP] reftype:BLND, 0 refs, offset 1102
[MAP] reftype:vers, 0 refs, offset 1114
Here, "POST" resource consists from 72 fragmemnts
(in Apple terminology, 72 references). It seems
that Adobe Type1 PS font is splitted into small
fragments. Possibly, if I collect all fragments,
remove each headers in fragment (each reference
has its header in the beginning) and join all
bodies, I may obtain a normal Adobe Type1 PS font.
There are 2 problems:
P1) each fragments have their headers in the beginning of fragments.
P2) the order of fragment is not in the order of reference number.
About P2, I should describe more. The fragments in
HelveLTMM are stored as following. It seems that
the first fragment of Adobe Type1 PS font is stored
as the final reference (#72), and the 2nd fragment is
stored as the first reference (#0). But I'm not sure
which content in the file declares such ordering.
ref #0
[unknown] length = 0x000007d0
[unknown] 01 00 p e r s a n d 20 p u t 0d d u
[unknown] p 20 33 39 20 2f q u o t e s i n g l
[unknown] e 20 p u t 0d d u p 20 34 30 20 2f p a
[unknown] r e n l e f t 20 p u t 0d d u p 20
[unknown] 34 31 20 2f p a r e n r i g h t 20 p
[unknown] u t 0d d u p 20 34 32 20 2f a s t e r
[unknown] i s k 20 p u t 0d d u p 20 34 33 20 2f
[unknown] p l u s 20 p u t 0d d u p 20 34 34 20
[unknown] 2f c o m m a 20 p u t 0d d u p 20 34
[unknown] 35 20 2f h y p h e n 20 p u t 0d d u
[unknown] p 20 34 36 20 2f p e r i o d 20 p u t
[unknown] 0d d u p 20 34 37 20 2f s l a s h 20 p
[unknown] u t 0d d u p 20 34 38 20 2f z e r o 20
[unknown] p u t 0d d u p 20 34 39 20 2f o n e 20
[unknown] p u t 0d d u p 20 35 30 20 2f t w o 20
[unknown] p u t 0d d u p 20 35 31 20 2f t h r e
ref #1
[unknown] length = 0x000007d0
[unknown] 01 00 e 20 p u t 0d d u p 20 31 35 33 20
[unknown] 2f o c i r c u m f l e x 20 p u t
[unknown] 0d d u p 20 31 35 34 20 2f o d i e r e
[unknown] s i s 20 p u t 0d d u p 20 31 35 35 20
[unknown] 2f o t i l d e 20 p u t 0d d u p 20
[unknown] 31 35 36 20 2f u a c u t e 20 p u t 0d
[unknown] d u p 20 31 35 37 20 2f u g r a v e 20
[unknown] p u t 0d d u p 20 31 35 38 20 2f u c i
[unknown] r c u m f l e x 20 p u t 0d d u p
[unknown] 20 31 35 39 20 2f u d i e r e s i s 20
[unknown] p u t 0d d u p 20 31 36 30 20 2f d a g
[unknown] g e r 20 p u t 0d d u p 20 31 36 31 20
[unknown] 2f d e g r e e 20 p u t 0d d u p 20
[unknown] 31 36 32 20 2f c e n t 20 p u t 0d d u
[unknown] p 20 31 36 33 20 2f s t e r l i n g 20
[unknown] p u t 0d d u p 20 31 36 34 20 2f s e c
...
ref #69
[unknown] length = 0x0000066e
[unknown] 02 00 37 30 b5 K c8 ee f5 H f0 8b 39 d7 09 da
[unknown] 87 22 f8 ff f6 15 df eb 29 f6 dc 90 a1 f0 d5 p
[unknown] 8e c8 96 R e2 dd da i cf l 0f b2 2b da b3 2a
[unknown] 20 bb 9b a5 t 8b b 88 bf 1c 2f e2 30 cd d 85
[unknown] 89 Y 7c b2 G c5 ad a6 e9 26 04 2f C 3d b1 P
[unknown] 2e 3c a7 38 fd ca 07 T 1e 9c eb 0a 99 0f 7c m
[unknown] 3a 5d 1d 1b bd 08 be 9a p c0 06 5d 09 P fb 2f
[unknown] fe a5 80 a bb f 84 b7 Q R de 1c 88 r ac 10
[unknown] 1e 1d fd 28 fe Q a d1 e5 a7 7e b2 95 07 cd 86
[unknown] d2 9b e5 02 db 30 8e 40 30 T b2 dc 7c b9 c2 16
[unknown] 37 c1 o e2 G 9f u a9 2a E 80 f5 9d 01 fa A
[unknown] a7 f6 bf ab a6 1b c4 c6 5c E cf bf 8c z g 5f
[unknown] 97 20 8c m 0b 21 11 39 v 94 36 3f 85 5c 1c 85
[unknown] 7f d6 f2 87 29 f9 2c 27 1a da f1 7e be 94 8b f
[unknown] e2 16 89 cd w 29 10 89 93 97 d3 0e n 85 ac 83
[unknown] fc 7d 8d a7 d8 ac O 9b fe e6 z 31 3f R a1 96
ref #70
[unknown] length = 0x00000216
[unknown] 01 00 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 0d 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 0d 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 0d 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
[unknown] 30
ref #71
[unknown] length = 0x00000002
[unknown] 05 00
ref #72
[unknown] length = 0x000007d2
[unknown] 01 00 25 21 P S 2d A d o b e F o n t
[unknown] 2d 31 2e 30 3a 20 H e l v e t i c a L
[unknown] T M M 20 30 30 31 2e 30 30 36 0d 25 25 C r
[unknown] e a t i o n D a t e 3a 20 W e d 20
[unknown] D e c 20 32 32 20 30 30 3a 32 33 3a 33 34 20
[unknown] 32 30 30 34 0d 25 25 V M u s a g e 3a 20
[unknown] 31 32 30 30 30 30 20 31 35 30 30 30 30 0d 31 37
[unknown] 20 d i c t 20 b e g i n 0d 2f F o n
[unknown] t I n f o 20 31 34 20 d i c t 20 d u
[unknown] p 20 b e g i n 0d 2f v e r s i o n
[unknown] 20 28 30 30 31 2e 30 30 36 29 20 r e a d o
[unknown] n l y 20 d e f 0d 2f C o p y r i g
[unknown] h t 20 28 P a r t 20 o f 20 t h e 20
[unknown] d i g i t a l l y 20 e n c o d e
[unknown] d 20 m a c h i n e 20 r e a d a b
[unknown] l e 20 o u t l i n e 20 d a t a 20
Even if we can detect correct ordering from some
content in the font file, due to the exist of header
in each reference, it's difficult to access as a
FT_Stream object.
The easiest solution may be copying each fragments
onto memory (in fact, ftmac.c implementation does
such). But if it is possible to make a meta-stream
joining short streams, the solution would be slightly
smart, I think.
Werner, how do you think of?
Regards,
mpsuzuki
- Re: [ft] Carbon-free fonts support for Mac OS X 10.5 (Leopard) compatibility,
mpsuzuki <=