Hi,
I found that the concatenation of Adobe Type1 PS font fragments
in 'POST' onto memory had ever been implemented 4 years ago :-).
The required fix is only the reordering by their ID number,
instead of their appearance order.
Here is a patch to reorder the fragments of Adobe Type1 PS font
splitted in 'POST' resource, by their resource ID numbers.
By this patch, you can load "HelveLTMM" font.
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.
Regards,
mpsuzuki
Index: include/freetype/internal/ftrfork.h
===================================================================
RCS file: /cvsroot/freetype/freetype2/include/freetype/internal/ftrfork.h,v
retrieving revision 1.4
diff -u -r1.4 ftrfork.h
--- include/freetype/internal/ftrfork.h 6 Dec 2007 10:27:15 -0000 1.4
+++ include/freetype/internal/ftrfork.h 11 Dec 2007 06:43:47 -0000
@@ -36,6 +36,13 @@
/* Don't forget to increment the number if you add a new guessing rule. */
#define FT_RACCESS_N_RULES 9
+ /* Structure to describe a reference in resource, by its resource id */
+ /* and internal offset. `POST' resource expects to be concatenated by */
+ /* the order of resource id, instead of its appearance in the file. */
+ typedef struct FT_RFork_Ref_ {
+ FT_UShort res_id;
+ FT_ULong offset;
+ } FT_RFork_Ref;
/*************************************************************************/
/* */
Index: src/base/ftrfork.c
===================================================================
RCS file: /cvsroot/freetype/freetype2/src/base/ftrfork.c,v
retrieving revision 1.9
diff -u -r1.9 ftrfork.c
--- src/base/ftrfork.c 6 Dec 2007 10:27:15 -0000 1.9
+++ src/base/ftrfork.c 11 Dec 2007 06:43:49 -0000
@@ -132,6 +132,19 @@
}
+ static int
+ ft_raccess_sort_ref_by_id( FT_RFork_Ref* a,
+ FT_RFork_Ref* b )
+ {
+ if ( a->res_id < b->res_id )
+ return ( -1 );
+ else if ( a->res_id > b->res_id )
+ return ( 1 );
+ else
+ return ( 0 );
+ }
+
+
FT_BASE_DEF( FT_Error )
FT_Raccess_Get_DataOffsets( FT_Library library,
FT_Stream stream,
@@ -147,6 +160,7 @@
FT_Memory memory = library->memory;
FT_Long temp;
FT_Long *offsets_internal;
+ FT_RFork_Ref *ref;
error = FT_Stream_Seek( stream, map_offset );
@@ -179,25 +193,38 @@
if ( error )
return error;
- if ( FT_NEW_ARRAY( offsets_internal, *count ) )
+ if ( FT_NEW_ARRAY( ref, *count ) )
return error;
for ( j = 0; j < *count; ++j )
{
- (void)FT_STREAM_SKIP( 2 ); /* resource id */
- (void)FT_STREAM_SKIP( 2 ); /* rsource name */
+ FT_READ_USHORT( ref[j].res_id );
+ (void)FT_STREAM_SKIP( 2 ); /* resource name */
if ( FT_READ_LONG( temp ) )
{
- FT_FREE( offsets_internal );
+ FT_FREE( ref );
return error;
}
- offsets_internal[j] = rdata_pos + ( temp & 0xFFFFFFL );
+ ref[j].offset = rdata_pos + ( temp & 0xFFFFFFL );
(void)FT_STREAM_SKIP( 4 ); /* mbz */
}
+ ft_qsort( ref, *count, sizeof( FT_RFork_Ref ),
+ ( int(*)(const void*, const void*)
)ft_raccess_sort_ref_by_id );
+
+ if ( FT_NEW_ARRAY( offsets_internal, *count ) )
+ {
+ FT_FREE( ref );
+ return error;
+ }
+
+ for ( j = 0; j < *count; ++j )
+ offsets_internal[j] = ref[j].offset;
+
+ FT_FREE( ref );
*offsets = offsets_internal;
return FT_Err_Ok;
On Tue, 11 Dec 2007 12:48:06 +0900
[EMAIL PROTECTED] wrote:
>Hi,
>
>On Mon, 10 Dec 2007 23:33:24 +0100 (CET)
>Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>>> The analysis of resource map in HelveLTMM is following: [...]
>>
>>Thanks. Regarding the structure of such a font it is probably useful
>>to contact Adobe directly in case you can't find an Adobe Technical
>>Note which documents that.
>
>Thank you for comment. By the help of George, I could
>reach a good reference to support the fragmented
>resource-fork PS Type1 font.
>
>>> 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?
>>
>>Please do what you think best!
>
>As George told, it may NOT be the regression but existing
>problem of Carbon-free resource-fork font support. Unfortunately,
>although the fragmented PFB font is legacy, but the issue can
>be important because recent Mac OS X bundles such fonts :-(
>
>As a quick band-aid, I will try to implement a memory-copying
>based solution. After that, I will reconsider about the
>meta-stream solution.
>
>Regards,
>mpsuzuki
>
>
>_______________________________________________
>Freetype mailing list
>[email protected]
>http://lists.nongnu.org/mailman/listinfo/freetype
--
鈴木
_______________________________________________
Freetype mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype
