|
From: | Adrian Robert |
Subject: | Re: macos.texi updated |
Date: | Tue, 11 Oct 2005 13:10:55 -0400 |
On Oct 11, 2005, at 4:01 AM, YAMAMOTO Mitsuharu wrote:
On Fri, 07 Oct 2005 10:53:22 -0400, Adrian Robert <address@hidden> said:In addition, I've been integrating the Cocoa port's font handling with xfaces.c, and can say it's onerous for developers. All of these structures and functions concerned with creating, parsing, and storing the XLFD representation. And you can't avoid using it in a port (at least, all of my attempts to work around it so far have failed), so each platform gets to join in the fun. Thus you find the various functions for faking (and unfaking) them under the two (now three) non-X platforms.What we need to provide with respect to XLFD in the platform-dependent part is x_list_fonts and x_load_font, whose main components are emulations of XListFonts and XLoadQueryFont. Not so many, I think. Just out of curiosity, what part of them do you think is onerous? Is it missing or oversimplified in the Carbon port?
This is subjective.. it works out to about 2-3% of the ports on the unicode 2 branch, but that is a lot:
In Carbon (macterm.c), my brief survey found "only" 500 lines concerned more or less directly with XLFD compatibility.
In W32 (w32fns.c), I found around 1000 lines.Obviously the approach makes a difference here, and I'm hoping the Cocoa port can be less, as it has around 600 lines for all of font management right now ex-XLFD, and doubling that would be depressing. ;-) Bottom line, 500 lines seems a lot when this is over and above both the code doing the main business of x_list_fonts and the code filling in all of the XFontStruct and font_info when loading fonts. Also, xfaces.c itself suffers; if the XLFD stuff were separated out to "xfaces.c" (and "wfaces.c" was made for the windowing-general part), I strongly suspect the code would be easier to understand and maintain.
[Prev in Thread] | Current Thread | [Next in Thread] |