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

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

>>>>> On Tue, 17 Feb 2009 12:26:08 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

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

(snip)

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

You seem to miss ftfont.c.  It has existed since June 2006, and
script-representative-chars has been used to handle the :script
property since its first version.

http://cvs.savannah.gnu.org/viewvc/emacs/src/ftfont.c?revision=1.1.2.1&root=emacs&sortby=date&view=markup

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

If I'm not familiar with a particular field, I'd rather follow the
implementations of other platforms than making my own way.  At least,
I would ask experts if my own way is appropriate.

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

I didn't say that you should just follow the other platforms.  I said,

  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

Note that I also mentioned "adding features".

Also you are underestimating the new font backend: it is no doubt an
attempt to provide platform-independent way of enhanced font handling,
not just for X11 to "catch up" some other platforms.

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

Could you give some concrete examples of the "improvement" by the use
of OO in the Cocoa/GNUstep port?  And if you read the code of my
Carbon+AppKit port, you will notice the difference is not in OO vs.
non-OO.

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