[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: Tue, 17 Feb 2009 12:26:08 +0200

On Feb 16, 2009, at 2:33 AM, YAMAMOTO Mitsuharu wrote:

On Thu, 12 Feb 2009 20:42:42 +0200, Adrian Robert <address@hidden> said:

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

Both the list and match are designed to take a font spec and returns
either font entities or a font entity.  So the knowledge of font specs
as well as font entities were necessary to implement them properly in
the first place.

At the beginning of font.h, font-spec and font-entity are described as lists of properties, and then those properties are listed in font_property_index. There is one property, "FONT_EXTRA_INDEX", that serves as a kind of basket for various additional properties, that don't merit being "first class" (listed explicitly) for whatever reason. The doc says, "extra information of a font such as name, OpenType features, and language coverage".

At the time I was writing the NS backend (fall 2006) -- with only Handa-san's X impl and emacs's previous font-handling architecture to go by -- it wasn't clear to me that although some of these properties ("OpenType features" and "name") were not important for all back- ends, there were other "extra" properties, such as ":script" and friends, that were.

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.

Also, the existence of script-representative-chars you used in the
kludge implies there were already some mechanisms such as the :script
property in the font specs for selecting appropriate fonts without
needing manual definition of fontsets.  You could have noticed that if
you read the implementations of other font backend drivers.

The only other impl was the X one, and it was difficult to separate out from the code what was X-specific, and what was generally applicable for all backends. At the time I understood that emacs handled multiple scripts through explictly-defined fontsets. script- representative-chars was there, but didn't seem to be used for anything, and most of the X code seemed centered around low-level font glyph encoding schemes like the "'japanese-jisx0208" and "chinese-gb2312" that you use in your example, rather than scripts. NS does not expose font glyph encoding schemes to the developer.

There were also the has_char() and encode_char() methods in the font backend driver API. These led me to think that the determination of whether a font was suitable for rendering a given script would be done automatically by the font backend common code (through calling these methods on representative characters). So I might not have been as persistent in tracking down things relating to ":script" as I might have been.

In general, you should consider/propose platform-independent ways of
solving problems/adding features rather than doing that by adding
platform-specific kludges, unless they are inherently
platform-specific matters.  Such kludges might be acceptable for
unofficial distributions, but not for the official Emacs distribution,

I agree that platform-independent is better. However I did not have enough knowledge at the time of what Handa-san's full plans were, of how X fonts worked in Xft/Freetype, nor whether what I did under NS was possible under X. Nonetheless adding it was valuable because (a) it allowed users on one platform to benefit from automatically- generated fontsets, and (b) it COULD have inspired people who ARE familiar with other platforms to try implementing something like it themselves.

Allowing for some innovation around the edges on different platforms can help drive the entire application forward on all systems. Disallowing it, you have a situation where no one tries any new features, because they cannot themselves do them for all platforms. For example, the font backend system itself was started only on X. That brought some new functionality, but it also "caught X up" to functionality that had already been innovated on other platforms, such as antialiasing.

Anyway, I appreciate your recent criticism which has been helpful in improving the port, but it would be even nicer if you would help out with the code. ;-) Together we could make it better and hopefully satisfying all of your standards as well as mine and most importantly the needs of users.

You have expressed reservations because you feel the port tries to do things in a different way from the rest of emacs, but that is not really accurate. It would be counterproductive. As I've said before, the port aims for clean, clear code taking into account both other ports' approaches and the fact that Cocoa is an OO API. It's not always going to fit as well as Carbon or X, but it has been improving. Certainly my efforts over the past months have been to shift things rather towards using common approaches than away. It doesn't happen overnight with a codebase of that size, but it gets better, and your help would speed that process.


reply via email to

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