freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] Re: [Freetype] Freetype 2 on Mac


From: Dan Williams
Subject: Re: [Devel] Re: [Freetype] Freetype 2 on Mac
Date: Tue, 7 Oct 2003 08:57:56 -0500 (CDT)

Leonard,

Parts of the patch I submitted were just whitespace changes so I could
better understand the flow of the code.  But there were a large number of
important parts, particularly near the bottom of the patch.  The header
file changes on top might not be relevant anmore since I believe I got a
patch in that includes <Carbon/Carbon.h> when using gcc anyway.  The part
that matters most is near the bottom in the new face code, where I walk
the FOND to determine to get all 'sfnt' faces, and then branch off to the
'sfnt' resource reading code to grab the correct one.  I couldn't see a
way of doing it without walking the FOND records, since face enumeration
is dependent on the order of faces in the FOND.  In any case, this
shouldn't matter because no program should be depending on the order of
fonts in the file anyways.  Other interesting parts are the consolidation
of the resource-based check and the .dfont reading stuff near the bottom
as well, since both can be consolidated on Carbon platforms due to the
Resource Manager not caring whether the resource fork is data-fork based
or resource-fork based.

I tested this code successfully with OpenOffice.org running under X11
on Mac OS X.  I decided not to use native .dfont fonts with OOo on OS X
because it meant loading each font into memory _3_ times, twice for OOo
and once for freetype (don't ask, I won't go into it).  Of course, the
problem with Mac fonts is that you have to load them into RAM, because you
can't mmap() a resource fork :(  So I stopped using this code.  Now the
work that the people on Fondu have done (fondu.sourceforge.net) would
allow someone to mmap() and use a .dfont file (because the font data is in
the data fork), it would require changes to applications to walk the
resource map to get to the 'sfnt' resoruces anyway.  And most applications
don't want to have to deal with that.  Freetype could theoretically use
the same code/concept, but that still leaves resource-fork-based fonts out
in the cold.

In any case, whether with resource-fork fonts or .dfont fonts, the
code does work and should accomplish what the poster earlier was after,
correct face enumeration and retrieval of Mac OS multi-face fonts.

Dan

On Tue, 7 Oct 2003, Leonard Rosenthol wrote:

> At 5:25 PM +0200 10/6/03, Werner LEMBERG wrote:
> >Sorry for that.  I really can't comment since I don't have a Mac.  If
> >other Mac users like Leonard or Tom agree I can simply add (an updated
> >version of) your patch.
> >
> 
>       Now that I am back doing Mac stuff (and hopefully some FT2 
> stuff shortly), I'll try to take a look this week...
> 
> 
> Leonard
> -- 
> ---------------------------------------------------------------------------
> Leonard Rosenthol                            <mailto:address@hidden>
> Chief Technical Officer                      <http://www.pdfsages.com>
> PDF Sages, Inc.                              215-629-3700 (voice)
>                                               215-629-0789 (fax)
> 
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]