>>>>> 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?
> 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
[EMAIL PROTECTED]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
