|
From: | Dan Williams |
Subject: | Re: [Devel] Freetype Mac .dfont issues? |
Date: | Thu, 13 Feb 2003 12:33:47 -0600 |
Hi,I have here a preliminary patch that allows more than the first face to be used from Freetype for mac fonts, both suitcases and dfonts. This patch is _NOT_ submission quality, I'm simply posting it to get a review if this is the right thing to do.
Caveats with the patch:1) Whacked up to support gcc building with -DTARGET_API_MAC_CARBON, not using CodeWarrior (ignore #include changes) 2) Hack to make both suitcases and dfonts use FT_New_Face_From_dfont(). This function would get renamed. 3) Doesn't work with some fonts like LastResort.dfont, Keyboard.dfont, Taipei.dfont, Beijing.dfont, perhaps because they do not have the correct TrueType version identifier in their 'sfnt' headers. Crashes on FT_FREE(stream) in open_face_from_buffer().
4) Whitespace changesWith these in mind, please review the patch and see if the method seems acceptable.
Thanks, Dan On Wednesday, February 12, 2003, at 12:43 PM, Leonard Rosenthol wrote:
At 12:55 AM -0600 1/24/03, Dan Williams wrote:I'm working on native Mac font support for OpenOffice.org.Great!Presumably, this gets passed down the line to FT_New_Face_dfont(). The following snippet I don't quite understand the logic of./* face_index may be -1, in which case we just need to do a sanity check */ if ( face_index < 0 ) res_index = 1; else { res_index = (short)( face_index + 1 ); face_index = 0; }I would agree that this code is wrong, and needs to be fixed.The rest of the pipeline is fine, and handles loading any res_index and face_index correctly as noted by the comments in the sources.Leonard
ftmac.c.MANYFACES.patch
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |