freetype-devel
[Top][All Lists]
Advanced

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

Re: [Devel] anybody working for TrueTypeGX / other Macintosh bitmap font


From: mpsuzuki
Subject: Re: [Devel] anybody working for TrueTypeGX / other Macintosh bitmap font support?
Date: Sat, 21 Jun 2003 16:28:21 +0900

Dear Mr. Werner Lemberg,

>Not really.  OpenType and TrueTypeGX should be basically provided one
>level higher than FreeType (cf. the stuff in the `otlayout'
>directory) since it doesn't directly belong to rendering.

>You should probably check related emails regarding OpenType in the
>FreeType's `devel' archive to see what kind of interface we plan to
>use.

OK, so I will refer otlayout sources. There's any documentation of
the design of otlayout API? I think TrueType GX Layout should be
similar to the OpenType Layout as far as possible.

>On the other hand, support for other bitmap fonts can be directly
>included.

OK.

--

By the way, FreeType projects has any decided direction about how
to access resource fork of HFS? Using Carbon API might be most
proper method, and it will be welcomed by developers/users on MacOS.
Current font environment on MacOS decreases the asymmetry in resrouce
and data fork (as *.dfont is introduced), but still there's left
asymmetry, especially old/obsolete fonts.

At present I'm working on UFS, so without Carbon API, because I
could not find convenient script language to access resource fork.

Sometimes HFS (or other filesystems which somehow MacOS can store
resource fork - like FAT, UFS) can be mounted other operating systems
without Carbon API (e.g. Linux). So, I wish if there's some system
independent abstraction layer - something like minimally subsetted
Carbon API to access resource & data fork.

I know such abstraction layer itself is out of scope of FreeType.
But using such can make FreeType portable. In fact, most license
of commercial fonts say as "you cannot modify our product, just
use it as it is", so dissembling MacOS font and make pure sfnt font
file from it is not permitted. Such difficulty is just because we
don't have portable method to access resource fork.

Please let me know your thought - if there's thin portable library
to access resource fork, FreeType can utilize it? 

Regards,

mpsuzuki



reply via email to

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