[Top][All Lists]

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

Re: fail on osx between 2/4/2009 and 2/5/2009

From: Adrian Robert
Subject: Re: fail on osx between 2/4/2009 and 2/5/2009
Date: Thu, 12 Feb 2009 20:42:42 +0200

On Feb 12, 2009, at 12:22 PM, Kenichi Handa wrote:

In article <address@hidden>, YAMAMOTO Mitsuharu <address@hidden> writes:

On Thu, 12 Feb 2009 16:37:43 +0900, Kenichi Handa <address@hidden> said:
I'm now thinking about these changes:

(1) Revert script-representative-chars to the previous state;
i.e. single entry for mathematical.

It would make nsfont_make_fontset_for_font work again.  But that
function is still a kludge that should be removed, and nsfont_list
needs to be changed so as to handle some of :lang, :script, :registry,
and maybe :chars.

I fully agree.  If Cocoa's font-backend needs some other
information to find a proper font, please let me know.


It might be there is no problem, except that I was unaware of the significance of these various :xxx properties referred to above. When I first implemented the Cocoa font back-end, the list and match APIs were mainly based around the font-entity structure, which contained the following information:

foundry, family, adstyle, registry, weight, slant, width, size, dpi, spacing, avgwidth

Display of characters in multiple scripts was handled by the existing emacs "fontset" structure. The "kludge" Yamamoto Mitsuharu refers to was designed to allow this mechanism to work under NS without the user or distributor needing to manually define a font set. It works reasonably well, judging by the HELLO screen. Of course, users / distributors always had the option to fall back to manual fontset definitions to get better results as in other emacsen.

However, if there is now an alternative method that the backend architecture supports, such that it is feeding 'script' and other properties additional to the font entity structure to the back end, and simply responding to these correctly will obviate the need for fontset specification at all, I would definitely like to change the NS font back end to use this new approach. Is the complete set of :xxx properties the back end should respond to documented somewhere? (I have been using font.h as the implementation reference until now.)


reply via email to

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