Re: macos.texi updated

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> 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?

> The only advantage of using a string representation I've seen so far
> is doing the regexp match in x_list_fonts.  But this is a false
> economy -- the extra code to do explicit field-by-field matching on
> a struct would be trivial, and far smaller than all of the XLFD
> translation and manipulation machinery now in place.

The Carbon port has been used the regexp match for XLFD pattern match,
but it turned out that almost a half of the startup time was used for
that.  So, recently it was changed to use more straightforward pattern
matching.  Yes, it might also be a false economy, but it was much
simpler and safer than modifying xfaces.c/fontset.c.  Of course, the
situation might change in Emacs 23.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp