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

[Adrian Robert <adrian.b.robert@gmail.com>]

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

>>>>>> On Thu, 12 Feb 2009 20:42:42 +0200, Adrian Robert  
>>>>>> <adrian.b.robert@gmail.com> 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.


Adrian