Re: macos.texi updated

[Adrian Robert <arobert@cogsci.ucsd.edu>]

On Oct 11, 2005, at 4:01 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Fri, 07 Oct 2005 10:53:22 -0400, Adrian Robert  
>>>>>> <arobert@cogsci.ucsd.edu> 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.