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

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

[Randal L. Schwartz]

sometime between 2/4 and 2/5, build broke on OSX.
launches, immediately exits.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

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

[Will Farrington]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

The error I'm seeing is:

*ERROR*: Invalid script or charset name: mathematical-bold


This only exists on frames opened in the window-system. Running emacs  
with -nw works fine.

On Feb 6, 2009, at 8:15 PM, Randal L. Schwartz wrote:

>
> sometime between 2/4 and 2/5, build broke on OSX.
> launches, immediately exits.
>
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503  
> 777 0095
> <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside  
> discussion
>
>
>


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2427 bytes --]

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

[Adrian Robert]

Will Farrington <wcfarrington <at> gmail.com> writes:

> 
> The error I'm seeing is:
> 
> *ERROR*: Invalid script or charset name: mathematical-bold
> 
> This only exists on frames opened in the window-system. Running emacs  
> with -nw works fine.

It seems to be all these new mathematical scripts, they aren't defined
anywhere, whereas others are defined either in international/characters.el
or international/fontset.el.  I don't understand the script system that
well, but don't see how this can be a failure only under OS X.
Are no other platforms experiencing it?

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

[Will Farrington]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]


On Feb 7, 2009, at 5:46 AM, Adrian Robert wrote:

> Will Farrington <wcfarrington <at> gmail.com> writes:
>
>>
>> The error I'm seeing is:
>>
>> *ERROR*: Invalid script or charset name: mathematical-bold
>>
>> This only exists on frames opened in the window-system. Running emacs
>> with -nw works fine.
>
> It seems to be all these new mathematical scripts, they aren't defined
> anywhere, whereas others are defined either in international/ 
> characters.el
> or international/fontset.el.  I don't understand the script system  
> that
> well, but don't see how this can be a failure only under OS X.
> Are no other platforms experiencing it?

I don't have my box running GNU/Linux here, so I can't test on those  
platforms. However, it may be that this error may in fact be another  
problem with the *step port that's causing the mathematical stuff to  
fail.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2427 bytes --]

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

[Kenichi Handa]

In article <loom.20090207T104349-969@post.gmane.org>, Adrian Robert <Adrian.B.Robert@gmail.com> writes:

> Will Farrington <wcfarrington <at> gmail.com> writes:
> > 
> > The error I'm seeing is:
> > 
> > *ERROR*: Invalid script or charset name: mathematical-bold
> > 
> > This only exists on frames opened in the window-system. Running emacs  
> > with -nw works fine.

> It seems to be all these new mathematical scripts, they aren't defined
> anywhere, whereas others are defined either in international/characters.el
> or international/fontset.el.  I don't understand the script system that
> well, but don't see how this can be a failure only under OS X.
> Are no other platforms experiencing it?

I can't reproduce that problem on GNU/Linux and X Window.
The above error is produced by set-fontset-font if the
argument TARGET is invalid.  But, I don't know why
mathematical-bold is given to set-fontset-font as TARGET.
It should appear only as :script property of a font-spec.

In article <m2ljsfisip.fsf@gmail.com>, William Xu <william.xwl@gmail.com> writes:
[...]
> The following fixes the problem for me: 

> diff --git a/lisp/international/characters.el b/lisp/international/characters.el
> index fd03468..97c2e59 100644
> --- a/lisp/international/characters.el
> +++ b/lisp/international/characters.el
> @@ -1147,11 +1147,35 @@ Setup char-width-table appropriate for non-CJK language environment."
>  	 (#x1D200 #x1D24F ancient-greek-musical-notation)
>  	 (#x1D300 #x1D35F tai-xuan-jing-symbol)
>  	 (#x1D360 #x1D37F counting-rod-numeral)
> -	 (#x1D400 #x1D7FF mathematical)
>  	 (#x1F000 #x1F02F mahjong-tile)
>  	 (#x1F030 #x1F09F domino-tile)
>  	 (#x20000 #x2AFFF han)
> -	 (#x2F800 #x2FFFF han)))
> +	 (#x2F800 #x2FFFF han)
> +         ;; math-subgroup
> +         (#x1D400 #x1D433 mathematical-bold)
> +         (#x1D434 #x1D467 mathematical-italic)
[...]

On which system, do you need it?  OS X?

---
Kenichi Handa
handa@m17n.org

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

[Will Farrington]

Kenichi Handa <handa@m17n.org> writes:
> On which system, do you need it?  OS X?

I don't know if any of the other *step systems need this fix, but it is
needed for OS X, yes.

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

[Jules Colding]

On 10/02/2009, at 07.42, Kenichi Handa wrote:

> In article <loom.20090207T104349-969@post.gmane.org>, Adrian Robert <Adrian.B.Robert@gmail.com 
> > writes:
>
>> Will Farrington <wcfarrington <at> gmail.com> writes:
>>>
>>> The error I'm seeing is:
>>>
>>> *ERROR*: Invalid script or charset name: mathematical-bold
>>>
>>> This only exists on frames opened in the window-system. Running  
>>> emacs
>>> with -nw works fine.
>
>> It seems to be all these new mathematical scripts, they aren't  
>> defined
>> anywhere, whereas others are defined either in international/ 
>> characters.el
>> or international/fontset.el.  I don't understand the script system  
>> that
>> well, but don't see how this can be a failure only under OS X.
>> Are no other platforms experiencing it?
>
> I can't reproduce that problem on GNU/Linux and X Window.

I have the exact same problem:

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2221

-- 
   jules

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 10 Feb 2009 09:08:30 +0100, Jules Colding <colding@42tools.com> said:

>>> It seems to be all these new mathematical scripts, they aren't
>>> defined anywhere, whereas others are defined either in
>>> international/ characters.el or international/fontset.el.  I don't
>>> understand the script system that well, but don't see how this can
>>> be a failure only under OS X.  Are no other platforms experiencing
>>> it?
>> 
>> I can't reproduce that problem on GNU/Linux and X Window.

> I have the exact same problem:

If you remove the following lines in fontset.c, the Cocoa/GNUstep port
will launch.

#ifdef HAVE_NS
  nsfont_make_fontset_for_font(name, font_object);
#endif

You may lose non-ASCII characters, because the NS font backend driver
doesn't use either :lang or :script property in a given font spec for
font listing/matching.

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

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

[Jules Colding]

On 10/02/2009, at 09.44, YAMAMOTO Mitsuharu wrote:

>>>>>> On Tue, 10 Feb 2009 09:08:30 +0100, Jules Colding <colding@42tools.com 
>>>>>> > said:
>
>>>> It seems to be all these new mathematical scripts, they aren't
>>>> defined anywhere, whereas others are defined either in
>>>> international/ characters.el or international/fontset.el.  I don't
>>>> understand the script system that well, but don't see how this can
>>>> be a failure only under OS X.  Are no other platforms experiencing
>>>> it?
>>>
>>> I can't reproduce that problem on GNU/Linux and X Window.
>
>> I have the exact same problem:
>
> If you remove the following lines in fontset.c, the Cocoa/GNUstep port
> will launch.
>
> #ifdef HAVE_NS
>  nsfont_make_fontset_for_font(name, font_object);
> #endif
>
> You may lose non-ASCII characters, because the NS font backend driver
> doesn't use either :lang or :script property in a given font spec for
> font listing/matching.

OK, thanks!

Best,
   jules

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 10 Feb 2009 17:44:23 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> If you remove the following lines in fontset.c, the Cocoa/GNUstep port
> will launch.

> #ifdef HAVE_NS
>   nsfont_make_fontset_for_font(name, font_object);
> #endif

> You may lose non-ASCII characters, because the NS font backend driver
> doesn't use either :lang or :script property in a given font spec for
> font listing/matching.

The :registry property is not used effectively there, either.

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

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

[Kenichi Handa]

In article <wlwsbysmu0.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> If you remove the following lines in fontset.c, the Cocoa/GNUstep port
> will launch.

> #ifdef HAVE_NS
>   nsfont_make_fontset_for_font(name, font_object);
> #endif

Ah!  Now I see why the current code doesn't work in
Cocoa/GNUstep port.  Hmmm, I'll think about the solution.  I
want to treat `mathematical-bold', etc. as a a kind of
script-subgroup, not a script.

---
Kenichi Handa
handa@m17n.org

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

[Jason Rumney]

Kenichi Handa wrote:
> Ah!  Now I see why the current code doesn't work in
> Cocoa/GNUstep port.  Hmmm, I'll think about the solution.  I
> want to treat `mathematical-bold', etc. as a a kind of
> script-subgroup, not a script.
>   

That would be better for Windows too. Previously there was a convenient 
correspondence between the scripts in fontset.el and opentype unicode 
subranges. Introducing finer granularity in fontset.el makes the job of 
finding a matching font much harder.

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

[Kenichi Handa]

In article <49917BE9.6020903@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > Ah!  Now I see why the current code doesn't work in
> > Cocoa/GNUstep port.  Hmmm, I'll think about the solution.  I
> > want to treat `mathematical-bold', etc. as a a kind of
> > script-subgroup, not a script.
> >   

> That would be better for Windows too. Previously there was a convenient 
> correspondence between the scripts in fontset.el and opentype unicode 
> subranges. Introducing finer granularity in fontset.el makes the job of 
> finding a matching font much harder.

I'm now thinking about these changes:

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

(2) Add :chars property to font-spec.  The value is a list
    or a vector of characters; the same as that of
    script-representative-chars.  This value supersedes what
    defined in script-representative-chars.

(3) In the default fontset, for each subgroup of
    mathematical characters, register a font-spec with
    :script as 'mathematical and :chars as proper values for
    the subgroup.

(4) Modify ftfont_list to pay attention to :chars property.
    Though, I don't know if the other backends can utilize
    it.

---
Kenichi Handa
handa@m17n.org

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

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 12 Feb 2009 16:37:43 +0900, Kenichi Handa <handa@m17n.org> 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.  Otherwise, the default fontset is just wasted and
the following example would not work properly on the Cocoa/GNUstep
port:

  (insert "Can you see the difference between "
	  (propertize "\x9aa8" 'charset 'japanese-jisx0208)
	  " and "
	  (propertize "\x9aa8" 'charset 'chinese-gb2312)
	  "?")

I'm not against the change (1) above; just some note.

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

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

[Kenichi Handa]

In article <wlbpt85bfo.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Thu, 12 Feb 2009 16:37:43 +0900, Kenichi Handa <handa@m17n.org> 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.

---
Kenichi Handa
handa@m17n.org

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

[Adrian Robert]

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

> In article <wlbpt85bfo.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO  
> Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>
>>>>>>> On Thu, 12 Feb 2009 16:37:43 +0900, Kenichi Handa  
>>>>>>> <handa@m17n.org> 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.

Hi,

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

thanks,
Adrian

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

[Kenichi Handa]

In article <15A24001-137F-469F-8B05-DB31D4E8995D@gmail.com>, Adrian Robert <adrian.b.robert@gmail.com> writes:

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

They should be in the docstring the function font-spec, but
not yet done, sorry.  I'll document them as soon as
possible.

Briefly, the are:

:script -- script name symbol.  script-representative-chars
can be used as an additional hint to find a font.

:lang -- symbol of iso639 two-letter language code.

:otf -- see the docstring of query-font

and I'm going to add:

:chars -- the same format as the cdr part of each element of
script-representative-chars.

---
Kenichi Handa
handa@m17n.org

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

[Adrian Robert]

On Feb 14, 2009, at 3:03 PM, Kenichi Handa wrote:
>
> :script -- script name symbol.  script-representative-chars
> can be used as an additional hint to find a font.
>
> :lang -- symbol of iso639 two-letter language code.
>
> :otf -- see the docstring of query-font
>
> and I'm going to add:
>
> :chars -- the same format as the cdr part of each element of
> script-representative-chars.

OK, thanks, I'll work on responding to them in the NS backend (though  
I'm unsure about the OTF stuff).  Does this new mechanism of   
displaying chars in any script (through passing :script to the  
backend when asking for fonts) operate with any fontset (e.g., if the  
user does set-frame-font or similar), or is it only when the user is  
using the so-called "default" fontset?

As far as prioritization, it was said earlier that :chars should  
override anything in script-representative-chars.  What about  
priority between :lang and :script?  From the backend impl's  
perspective, does :lang really need to be worried about if :script is  
present?  Will there be times when match() or list() receives a spec  
with :lang only (and no :script)?

Also, is there a plan to update the documentation for match() and list 
() in font.h?  I'm willing to do this (after I've finished and tested  
my new implementation) if no one else has time.

thanks,
Adrian

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

[Kenichi Handa]

In article <86BB7F5A-18D1-4D15-A141-FC721BCC7CB4@gmail.com>, Adrian Robert <adrian.b.robert@gmail.com> writes:

> On Feb 14, 2009, at 3:03 PM, Kenichi Handa wrote:
> >
> > :script -- script name symbol.  script-representative-chars
> > can be used as an additional hint to find a font.
> >
> > :lang -- symbol of iso639 two-letter language code.
> >
> > :otf -- see the docstring of query-font
> >
> > and I'm going to add:
> >
> > :chars -- the same format as the cdr part of each element of
> > script-representative-chars.

> OK, thanks, I'll work on responding to them in the NS backend (though  
> I'm unsure about the OTF stuff).  Does this new mechanism of   
> displaying chars in any script (through passing :script to the  
> backend when asking for fonts) operate with any fontset (e.g., if the  
> user does set-frame-font or similar), or is it only when the user is  
> using the so-called "default" fontset?

A font-backend doesn't have to case about fontset.  In other
words, :script property may appean in a font-spec stored in
any fontsets.

> As far as prioritization, it was said earlier that :chars should  
> override anything in script-representative-chars.  What about  
> priority between :lang and :script?  From the backend impl's  
> perspective, does :lang really need to be worried about if :script is  
> present?

In `list' method, all properties in a font-spec must be
sutisfied. If both :script and :lang are specified, it must
return fonts that satify both property.  On the other hand,
`match' method can return a font that, a font-backend
thinks, most fit with the specs.  So, it can put any
priority to the properties, and can even ignore some of
them.

> Will there be times when match() or list() receives a spec  
> with :lang only (and no :script)?

Yes.

> Also, is there a plan to update the documentation for match() and list 
> () in font.h?  I'm willing to do this (after I've finished and tested  
> my new implementation) if no one else has time.

I don't know what else should be added to the
documentations, but if you think the current ones must be
improved, please go ahead.

---
Kenichi Handa
handa@m17n.org

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

[Kenichi Handa]

Sorry for the typo:

In article <E1LYrk6-0004M6-7X@etlken>, Kenichi Handa <handa@m17n.org> writes:
> A font-backend doesn't have to case about fontset.  In other
                                 ^^^^->care

---
Kenichi Handa
handa@m17n.org

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

[Adrian Robert]

>> OK, thanks, I'll work on responding to them in the NS backend (though
>> I'm unsure about the OTF stuff).  Does this new mechanism of
>> displaying chars in any script (through passing :script to the
>> backend when asking for fonts) operate with any fontset (e.g., if the
>> user does set-frame-font or similar), or is it only when the user is
>> using the so-called "default" fontset?
>>
>
> A font-backend doesn't have to case about fontset.  In other
> words, :script property may appean in a font-spec stored in
> any fontsets.

I meant my question more from a user perspective.  If they call 'set- 
frame-font or similar, do ALL of the fonts, on, e.g., the HELLO  
screen, get switched to be the most similar to the user's selection  
with the appropriate charset, or does it just change the ASCII font?   
Experimenting with the non-freetype X build here, just set-frame-font  
doesn't seem to do it, but selecting something from the shift-left- 
mouse menu does (but I can't fully trace out what is getting called  
in this case).



>> Also, is there a plan to update the documentation for match() and  
>> list
>> () in font.h?  I'm willing to do this (after I've finished and tested
>> my new implementation) if no one else has time.
>
> I don't know what else should be added to the
> documentations, but if you think the current ones must be
> improved, please go ahead.

The full list of properties that can appear bundled under the  
FONT_EXTRA property that are important for drivers to take into  
account in match() and list() should be specified somewhere in font.h.

In font.c there is font_property_table, which lists everything that  
is a "first class" property in font.h (explicitly listed in  
font_property_index), plus the following: 'lang', 'script', and  
'otf'.  While the font-spec function mentions 'script' and 'name',  
but not 'lang' or 'otf'.  I'm not sure about the criterion for  
putting something under "EXTRA" or listing it in one place or another  
in font.c, but if the font driver should respond to it, especially  
for something as important as core emacs font selection, it should be  
mentioned in font.h.

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

[Kenichi Handa]

In article <DA118B02-9827-49E5-A419-8C1B02B8C019@gmail.com>, Adrian Robert <adrian.b.robert@gmail.com> writes:

> I meant my question more from a user perspective.  If they call 'set- 
> frame-font or similar, do ALL of the fonts, on, e.g., the HELLO  
> screen, get switched to be the most similar to the user's selection  
> with the appropriate charset, or does it just change the ASCII font?   

Yes, at least that is the intention.

> Experimenting with the non-freetype X build here, just set-frame-font  
> doesn't seem to do it, but selecting something from the shift-left- 
> mouse menu does (but I can't fully trace out what is getting called  
> in this case).

Then, it seems that there's a bug somewhere.  I'll work on it.

>>> Also, is there a plan to update the documentation for match() and  
>>> list
>>> () in font.h?  I'm willing to do this (after I've finished and tested
>>> my new implementation) if no one else has time.
> >
> > I don't know what else should be added to the
> > documentations, but if you think the current ones must be
> > improved, please go ahead.

> The full list of properties that can appear bundled under the  
> FONT_EXTRA property that are important for drivers to take into  
> account in match() and list() should be specified somewhere in font.h.

Ah, I see what you mean.

> In font.c there is font_property_table, which lists everything that  
> is a "first class" property in font.h (explicitly listed in  
> font_property_index), plus the following: 'lang', 'script', and  
> 'otf'.  While the font-spec function mentions 'script' and 'name',  
> but not 'lang' or 'otf'.  I'm not sure about the criterion for  
> putting something under "EXTRA" or listing it in one place or another  
> in font.c, but if the font driver should respond to it, especially  
> for something as important as core emacs font selection, it should be  
> mentioned in font.h.

Ok, I'll document them.

---
Kenichi Handa
handa@m17n.org

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

[Kenichi Handa]

In article <E1LZNv0-0003sq-L9@etlken>, Kenichi Handa <handa@m17n.org> writes:
> > The full list of properties that can appear bundled under the  
> > FONT_EXTRA property that are important for drivers to take into  
> > account in match() and list() should be specified somewhere in font.h.

I've just added comments in font.h, and augmented the
docstring for font-spec (in font.c).

Please tell me if there is any unclear part.

---
Kenichi Handa
handa@m17n.org

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 18 Feb 2009 11:48:19 +0900, Kenichi Handa <handa@m17n.org> said:

> I've just added comments in font.h, and augmented the docstring for
> font-spec (in font.c).

> Please tell me if there is any unclear part.

Besides several typos that can easily be found by a spell checker, I
think the :lang property accepts a list of language symbols as well as
a single language symbol.

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

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

[Kenichi Handa]

In article <wl4oysv3pa.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Wed, 18 Feb 2009 11:48:19 +0900, Kenichi Handa <handa@m17n.org> said:
> > I've just added comments in font.h, and augmented the docstring for
> > font-spec (in font.c).

> > Please tell me if there is any unclear part.

> Besides several typos that can easily be found by a spell checker,

Oops, I've just fixed all typos reported by ispell.

> I think the :lang property accepts a list of language
> symbols as well as a single language symbol.

Ummm, at least `font-spec' doesn't accept a list as :lang
property value.  There surely exist codes that handle a list
for :lang value, but, I don't remember well why I wrote
that part, sigh...

Do you think we should accept a list for :lang property?

---
Kenichi Handa
handa@m17n.org

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 18 Feb 2009 13:01:21 +0900, Kenichi Handa <handa@m17n.org> said:

>> I think the :lang property accepts a list of language symbols as
>> well as a single language symbol.

> Ummm, at least `font-spec' doesn't accept a list as :lang property
> value.  There surely exist codes that handle a list for :lang value,
> but, I don't remember well why I wrote that part, sigh...

Maybe because FcPattern can contain a LangSet?  FWIW, CTFontDescriptor
on Mac OS X 10.5 can also contain multiple languages as a value for
the key kCTFontLanguagesAttribute.

http://developer.apple.com/documentation/Carbon/Reference/CTFontDescriptorRef/Reference/reference.html#//apple_ref/doc/c_ref/kCTFontLanguagesAttribute

I guess they are primarily for obtaining information from a font
(i.e., one font may cover multiple languages) rather than for query
patterns.

> Do you think we should accept a list for :lang property?

I don't have any particular use cases for now, so I don't care.

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

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

[Adrian Robert]

On Feb 18, 2009, at 4:48 AM, Kenichi Handa wrote:

> In article <E1LZNv0-0003sq-L9@etlken>, Kenichi Handa  
> <handa@m17n.org> writes:
>>> The full list of properties that can appear bundled under the
>>> FONT_EXTRA property that are important for drivers to take into
>>> account in match() and list() should be specified somewhere in  
>>> font.h.
>
> I've just added comments in font.h, and augmented the
> docstring for font-spec (in font.c).
>
> Please tell me if there is any unclear part.

Looks clear to me.  Should weight/slant/width also be mentioned under  
list()?  Here is a patch which would add that.


*** font.h.~1.28.~	Wed Feb 18 11:51:23 2009
--- font.h	Wed Feb 18 16:54:13 2009
***************
*** 68,76 ****
   enum font_property_index
     {
       /* FONT-TYPE is a symbol indicating a font backend; currently  
`x',
!        `xft', `ftx' are available on X and gdi on Windows.
!        For Windows, `bdf' and `uniscribe' backends are in progress.
!        For Mac OS X, we need `atm'.  */
       FONT_TYPE_INDEX,

       /* FONT-FOUNDRY is a foundry name (symbol).  */
--- 68,75 ----
   enum font_property_index
     {
       /* FONT-TYPE is a symbol indicating a font backend; currently  
`x',
!        `xft', `ftx' are available on X, gdi on Windows, and ns under
!        Cocoa / GNUstep.  */
       FONT_TYPE_INDEX,

       /* FONT-FOUNDRY is a foundry name (symbol).  */
***************
*** 153,160 ****
       /* In a font-spec, the value is an alist of extra information  
of a
          font such as name, OpenType features, and language coverage.
          In addition, in a font-entity, the value may contain a pair
!        (font-entity . INFO) where INFO is an extra infomation to
!        identify a font (font-driver dependent).  */
       FONT_EXTRA_INDEX,		/* alist		alist */

       /* This value is the length of font-spec vector.  */
--- 152,159 ----
       /* In a font-spec, the value is an alist of extra information  
of a
          font such as name, OpenType features, and language coverage.
          In addition, in a font-entity, the value may contain a pair
!        (font-entity . INFO) where INFO is extra information to  
identify
!        a font (font-driver dependent).  */
       FONT_EXTRA_INDEX,		/* alist		alist */

       /* This value is the length of font-spec vector.  */
***************
*** 172,178 ****
       FONT_NAME_INDEX = FONT_ENTITY_MAX,

       /* Full name of the font (string).  It is the name extracted from
!        the opend font, and may be different from the above.  It may be
          nil if the opened font doesn't give a name.  */
       FONT_FULLNAME_INDEX,

--- 171,177 ----
       FONT_NAME_INDEX = FONT_ENTITY_MAX,

       /* Full name of the font (string).  It is the name extracted from
!        the opened font, and may be different from the above.  It  
may be
          nil if the opened font doesn't give a name.  */
       FONT_FULLNAME_INDEX,

***************
*** 499,505 ****
     /* Symbol indicating the type of the font-driver.  */
     Lisp_Object type;

!   /* 1 iff the font's foundary, family, and adstyle names are case
        sensitve.  */
     int case_sensitive;

--- 498,504 ----
     /* Symbol indicating the type of the font-driver.  */
     Lisp_Object type;

!   /* 1 iff the font's foundry, family, and adstyle names are case
        sensitve.  */
     int case_sensitive;

***************
*** 509,518 ****

     /* List fonts exactly matching with FONT_SPEC on FRAME.  The value
        is a list of font-entities.  The font properties to be  
considered
!      are: :foundry, :family, :adstyle, :registry, :script, :lang, and
!      :otf.  See the function `font-spec' for their meanings.  Note
!      that the last three properties are stored in FONT_EXTRA_INDEX
!      slot of FONT_SPEC.

        The returned value is a list of font-entities.  Each font-entity
        has :type property whose value is the same as the above `type'.
--- 508,517 ----

     /* List fonts exactly matching with FONT_SPEC on FRAME.  The value
        is a list of font-entities.  The font properties to be  
considered
!      are: :family, :weight, :slant, :width, :foundry, :adstyle,
!      :registry, :script, :lang, and :otf.  See the function
!      `font-spec' for their meanings.  Note that the last three
!      properties are stored in FONT_EXTRA_INDEX slot of FONT_SPEC.

        The returned value is a list of font-entities.  Each font-entity
        has :type property whose value is the same as the above `type'.

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

[Kenichi Handa]

In article <9FCA1DF6-50B7-45BF-8082-A8C365F4ADF7@gmail.com>, Adrian Robert <adrian.b.robert@gmail.com> writes:

> On Feb 18, 2009, at 4:48 AM, Kenichi Handa wrote:

> > In article <E1LZNv0-0003sq-L9@etlken>, Kenichi Handa  
> > <handa@m17n.org> writes:
>>>> The full list of properties that can appear bundled under the
>>>> FONT_EXTRA property that are important for drivers to take into
>>>> account in match() and list() should be specified somewhere in  
>>>> font.h.
> >
> > I've just added comments in font.h, and augmented the
> > docstring for font-spec (in font.c).
> >
> > Please tell me if there is any unclear part.

> Looks clear to me.  Should weight/slant/width also be mentioned under  
> list()?

No, because they are not specified in FONT-SPEC.  The `list'
method must return fonts of all their variations.  A proper
font is selected in font_list_entities of font.c.

>  Here is a patch which would add that.

Thank you.  I updated font.h according to that (except for
the last hunk).

---
Kenichi Handa
handa@m17n.org


> *** font.h.~1.28.~	Wed Feb 18 11:51:23 2009
> --- font.h	Wed Feb 18 16:54:13 2009
> ***************
> *** 68,76 ****
>    enum font_property_index
>      {
>        /* FONT-TYPE is a symbol indicating a font backend; currently  
> `x',
> !        `xft', `ftx' are available on X and gdi on Windows.
> !        For Windows, `bdf' and `uniscribe' backends are in progress.
> !        For Mac OS X, we need `atm'.  */
>        FONT_TYPE_INDEX,

>        /* FONT-FOUNDRY is a foundry name (symbol).  */
> --- 68,75 ----
>    enum font_property_index
>      {
>        /* FONT-TYPE is a symbol indicating a font backend; currently  
> `x',
> !        `xft', `ftx' are available on X, gdi on Windows, and ns under
> !        Cocoa / GNUstep.  */
>        FONT_TYPE_INDEX,

>        /* FONT-FOUNDRY is a foundry name (symbol).  */
> ***************
> *** 153,160 ****
>        /* In a font-spec, the value is an alist of extra information  
> of a
>           font such as name, OpenType features, and language coverage.
>           In addition, in a font-entity, the value may contain a pair
> !        (font-entity . INFO) where INFO is an extra infomation to
> !        identify a font (font-driver dependent).  */
>        FONT_EXTRA_INDEX,		/* alist		alist */

>        /* This value is the length of font-spec vector.  */
> --- 152,159 ----
>        /* In a font-spec, the value is an alist of extra information  
> of a
>           font such as name, OpenType features, and language coverage.
>           In addition, in a font-entity, the value may contain a pair
> !        (font-entity . INFO) where INFO is extra information to  
> identify
> !        a font (font-driver dependent).  */
>        FONT_EXTRA_INDEX,		/* alist		alist */

>        /* This value is the length of font-spec vector.  */
> ***************
> *** 172,178 ****
>        FONT_NAME_INDEX = FONT_ENTITY_MAX,

>        /* Full name of the font (string).  It is the name extracted from
> !        the opend font, and may be different from the above.  It may be
>           nil if the opened font doesn't give a name.  */
>        FONT_FULLNAME_INDEX,

> --- 171,177 ----
>        FONT_NAME_INDEX = FONT_ENTITY_MAX,

>        /* Full name of the font (string).  It is the name extracted from
> !        the opened font, and may be different from the above.  It  
> may be
>           nil if the opened font doesn't give a name.  */
>        FONT_FULLNAME_INDEX,

> ***************
> *** 499,505 ****
>      /* Symbol indicating the type of the font-driver.  */
>      Lisp_Object type;

> !   /* 1 iff the font's foundary, family, and adstyle names are case
>         sensitve.  */
>      int case_sensitive;

> --- 498,504 ----
>      /* Symbol indicating the type of the font-driver.  */
>      Lisp_Object type;

> !   /* 1 iff the font's foundry, family, and adstyle names are case
>         sensitve.  */
>      int case_sensitive;

> ***************
> *** 509,518 ****

>      /* List fonts exactly matching with FONT_SPEC on FRAME.  The value
>         is a list of font-entities.  The font properties to be  
> considered
> !      are: :foundry, :family, :adstyle, :registry, :script, :lang, and
> !      :otf.  See the function `font-spec' for their meanings.  Note
> !      that the last three properties are stored in FONT_EXTRA_INDEX
> !      slot of FONT_SPEC.

>         The returned value is a list of font-entities.  Each font-entity
>         has :type property whose value is the same as the above `type'.
> --- 508,517 ----

>      /* List fonts exactly matching with FONT_SPEC on FRAME.  The value
>         is a list of font-entities.  The font properties to be  
> considered
> !      are: :family, :weight, :slant, :width, :foundry, :adstyle,
> !      :registry, :script, :lang, and :otf.  See the function
> !      `font-spec' for their meanings.  Note that the last three
> !      properties are stored in FONT_EXTRA_INDEX slot of FONT_SPEC.

>         The returned value is a list of font-entities.  Each font-entity
>         has :type property whose value is the same as the above `type'.

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

[YAMAMOTO Mitsuharu]

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

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

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

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

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

[Adrian Robert]

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

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

[YAMAMOTO Mitsuharu]

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

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

[Adrian Robert]

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

The "improving" I meant was getting the NS port code more parallel  
with code in other ports, compared to the state, say, a year ago.   
Despite some tension arising from the fact that the other ports  
interface with non-OO and lower-level APIs on the platform's side.



>   And if you read the code of my
> Carbon+AppKit port, you will notice the difference is not in OO vs.
> non-OO.

Is that code available to read somewhere?

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

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 19 Feb 2009 12:30:48 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

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

> The "improving" I meant was getting the NS port code more parallel
> with code in other ports, compared to the state, say, a year ago.
> Despite some tension arising from the fact that the other ports
> interface with non-OO and lower-level APIs on the platform's side.

I see.  I misread it as "the code deviates from those in other ports,
but that makes improvement with respect to OO".

>> And if you read the code of my Carbon+AppKit port, you will notice
>> the difference is not in OO vs.  non-OO.

> Is that code available to read somewhere?

As I've mentioned here several times,

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.2.tar.gz

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

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 10 Feb 2009 21:06:45 +0900, Kenichi Handa <handa@m17n.org> said:

>> If you remove the following lines in fontset.c, the Cocoa/GNUstep port
>> will launch.

>> #ifdef HAVE_NS
>> nsfont_make_fontset_for_font(name, font_object);
>> #endif

> Ah!  Now I see why the current code doesn't work in
> Cocoa/GNUstep port.  Hmmm, I'll think about the solution.  I
> want to treat `mathematical-bold', etc. as a a kind of
> script-subgroup, not a script.

IMO the above nsfont_make_fontset_for_font call is an NS-specific
kludge and should be removed in the first place.  What should be fixed
is at the NS font backend driver side whose `list' function
effectively considers only the :family property in a given font spec.

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

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

[William Xu]

Kenichi Handa <handa@m17n.org> writes:

> On which system, do you need it?  OS X?

Yes.  

-- 
William

http://xwl.appspot.com

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

[William Xu]

Will Farrington <wcfarrington@gmail.com> writes:

> The error I'm seeing is:
>
> *ERROR*: Invalid script or charset name: mathematical-bold

Looks like some necessary updates is missing in
`international/characters.el' when: 

,----
| Author: Kenichi Handa <handa@m17n.org>
| Date:   Thu Feb 5 06:23:19 2009 +0000
| 
|     (script-representative-chars): Remove
|     mathematical.
|     (setup-default-fontset): Add entries for each subgroup of
|     mathematical script.
`----

The following fixes the problem for me: 

diff --git a/lisp/international/characters.el b/lisp/international/characters.el
index fd03468..97c2e59 100644
--- a/lisp/international/characters.el
+++ b/lisp/international/characters.el
@@ -1147,11 +1147,35 @@ Setup char-width-table appropriate for non-CJK language environment."
 	 (#x1D200 #x1D24F ancient-greek-musical-notation)
 	 (#x1D300 #x1D35F tai-xuan-jing-symbol)
 	 (#x1D360 #x1D37F counting-rod-numeral)
-	 (#x1D400 #x1D7FF mathematical)
 	 (#x1F000 #x1F02F mahjong-tile)
 	 (#x1F030 #x1F09F domino-tile)
 	 (#x20000 #x2AFFF han)
-	 (#x2F800 #x2FFFF han)))
+	 (#x2F800 #x2FFFF han)
+         ;; math-subgroup
+         (#x1D400 #x1D433 mathematical-bold)
+         (#x1D434 #x1D467 mathematical-italic)
+         (#x1D468 #x1D49B mathematical-bold-italic)
+         (#x1D49C #x1D4CF mathematical-script)
+         (#x1D4D0 #x1D503 mathematical-bold-script)
+         (#x1D504 #x1D537 mathematical-fraktur)
+         (#x1D538 #x1D56B mathematical-double-struck)
+         (#x1D56C #x1D59F mathematical-bold-fraktur)
+         (#x1D5A0 #x1D5D3 mathematical-sans-serif)
+         (#x1D5D4 #x1D607 mathematical-sans-serif-bold)
+         (#x1D608 #x1D63B mathematical-sans-serif-italic)
+         (#x1D63C #x1D66F mathematical-sans-serif-bold-italic)
+         (#x1D670 #x1D6A3 mathematical-monospace)
+         (#x1D6A4 #x1D6A5 mathematical-italic)
+         (#x1D6A8 #x1D6E1 mathematical-bold)
+         (#x1D6E2 #x1D71B mathematical-italic)
+         (#x1D71C #x1D755 mathematical-bold-italic)
+         (#x1D756 #x1D78F mathematical-sans-serif-bold)
+         (#x1D790 #x1D7C9 mathematical-sans-serif-bold-italic)
+         (#x1D7CA #x1D7D7 mathematical-bold)
+         (#x1D7D8 #x1D7E1 mathematical-double-struck)
+         (#x1D7E2 #x1D7EB mathematical-sans-serif)
+         (#x1D7EC #x1D7F5 mathematical-sans-serif-bold)
+         (#x1D7F6 #x1D7FF mathematical-monospace)))
     (set-char-table-range char-script-table
 			  (cons (car elt) (nth 1 elt)) (nth 2 elt))
     (or (memq (nth 2 elt) script-list)

-- 
William

http://xwl.appspot.com