bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5870: [Aquamacs-bugs] Re: incorrect fontification of non-ascii chars


From: YAMAMOTO Mitsuharu
Subject: bug#5870: [Aquamacs-bugs] Re: incorrect fontification of non-ascii chars on Mac OS X 10.4
Date: Thu, 08 Apr 2010 17:00:24 -0000
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Thu, 30 Jun 2005 07:52:28 +0100, David Reitter <address@hidden> said:

> On 30 Jun 2005, at 04:34, YAMAMOTO Mitsuharu wrote:
>> (create-fontset-from-mac-roman-font
>> "-*-FAMILY-medium-r-normal--SIZE-*-*-*-*-*-mac-roman" nil "NAME")
>> 
>> would do the right thing for normal use.  If one also want to use
>> ETL fonts, one can refer to how "fontset-mac" is defined.

> I'm doing this now, and the definition of a couple of fontsets in
> different sizes (around 25 fontsets) takes over three seconds. Since
> we define the fontsets at startup time, this represents an issue for
> us.

I'm not aware of that (I only define one fontset on startup).
Removing the Foptimize_char_table call in Fset_fontset_font
(fontset.c) seems to improve the speed at least for this case.

> Can fontset creation handled on demand some how?

What should trigger fontset creations?  If it is restricted to user
commands such as menu item selection, then such lazy creation could be
implemented at the user level.

> Why do we handle fonts lust like on X11 again in the Carbon port?
> Do dozens of packages depend on specific fonts being set via the X11
> font-specs?  Does it enable people to actually exchange / share
> font-settings between the Carbon port and the X11 port?

I think that's because the current Emacs internal code, aka
emacs-mule, is created so that it matches the X11 font system.  You
don't want to change the Emacs internal code for the Carbon port, do
you?  Exchanging/sharing font-setting is not relevant here.

> I hope the font handling can and will be revised when the unicode
> branch is merged.

It seems that the unicode branch enables us to define custom charsets
and one can specify such charsets in a font-spec.  I'm not sure how
ATSUI support will change the situation. (I've never worked on that.)

                                     YAMAMOTO Mitsuharu
                                address@hidden








reply via email to

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