emacs-devel
[Top][All Lists]
Advanced

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

Re: macos.texi updated


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.







reply via email to

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