On Oct 11, 2005, at 4:01 AM, YAMAMOTO Mitsuharu wrote:
On Fri, 07 Oct 2005 10:53:22 -0400, Adrian Robert
<[EMAIL PROTECTED]> 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.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
