unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* fontset/font change
@ 2009-03-11 13:50 Miles Bader
  2009-03-11 14:05 ` Jason Rumney
  2009-03-12  0:57 ` Kenichi Handa
  0 siblings, 2 replies; 14+ messages in thread
From: Miles Bader @ 2009-03-11 13:50 UTC (permalink / raw)
  To: emacs-devel

I have been using the following bit of code in my .emacs:

   ;; ugh... force use of Droid Sans Fallback for all non-roman chars
   (let ((fontset (frame-parameter nil 'font)))
     (unless (equal fontset "tty")
       (set-fontset-font fontset 'unicode "Droid Sans Fallback")))

As of today, it no longer seems to work (because the fontset names seem
to be different now, and no longer match the font name).

The intent is to use the font "Droid Sans Fallback" to render anything
that the default font can't (the default font is "Droid Sans Mono", so
they're matched in style etc); "Droid Sans Fallback" contains things
like CJK characters.  If I don't do this, then emacs tends to pick
various random fonts for CJK characters (e.g., Sazanami for japanese).

Is there a better way to do this, which works in the current Emacs?

Thanks,

-Miles

-- 
Patience, n. A minor form of despair, disguised as a virtue.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-11 13:50 fontset/font change Miles Bader
@ 2009-03-11 14:05 ` Jason Rumney
  2009-03-11 14:36   ` Miles Bader
  2009-03-12  1:16   ` Kenichi Handa
  2009-03-12  0:57 ` Kenichi Handa
  1 sibling, 2 replies; 14+ messages in thread
From: Jason Rumney @ 2009-03-11 14:05 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

Miles Bader wrote:
> I have been using the following bit of code in my .emacs:
>
>    ;; ugh... force use of Droid Sans Fallback for all non-roman chars
>    (let ((fontset (frame-parameter nil 'font)))
>      (unless (equal fontset "tty")
>        (set-fontset-font fontset 'unicode "Droid Sans Fallback")))
>
> As of today, it no longer seems to work (because the fontset names seem
> to be different now, and no longer match the font name).
>   
As of now, something still seems to be broken (see bug#2637).

On Windows, I get the message "Can't set a font for partial ASCII 
range." This seems to be coming from line 1511 of fontset.c, while 
processing one of these lines (maybe the latin-jisx0201 line) from 
term/w32-win.el; TARGET is the integer 33:

  ;; Enable Japanese fonts on Windows to be used by default.
  (set-fontset-font t (make-char 'katakana-jisx0201)
            '("*" . "JISX0208-SJIS"))
  (set-fontset-font t (make-char 'latin-jisx0201)
            '("*" . "JISX0208-SJIS"))
  (set-fontset-font t (make-char 'japanese-jisx0208)
            '("*" . "JISX0208-SJIS"))
  (set-fontset-font t (make-char 'japanese-jisx0208-1978)
            '("*" . "JISX0208-SJIS"))





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-11 14:05 ` Jason Rumney
@ 2009-03-11 14:36   ` Miles Bader
  2009-03-12  1:16   ` Kenichi Handa
  1 sibling, 0 replies; 14+ messages in thread
From: Miles Bader @ 2009-03-11 14:36 UTC (permalink / raw)
  To: emacs-devel

Jason Rumney <jasonr@gnu.org> writes:
>>    (let ((fontset (frame-parameter nil 'font)))
>>      (unless (equal fontset "tty")
>>        (set-fontset-font fontset 'unicode "Droid Sans Fallback")))
...
>  (set-fontset-font t (make-char 'katakana-jisx0201)

Hmm, it seems that I can use `t' as the fontset-name to get the effect I
want; this doesn't seem to be mentioned in the docstring:

   (set-fontset-font t 'unicode "Droid Sans Fallback")

-Miles

-- 
Brain, n. An apparatus with which we think we think.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-11 13:50 fontset/font change Miles Bader
  2009-03-11 14:05 ` Jason Rumney
@ 2009-03-12  0:57 ` Kenichi Handa
  2009-03-12  1:05   ` Miles Bader
  1 sibling, 1 reply; 14+ messages in thread
From: Kenichi Handa @ 2009-03-12  0:57 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

In article <87ljrcb23h.fsf@catnip.gol.com>, Miles Bader <miles@gnu.org> writes:

> I have been using the following bit of code in my .emacs:
>    ;; ugh... force use of Droid Sans Fallback for all non-roman chars
>    (let ((fontset (frame-parameter nil 'font)))
>      (unless (equal fontset "tty")
>        (set-fontset-font fontset 'unicode "Droid Sans Fallback")))

> As of today, it no longer seems to work (because the fontset names seem
> to be different now, and no longer match the font name).

As I wrote in the previous mail, the right way to get the
fontset of the current frame is:
  (face-attribute 'default :fontset)

> The intent is to use the font "Droid Sans Fallback" to render anything
> that the default font can't (the default font is "Droid Sans Mono", so
> they're matched in style etc); "Droid Sans Fallback" contains things
> like CJK characters.  If I don't do this, then emacs tends to pick
> various random fonts for CJK characters (e.g., Sazanami for japanese).

Then, you can simply modify the default fontset as this:

  (set-fontset-font "fontset-default" 'unicode "Droid Sans Fallback"
  		    nil 'prepend)

The reason for `prepend' is not to loose the original useful
setting for characters not in "Droid Sans Fallback".

In article <87d4coazzf.fsf@catnip.gol.com>, Miles Bader
<miles@gnu.org> writes:

> Hmm, it seems that I can use `t' as the fontset-name to get the effect I
> want; this doesn't seem to be mentioned in the docstring:

>    (set-fontset-font t 'unicode "Droid Sans Fallback")

Here `t' is the same as "fontset-default".  This facility is
kept just for backward compatibility.

---
Kenichi Handa
handa@m17n.org




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12  0:57 ` Kenichi Handa
@ 2009-03-12  1:05   ` Miles Bader
  2009-03-12  2:53     ` Kenichi Handa
  0 siblings, 1 reply; 14+ messages in thread
From: Miles Bader @ 2009-03-12  1:05 UTC (permalink / raw)
  To: emacs-devel

Kenichi Handa <handa@m17n.org> writes:
>>    (set-fontset-font t 'unicode "Droid Sans Fallback")
>
> Here `t' is the same as "fontset-default".  This facility is
> kept just for backward compatibility.

Isn't it useful?  Is there a reason not to keep it as a feature...?

-miles

-- 
Suburbia: where they tear out the trees and then name streets after them.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-11 14:05 ` Jason Rumney
  2009-03-11 14:36   ` Miles Bader
@ 2009-03-12  1:16   ` Kenichi Handa
  2009-03-12 13:19     ` Jason Rumney
  1 sibling, 1 reply; 14+ messages in thread
From: Kenichi Handa @ 2009-03-12  1:16 UTC (permalink / raw)
  To: Jason Rumney; +Cc: emacs-devel, miles

In article <49B7C51E.6020507@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Miles Bader wrote:
> > I have been using the following bit of code in my .emacs:
> >
> >    ;; ugh... force use of Droid Sans Fallback for all non-roman chars
> >    (let ((fontset (frame-parameter nil 'font)))
> >      (unless (equal fontset "tty")
> >        (set-fontset-font fontset 'unicode "Droid Sans Fallback")))
> >
> > As of today, it no longer seems to work (because the fontset names seem
> > to be different now, and no longer match the font name).
> >   
> As of now, something still seems to be broken (see bug#2637).

> On Windows, I get the message "Can't set a font for partial ASCII 
> range." This seems to be coming from line 1511 of fontset.c, while 
> processing one of these lines (maybe the latin-jisx0201 line) from 
> term/w32-win.el; TARGET is the integer 33:

>   ;; Enable Japanese fonts on Windows to be used by default.
>   (set-fontset-font t (make-char 'katakana-jisx0201)
>             '("*" . "JISX0208-SJIS"))
>   (set-fontset-font t (make-char 'latin-jisx0201)
>             '("*" . "JISX0208-SJIS"))
>   (set-fontset-font t (make-char 'japanese-jisx0208)
>             '("*" . "JISX0208-SJIS"))
>   (set-fontset-font t (make-char 'japanese-jisx0208-1978)
>             '("*" . "JISX0208-SJIS"))

In pre-unicode Emacs, make-char returned generic characters
in the above calls.  But, as a concept of generic character
is deleted in Emacs 23, the above setting anyway doesn't
work now.

The right way for "Enable Japanese fonts on Windows to be
used by default." is:
  (set-fontset-font "fontset-default" 'katakana-jisx0201
                    '("*" . "JISX0208-SJIS") nil 'prepend)
  (set-fontset-font "fontset-default" #x203E
                    '("*" . "JISX0208-SJIS") nil 'prepend)
  (set-fontset-font "fontset-default" 'japanese-jisx0208
                    '("*" . "JISX0208-SJIS") nil 'prepend)
  (set-fontset-font "fontset-default" 'japanese-jisx0208-1978
                    '("*" . "JISX0208-SJIS") nil 'prepend)

Note that U+203E is the only non_ASCII character in
latin-jisx0201.

But, why do we have that kind of setting in term/w32-win.el
only for Japanese?  What does the registry "JISX0208-SJIS"
exactly mean?  Why doesn't the default setting work?

---
Kenichi Handa
handa@m17n.org




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12  1:05   ` Miles Bader
@ 2009-03-12  2:53     ` Kenichi Handa
  2009-03-12  4:01       ` Miles Bader
  2009-03-12  4:10       ` Chong Yidong
  0 siblings, 2 replies; 14+ messages in thread
From: Kenichi Handa @ 2009-03-12  2:53 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

In article <87ab7rwny3.fsf@catnip.gol.com>, Miles Bader <miles@gnu.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>> (set-fontset-font t 'unicode "Droid Sans Fallback")
> >
> > Here `t' is the same as "fontset-default".  This facility is
> > kept just for backward compatibility.

> Isn't it useful?  Is there a reason not to keep it as a feature...?

Ah, wait, I recalled the history.  In Emacs 22, `nil' was
for "fontset-default", but while working on emacs-unicode-2
branch, someone suggested that nil usually should mean the
currently selected one.  I thought that was a good idea, and
was going to change `t' for the default fontset, and `nil'
for the the fontset of the current frame.

But, before finishing it (it seems that I just changed `t'
for the default), I forget about this matter when I got very
busy for the other tasks.  :-(

Sorry for the confusion, but what should I do now?

(1) Just recover the behaviour of Emacs 22: nil for the default
(2) Make nil for the currently selected fontset, and t for the default
(3) (1) and make t for the currently selected one.

---
Kenichi Handa
handa@m17n.org




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12  2:53     ` Kenichi Handa
@ 2009-03-12  4:01       ` Miles Bader
  2009-03-12  4:10       ` Chong Yidong
  1 sibling, 0 replies; 14+ messages in thread
From: Miles Bader @ 2009-03-12  4:01 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel

Kenichi Handa <handa@m17n.org> writes:
> (1) Just recover the behaviour of Emacs 22: nil for the default
> (2) Make nil for the currently selected fontset, and t for the default
> (3) (1) and make t for the currently selected one.

I have no opinion, as I don't think I ever use anything except the
default (does anyone??), but having a shorthand for these things is
good, I think; some of the fontset names seem kind of awkward and
arbitrary to me...

Thanks,

-Miles

-- 
Occam's razor split hairs so well, I bought the whole argument!




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12  2:53     ` Kenichi Handa
  2009-03-12  4:01       ` Miles Bader
@ 2009-03-12  4:10       ` Chong Yidong
  2009-03-12  6:40         ` Kenichi Handa
  1 sibling, 1 reply; 14+ messages in thread
From: Chong Yidong @ 2009-03-12  4:10 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel, Miles Bader

Kenichi Handa <handa@m17n.org> writes:

> In Emacs 22, `nil' was for "fontset-default", but while working on
> emacs-unicode-2 branch, someone suggested that nil usually should mean
> the currently selected one.  I thought that was a good idea, and was
> going to change `t' for the default fontset, and `nil' for the the
> fontset of the current frame.
>
> Sorry for the confusion, but what should I do now?
>
> (1) Just recover the behaviour of Emacs 22: nil for the default
> (2) Make nil for the currently selected fontset, and t for the default
> (3) (1) and make t for the currently selected one.

It seems a little cleaner to have nil specify the current fontset rather
than fontset-default, but only a little.  In your estimation, is there a
significant amount of outside code (e.g. user customizations) that rely
on the old behavior?  If so, I don't think it's profitable to make this
change.

As Miles mentioned, either way this needs to be documented in the
docstring.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12  4:10       ` Chong Yidong
@ 2009-03-12  6:40         ` Kenichi Handa
  2009-03-12 13:39           ` Chong Yidong
  0 siblings, 1 reply; 14+ messages in thread
From: Kenichi Handa @ 2009-03-12  6:40 UTC (permalink / raw)
  To: Chong Yidong; +Cc: miles, emacs-devel

In article <87eix32xfa.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> > Sorry for the confusion, but what should I do now?
> >
> > (1) Just recover the behaviour of Emacs 22: nil for the default
> > (2) Make nil for the currently selected fontset, and t for the default
> > (3) (1) and make t for the currently selected one.

> It seems a little cleaner to have nil specify the current fontset rather
> than fontset-default, but only a little.  In your estimation, is there a
> significant amount of outside code (e.g. user customizations) that rely
> on the old behavior?

I don't think so because I don't here any complaints about
it after I changed t for the default long ago in
emacs-unicode-2 branch.  And even since the merge of about
one year ago, there's no complaint either.

So, if you maintainers think that the incompatible change
now is ok, I'll do (2) above quickly.

> As Miles mentioned, either way this needs to be documented in the
> docstring.

Sure.

---
Kenichi Handa
handa@m17n.org




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12  1:16   ` Kenichi Handa
@ 2009-03-12 13:19     ` Jason Rumney
  2009-03-13  5:18       ` Kenichi Handa
  0 siblings, 1 reply; 14+ messages in thread
From: Jason Rumney @ 2009-03-12 13:19 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-devel, miles

Kenichi Handa wrote:
>>   ;; Enable Japanese fonts on Windows to be used by default.
>>   (set-fontset-font t (make-char 'katakana-jisx0201)
>>             '("*" . "JISX0208-SJIS"))
>>   (set-fontset-font t (make-char 'latin-jisx0201)
>>             '("*" . "JISX0208-SJIS"))
>>   (set-fontset-font t (make-char 'japanese-jisx0208)
>>             '("*" . "JISX0208-SJIS"))
>>   (set-fontset-font t (make-char 'japanese-jisx0208-1978)
>>             '("*" . "JISX0208-SJIS"))
>>     
>
> In pre-unicode Emacs, make-char returned generic characters
> in the above calls.  But, as a concept of generic character
> is deleted in Emacs 23, the above setting anyway doesn't
> work now.
>   

> Note that U+203E is the only non_ASCII character in
> latin-jisx0201.
>   

I didn't know about that one (is it intended to be a combining macron?), 
but isn't ¥ also in latin-jisx0201 (at code point 92)?


> But, why do we have that kind of setting in term/w32-win.el
> only for Japanese? 

Because only Japanese uses SJIS on Windows.

> What does the registry "JISX0208-SJIS" exactly mean?

A JISX0208 font that is available in SJIS encoding. Is there a more 
standard way of writing that?

>   Why doesn't the default setting work?
>   

It seems it does now. I have removed those lines from w32-win.el.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12  6:40         ` Kenichi Handa
@ 2009-03-12 13:39           ` Chong Yidong
  2009-03-13  5:10             ` Kenichi Handa
  0 siblings, 1 reply; 14+ messages in thread
From: Chong Yidong @ 2009-03-12 13:39 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: miles, emacs-devel

Kenichi Handa <handa@m17n.org> writes:

>> It seems a little cleaner to have nil specify the current fontset rather
>> than fontset-default, but only a little.  In your estimation, is there a
>> significant amount of outside code (e.g. user customizations) that rely
>> on the old behavior?
>
> I don't think so because I don't here any complaints about
> it after I changed t for the default long ago in
> emacs-unicode-2 branch.  And even since the merge of about
> one year ago, there's no complaint either.
>
> So, if you maintainers think that the incompatible change
> now is ok, I'll do (2) above quickly.

Please go ahead.  You should make a note of this change in etc/NEWS as
well.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12 13:39           ` Chong Yidong
@ 2009-03-13  5:10             ` Kenichi Handa
  0 siblings, 0 replies; 14+ messages in thread
From: Kenichi Handa @ 2009-03-13  5:10 UTC (permalink / raw)
  To: Chong Yidong; +Cc: miles, emacs-devel

In article <878wnaj1xf.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>> It seems a little cleaner to have nil specify the current fontset rather
>>> than fontset-default, but only a little.  In your estimation, is there a
>>> significant amount of outside code (e.g. user customizations) that rely
>>> on the old behavior?
> >
> > I don't think so because I don't here any complaints about
> > it after I changed t for the default long ago in
> > emacs-unicode-2 branch.  And even since the merge of about
> > one year ago, there's no complaint either.
> >
> > So, if you maintainers think that the incompatible change
> > now is ok, I'll do (2) above quickly.

> Please go ahead.  You should make a note of this change in etc/NEWS as
> well.

Just done.

---
Kenichi Handa
handa@m17n.org




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: fontset/font change
  2009-03-12 13:19     ` Jason Rumney
@ 2009-03-13  5:18       ` Kenichi Handa
  0 siblings, 0 replies; 14+ messages in thread
From: Kenichi Handa @ 2009-03-13  5:18 UTC (permalink / raw)
  To: Jason Rumney; +Cc: emacs-devel, miles

In article <49B90BD9.6060309@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> > Note that U+203E is the only non_ASCII character in
> > latin-jisx0201.
> >   

> I didn't know about that one (is it intended to be a combining macron?), 

No, the unicode name is "OVERLINE", and it's not a combining mark.

> but isn't ¥ also in latin-jisx0201 (at code point 92)?

Ah, right, I've forgotten about that.

> > But, why do we have that kind of setting in term/w32-win.el
> > only for Japanese? 

> Because only Japanese uses SJIS on Windows.

> > What does the registry "JISX0208-SJIS" exactly mean?

> A JISX0208 font that is available in SJIS encoding. Is there a more 
> standard way of writing that?

> >   Why doesn't the default setting work?
> >   

> It seems it does now.

That's good.

> I have removed those lines from w32-win.el.

Thank you.

---
Kenichi Handa
handa@m17n.org




^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2009-03-13  5:18 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-11 13:50 fontset/font change Miles Bader
2009-03-11 14:05 ` Jason Rumney
2009-03-11 14:36   ` Miles Bader
2009-03-12  1:16   ` Kenichi Handa
2009-03-12 13:19     ` Jason Rumney
2009-03-13  5:18       ` Kenichi Handa
2009-03-12  0:57 ` Kenichi Handa
2009-03-12  1:05   ` Miles Bader
2009-03-12  2:53     ` Kenichi Handa
2009-03-12  4:01       ` Miles Bader
2009-03-12  4:10       ` Chong Yidong
2009-03-12  6:40         ` Kenichi Handa
2009-03-12 13:39           ` Chong Yidong
2009-03-13  5:10             ` Kenichi Handa

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).