unicode font-backend + tiling

unicode font-backend + tiling

[Miles Bader]

I tried merging the current unicode branch with my tiling and lexbind
branches (mostly so I could get anti-aliased fonts using the new font
backend stuff).... I'm happy to report that there were only a few minor
problems, and generally it merged without incident.

Here's a screen shot with image backgrounds ("tiling") + anti-aliased
fonts:

   http://snogglethorpe.googlepages.com/emacs-unicodetilinglexbind-0.png

-Miles
-- 
x
y
Z!

Re: unicode font-backend + tiling

[Leo]

On Tuesday,  5 Dec 2006, Miles Bader wrote:

> I tried merging the current unicode branch with my tiling and lexbind
> branches (mostly so I could get anti-aliased fonts using the new font
> backend stuff).... I'm happy to report that there were only a few minor
> problems, and generally it merged without incident.
>
> Here's a screen shot with image backgrounds ("tiling") + anti-aliased
> fonts:
>
>    http://snogglethorpe.googlepages.com/emacs-unicodetilinglexbind-0.png
>
> -Miles

That's a very interesting screenshot. Will those features be merged
into Emacs once 22 is released?

-- 
Leo

Re: unicode font-backend + tiling

[Miles Bader]

Leo <sdl.web@gmail.com> writes:
> That's a very interesting screenshot. Will those features be merged
> into Emacs once 22 is released?

At least some of them will... :-)

The anti-aliased fonts are part of a reworking of font handling on the
unicode branch, which will become the new trunk once 22 is released.
The image-background stuff is my own patch, which I think may be
mergeable in the future (while arguably it's just bling, I don't think
it's all that intrusive).  [Other stuff like lexbind, who knows...]

[After using it for a while, I find I really like the aa font support
... text looks so _pretty_ now (and Emacs is, after all, all about
text!).]

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?

Re: unicode font-backend + tiling

[Leo]

On Tuesday, 05 Dec 2006, Miles Bader wrote:

> Leo <sdl.web@gmail.com> writes:
>> That's a very interesting screenshot. Will those features be merged
>> into Emacs once 22 is released?
>
> At least some of them will... :-)
>
> The anti-aliased fonts are part of a reworking of font handling on the
> unicode branch, which will become the new trunk once 22 is released.
> The image-background stuff is my own patch, which I think may be
> mergeable in the future (while arguably it's just bling, I don't think
> it's all that intrusive).  [Other stuff like lexbind, who knows...]

I love aa too. However Chinese characters look hazy when aa is enabled.

I check Chinese characters in gedit (gnome editor); it seems it
disable aa for Chinese characters. I wonder how can emacs do the same.

-- 
Leo

Re: unicode font-backend + tiling

[Miles Bader]

On 12/5/06, Leo <sdl.web@gmail.com> wrote:
> I love aa too. However Chinese characters look hazy when aa is enabled.
>
> I check Chinese characters in gedit (gnome editor); it seems it
> disable aa for Chinese characters. I wonder how can emacs do the same.

By default, Emacs 23 doesn't use AA for non-ascii character sets yet
(so it just uses the old bitmap mechanism).

If I enable AA for CJK characters in Emacs, they do actually look
fuzzy[*] -- this is slightly surprising to me, since I think the
default configuration for freetype disables AA for CJK characters.  So
maybe Emacs is overriding the defaults (I don't really know how that
stuff works)?  If so, I assume it can be tweaked to not do that...

[*] BTW, don't think AA actually _always_ looks bad for CJK -- I've
seen some really, really nicely done examples, I think it was some
type1 cjk fonts where freetype was using the normally disabled
autohinter (disabled for some stupid patent reason).

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <m28xhnrr4z.fsf@sl392.st-edmunds.cam.ac.uk>, Leo <sdl.web@gmail.com> writes:

> I love aa too. However Chinese characters look hazy when aa is enabled.

> I check Chinese characters in gedit (gnome editor); it seems it
> disable aa for Chinese characters. I wonder how can emacs do the same.

It's quite easy to display characters without aa
(anti-aliasing), but the problem is how we specify aa or
non-aa for a specific set of characters/fonts.  We may want
aa even for Chinese characters if the font size is smaller
than some threshold.  So, we must design a flexible
interface that can be controlled by users.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> It's quite easy to display characters without aa
> (anti-aliasing), but the problem is how we specify aa or
> non-aa for a specific set of characters/fonts.  We may want
> aa even for Chinese characters if the font size is smaller
> than some threshold.  So, we must design a flexible
> interface that can be controlled by users.

Couldn't Emacs, by default at least, just let xft/freetype/whatever
decide?  I was under the impression that other apps just did that, and
it seems to work well (roman letters use aa, cjk doesn't use aa at
"normal" sizes, but _does_ at big sizes).

Sorry if the above doesn't make much sense ... :-)

-Miles
-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: unicode font-backend + tiling

[Zhang Wei]

Kenichi Handa <handa@m17n.org> writes:

> It's quite easy to display characters without aa
> (anti-aliasing), but the problem is how we specify aa or
> non-aa for a specific set of characters/fonts.  We may want
> aa even for Chinese characters if the font size is smaller
> than some threshold.  So, we must design a flexible
> interface that can be controlled by users.

Why don't we just respect fontconfig (fonts.conf)?

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <buopsazlzqp.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > It's quite easy to display characters without aa
> > (anti-aliasing), but the problem is how we specify aa or
> > non-aa for a specific set of characters/fonts.  We may want
> > aa even for Chinese characters if the font size is smaller
> > than some threshold.  So, we must design a flexible
> > interface that can be controlled by users.

> Couldn't Emacs, by default at least, just let xft/freetype/whatever
> decide?

Perhaps possible for xft backend.  I've just installed a
change for that.

> I was under the impression that other apps just did that, and
> it seems to work well (roman letters use aa, cjk doesn't use aa at
> "normal" sizes, but _does_ at big sizes).

I've thought that aa is useful for small sizes.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Leo]

On TUE, 5 DEC 2006, Kenichi Handa wrote:

> In article <buopsazlzqp.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:
>
>> Kenichi Handa <handa@m17n.org> writes:
>> > It's quite easy to display characters without aa
>> > (anti-aliasing), but the problem is how we specify aa or
>> > non-aa for a specific set of characters/fonts.  We may want
>> > aa even for Chinese characters if the font size is smaller
>> > than some threshold.  So, we must design a flexible
>> > interface that can be controlled by users.
>
>> Couldn't Emacs, by default at least, just let xft/freetype/whatever
>> decide?
>
> Perhaps possible for xft backend.  I've just installed a
> change for that.

I update emacs to incorporate your changes, but can't see the
difference i.e. Chinese chars still look blurry.

-- 
Leo

Re: unicode font-backend + tiling

[Mikhail Gusarov]

You (handa@m17n.org) wrote:

 KH> So, we must design a flexible interface that can be controlled by
 KH> users.

The name of this interface is fontconfig.

-- 

Re: unicode font-backend + tiling

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
>> Couldn't Emacs, by default at least, just let xft/freetype/whatever
>> decide?
>
> Perhaps possible for xft backend.  I've just installed a
> change for that.

I just tried your change, and it's still using AA at normal sizes.

Here's the lisp I used to enable CJK AA (which I got from an earlier
post of yours); is there a better way to do it?:  

   (set-fontset-font "fontset-default" 'kana "さざみゴシック")
   (set-fontset-font "fontset-default" 'han "さざみゴシック")

However I've _also_ just tried my test in gnome-terminal and some other
gnome apps, and they do the same thing (use AA always, even for CJK) in
the "body" text.  However the same programs use non-AA CJK text in menus
etc.!  So I don't know where that decision is getting made....

Firefox on the other hand, even its "body" text, uses AA at small sizes,
non-AA at normal sizes, and AA at big sizes, which I gather is the
desired behavior.

>> I was under the impression that other apps just did that, and
>> it seems to work well (roman letters use aa, cjk doesn't use aa at
>> "normal" sizes, but _does_ at big sizes).
>
> I've thought that aa is useful for small sizes.

Yes, it is, but I didn't test at small sizes... :-)

I think firefox uses AA for CJK at small sizes too.

-Miles
-- 
I'd rather be consing.

Re: unicode font-backend + tiling

[Jan Djärv]

Miles Bader skrev:
> I tried merging the current unicode branch with my tiling and lexbind
> branches (mostly so I could get anti-aliased fonts using the new font
> backend stuff).... I'm happy to report that there were only a few minor
> problems, and generally it merged without incident.
> 
> Here's a screen shot with image backgrounds ("tiling") + anti-aliased
> fonts:
> 
>    http://snogglethorpe.googlepages.com/emacs-unicodetilinglexbind-0.png
> 

Aah, nice.  Emacs enters the eye-candy competition :-)

	Jan D.

Re: unicode font-backend + tiling

[Jan Djärv]

Kenichi Handa skrev:
> In article <buopsazlzqp.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:
> 
>> Kenichi Handa <handa@m17n.org> writes:
>>> It's quite easy to display characters without aa
>>> (anti-aliasing), but the problem is how we specify aa or
>>> non-aa for a specific set of characters/fonts.  We may want
>>> aa even for Chinese characters if the font size is smaller
>>> than some threshold.  So, we must design a flexible
>>> interface that can be controlled by users.
> 
>> Couldn't Emacs, by default at least, just let xft/freetype/whatever
>> decide?
> 
> Perhaps possible for xft backend.  I've just installed a
> change for that.
> 
>> I was under the impression that other apps just did that, and
>> it seems to work well (roman letters use aa, cjk doesn't use aa at
>> "normal" sizes, but _does_ at big sizes).
> 
> I've thought that aa is useful for small sizes.

Usually not.  The smaller size the worse it looks.  OSX has a system setting 
where you can set the smallest size when AA is used.

	Jan D.

Re: unicode font-backend + tiling

[Miles Bader]

Jan Djärv <jan.h.d@swipnet.se> writes:
>> I've thought that aa is useful for small sizes.
>
> Usually not.  The smaller size the worse it looks.  OSX has a system setting 
> where you can set the smallest size when AA is used.

The common wisdom, as I understand it, is that AA is "bad" for normal
sizes, but good at big sizes, and good at very small sizes.  Try it with
firefox or something -- without AA very small characters simply become
unrecognizable blobs at some point, but with AA, they are surprisingly
readable, if unpleasantly fuzzy (and better fuzzy than unreadable :-).

Where exactly the dividing lines are I guess depends on many factors,
how good the rendering technology is, the font hinting, the general font
design, etc.

I think freetype displaying latin characters with bitstream vera fonts
is good enough at AA that it's better to always leave it on, even at
normal body text sizes (it's amazingly good -- for instance it keeps
horizontal and vertical strokes as single-pixel high contrast lines
where possible, only using other colors to subtly fill in various round
bits; vera's design seems to mesh well with this to yield a very
readable result).

Some other platform/font combinations aren't as good, so you might want
to disable AA at normal body text sizes for readability.  E.g., the
current discussion is about CJK fonts, which often have many more fiddly
bits than latin fonts, and those CJK fonts I have access to don't look
great when AA'd at normal sizes (it's a shame because in the past I have
seen extremely good anti-aliased CJK fonts on Debian, and I have no idea
what exact combination of factors was responsible!).

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: unicode font-backend + tiling

[Juanma Barranquero]

On 12/5/06, Miles Bader <miles@gnu.org> wrote:

> By default, Emacs 23 doesn't use AA for non-ascii character sets yet

Non-ASCII or non-latin-*?

                    /L/e/k/t/u

Re: unicode font-backend + tiling

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> By default, Emacs 23 doesn't use AA for non-ascii character sets yet
>
> Non-ASCII or non-latin-*?

I'm not sure the test it actually uses .... :-)

It seems more like "non-latin", as most european characters are
antialiased too, though I have noticed the odd latin character displayed
as a bitmap; I dunno really...

-Miles

-- 
We live, as we dream -- alone....

Re: unicode font-backend + tiling

[Miles Bader]

BTW, is there a way I can turn on --enable-font-backend by default?

The README.unicode mentions a "Emacs.FontBackend:" X resource, but that
seems to be only used when the font-backend is enabled with
--enable-font-backend.

Thanks,

-Miles
-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <f7ccd24b0612050203m4bc7daabiac7f0c392501df80@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes:

> On 12/5/06, Miles Bader <miles@gnu.org> wrote:
> > By default, Emacs 23 doesn't use AA for non-ascii character sets yet

> Non-ASCII or non-latin-*?

Non-ASCII.  Because the default fontset specifies X fonts
for them.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <buovekqliig.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:

> BTW, is there a way I can turn on --enable-font-backend by default?

No.  That's simply because I didn't want to design a
soon-to-be-obsolete new interface for that.  I am going to
delete all legacy font-handling codes and thus make
"--enable-font-backend" the default.

Isn't this good enough for the moment?

% alias emacs-fb='emacs-unicode --enable-font-backend'

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> Isn't this good enough for the moment?
>
> % alias emacs-fb='emacs-unicode --enable-font-backend'

It's just that I often start emacs via non-command-line methods (menus,
via EDITOR, etc.; it's a pain to go though and change all those things).

I guess for now I can just hack emacs.c to default the command-line
option to "on".

As far as I can tell though, the feature is pretty stable -- I've not
had any crashes or weirdness since I finished debugging the problems
from the merge (none of which are problems with the the official unicode
branch) -- so it might even be better just to change the real default to
"on", on the assumpt that if someone uses "configure
--with-font-backend", they probably want to use it... :-]

-Miles
-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <buopsaylgu1.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > Isn't this good enough for the moment?
> >
> > % alias emacs-fb='emacs-unicode --enable-font-backend'

> It's just that I often start emacs via non-command-line methods (menus,
> via EDITOR, etc.; it's a pain to go though and change all those things).

> I guess for now I can just hack emacs.c to default the command-line
> option to "on".

> As far as I can tell though, the feature is pretty stable -- I've not
> had any crashes or weirdness since I finished debugging the problems
> from the merge (none of which are problems with the the official unicode
> branch) -- so it might even be better just to change the real default to
> "on", on the assumpt that if someone uses "configure
> --with-font-backend", they probably want to use it... :-]

On Windows and Mac, we can't make it on.  If someone would
like to work on changing the default only for Unix/GNU-Linux
and on providing a way to disable font-backend on such
systems, please go ahead.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Stefan Monnier]

> Couldn't Emacs, by default at least, just let
> xft/freetype/whatever decide?

Not it could, but it should.  Let's not reinvent this wheel, we have plenty
of other things to do.


        Stefan

Re: unicode font-backend + tiling

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> On Windows and Mac, we can't make it on.

Wouldn't one just not use "configure --enable-font-backend" on those systems?

> If someone would like to work on changing the default only for
> Unix/GNU-Linux and on providing a way to disable font-backend on such
> systems, please go ahead.

I was just thinking of something like this:


--- orig/src/emacs.c
+++ mod/src/emacs.c
@@ -1441,10 +1441,14 @@
     = argmatch (argv, argc, "-nl", "--no-loadup", 6, NULL, &skip_args);
 
 #ifdef USE_FONT_BACKEND
-  enable_font_backend = 0;
+  enable_font_backend = 1;
   if (argmatch (argv, argc, "-enable-font-backend", "--enable-font-backend",
 		4, NULL, &skip_args))
     enable_font_backend = 1;
+  else if (argmatch (argv, argc,
+		     "-disable-font-backend", "--disable-font-backend",
+		     4, NULL, &skip_args))
+    enable_font_backend = 0;
 #endif	/* USE_FONT_BACKEND */
 
 #ifdef HAVE_X_WINDOWS
@@ -1850,6 +1854,7 @@
   { "-no-multibyte", "--no-multibyte", 80, 0 },
   { "-nl", "--no-loadup", 70, 0 },
   { "-enable-font-backend", "--enable-font-backend", 65, 0 },
+  { "-disable-font-backend", "--disable-font-backend", 65, 0 },
   /* -d must come last before the options handled in startup.el.  */
   { "-d", "--display", 60, 1 },
   { "-display", 0, 60, 1 },


-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <87mz62uc96.fsf@frontier.dottedmag.net>, Mikhail Gusarov <dottedmag@dottedmag.net> writes:

> You (handa@m17n.org) wrote:

 KH> So, we must design a flexible interface that can be controlled by
 KH> users.

> The name of this interface is fontconfig.

But,

Miles Bader <miles.bader@necel.com> writes:

> However I've _also_ just tried my test in gnome-terminal and some other
> gnome apps, and they do the same thing (use AA always, even for CJK) in
> the "body" text.  However the same programs use non-AA CJK text in menus
> etc.!  So I don't know where that decision is getting made....

> Firefox on the other hand, even its "body" text, uses AA at small sizes,
> non-AA at normal sizes, and AA at big sizes, which I gather is the
> desired behavior.

Doesn't it mean that an application program anyway have to
do fine tuning over fontconfig?

By the way, I've just installed another fix for Xft
font-backend so that fontconfig's setting takes effect.

With the latest code,  when I have this in ~/.fonts.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <match target="pattern">
   <test name="family">
     <string>AR PL SungtiL GB</string>
   </test>
   <edit name="antialias" mode="assign">
     <bool>false</bool>
   </edit>
 </match>

and set han script code as this:

(set-fontset-font
 "fontset-default"
 'han
 '("AR PL SungtiL GB" . "iso10646-1"))

Chinese characters are dispalyed without antialias.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <buo8xhl8xdp.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > On Windows and Mac, we can't make it on.

> Wouldn't one just not use "configure --enable-font-backend" on those systems?

The font-backend for Mac is now under development.  I hope
it's committed soon.  But, when' it's committed, I don't
know it's stable enough for enabling font-backend by
default.

> > If someone would like to work on changing the default only for
> > Unix/GNU-Linux and on providing a way to disable font-backend on such
> > systems, please go ahead.

> I was just thinking of something like this:

I don't have a time to test it.  If you want to install it,
please go ahead.  But, please write something in
README.unicode about that change in addition to
ChangeLog.unicode.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Mikhail Gusarov]

You (miles.bader@necel.com) wrote:

 MB> However I've _also_ just tried my test in gnome-terminal and some
 MB> other gnome apps, and they do the same thing (use AA always, even
 MB> for CJK) in the "body" text.  However the same programs use
 MB> non-AA CJK text in menus etc.!  So I don't know where that
 MB> decision is getting made....

 MB> Firefox on the other hand, even its "body" text, uses AA at small
 MB> sizes, non-AA at normal sizes, and AA at big sizes, which I
 MB> gather is the desired behavior.

Apps have the power to override the decision made in fontconfig. I
suppose both gnome-terminal and Firefox do use it. Not sure such
override is a good thing.

-- 

Re: unicode font-backend + tiling

[Leo]

On WED, 6 DEC 2006, Kenichi Handa wrote:

> By the way, I've just installed another fix for Xft
> font-backend so that fontconfig's setting takes effect.
>
> With the latest code,  when I have this in ~/.fonts.conf:
>
> <?xml version="1.0"?>
> <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> <fontconfig>
>  <match target="pattern">
>    <test name="family">
>      <string>AR PL SungtiL GB</string>
>    </test>
>    <edit name="antialias" mode="assign">
>      <bool>false</bool>
>    </edit>
>  </match>
>
> and set han script code as this:
>
> (set-fontset-font
>  "fontset-default"
>  'han
>  '("AR PL SungtiL GB" . "iso10646-1"))
>
> Chinese characters are dispalyed without antialias.
>

This is awesome.

-- 
Leo

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <m2lkll19dz.fsf@sl392.st-edmunds.cam.ac.uk>, Leo <sdl.web@gmail.com> writes:

> On WED, 6 DEC 2006, Kenichi Handa wrote:
> > By the way, I've just installed another fix for Xft
> > font-backend so that fontconfig's setting takes effect.
> >
> > With the latest code,  when I have this in ~/.fonts.conf:
> >
> > <?xml version="1.0"?>
> > <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> > <fontconfig>
> >  <match target="pattern">
> >    <test name="family">
> >      <string>AR PL SungtiL GB</string>
> >    </test>
> >    <edit name="antialias" mode="assign">
> >      <bool>false</bool>
> >    </edit>
> >  </match>
> >
> > and set han script code as this:
> >
> > (set-fontset-font
> >  "fontset-default"
> >  'han
> >  '("AR PL SungtiL GB" . "iso10646-1"))
> >
> > Chinese characters are dispalyed without antialias.
> >

> This is awesome.

What is awesome?  The procedure to make Chinese character
displayed without antialias?  Or, the looking of Chinese
character displayed withtout antialias by the above font?
If it's the latter, I agree.  At least that font is better
with antialias.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Leo]

On WED, 6 DEC 2006, Kenichi Handa wrote:

[...]

>> >
>> > Chinese characters are dispalyed without antialias.
>> >
>
>> This is awesome.
>
> What is awesome?  The procedure to make Chinese character
> displayed without antialias?  Or, the looking of Chinese
> character displayed withtout antialias by the above font?
> If it's the latter, I agree.  At least that font is better
> with antialias.

I use NSimSun and with your change, it is much readable without AA.

>
> ---
> Kenichi Handa
> handa@m17n.org

-- 
Leo

Re: unicode font-backend + tiling

[Romain Francoise]

While on the topic of fonts in emacs-unicode-2, do you know why the
following happens?

ELISP> (char-displayable-p ?\U00002014)
*** Eval error ***  Wrong type argument: integer-or-marker-p, nil
ELISP>

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

bug of char-displayable-p [Re: unicode font-backend + tiling]

[Kenichi Handa]

In article <87k614g5ll.fsf@pacem.orebokech.com>, Romain Francoise <romain@orebokech.com> writes:

> While on the topic of fonts in emacs-unicode-2, do you know why the
> following happens?

ELISP> (char-displayable-p ?\U00002014)
> *** Eval error ***  Wrong type argument: integer-or-marker-p, nil
ELISP>

It's a bug.  I've just installed a fix.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[Zhang Wei]

Kenichi Handa <handa@m17n.org> writes:

[...]

> By the way, I've just installed another fix for Xft
> font-backend so that fontconfig's setting takes effect.
>
> With the latest code,  when I have this in ~/.fonts.conf:
>
> <?xml version="1.0"?>
> <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
> <fontconfig>
>  <match target="pattern">
>    <test name="family">
>      <string>AR PL SungtiL GB</string>
>    </test>
>    <edit name="antialias" mode="assign">
>      <bool>false</bool>
>    </edit>
>  </match>
>
> and set han script code as this:
>
> (set-fontset-font
>  "fontset-default"
>  'han
>  '("AR PL SungtiL GB" . "iso10646-1"))
>
> Chinese characters are dispalyed without antialias.

But the following fontconfig setting still takes no effect:

--8<---------------cut here---------------start------------->8---
  <match target="font" >
    <test qual="any" name="family" compare="eq" >
      <string>SimSun</string>
    </test>
    <test name="pixelsize" compare="more_eq" >
      <double>12</double>
    </test>
    <test name="pixelsize" compare="less_eq" >
      <double>18</double>
    </test>
    <edit name="antialias" mode="assign" >
      <bool>false</bool>
    </edit>
  </match>
--8<---------------cut here---------------end--------------->8---

Re: unicode font-backend + tiling

[Miles Bader]

Zhang Wei <id.brep@gmail.com> writes:
> But the following fontconfig setting still takes no effect:

I dunno, but maybe it's because you're using <double>?  I had success
using <int> to match against pixelsize.

The following .fonts.conf file works for me; it:
(1) turns on the autohinter, which seems to improve these fonts,
and (2) turns off anti-aliasing for a pixelsize between 13 and 17
(for fonts smaller than 13 pixels, the curved lines in these fonts start
to get weird ugly artifacts).

BTW the fonts below are actually "kochi gothic" and "kochi mincho", but
for whatever reason the roman names don't match...  I don't really
understand f.c.'s matcher too well !


<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">

<fontconfig>

 <match target="pattern">
   <test name="family">
     <string>東風ゴシック</string>
     <string>さざなみ明朝</string>
   </test>

   <edit name="autohint" mode="assign">
     <bool>true</bool>
   </edit>
 </match>

 <match target="pattern">
   <test name="family">
     <string>東風ゴシック</string>
     <string>さざなみ明朝</string>
   </test>
   <test name="pixelsize" compare="more">
     <int>12</int>
   </test>
   <test name="pixelsize" compare="less">
     <int>18</int>
   </test>

   <edit name="antialias" mode="assign">
     <bool>false</bool>
   </edit>
 </match>

</fontconfig>


-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: unicode font-backend + tiling

[Kenichi Handa]

In article <ulklkxr9k.fsf@gmail.com>, Zhang Wei <id.brep@gmail.com> writes:

> But the following fontconfig setting still takes no effect:

> --8<---------------cut here---------------start------------->8---
>   <match target="font" >

How about changing that line to this as my example.

>   <match target="pattern">

I must confess I don't know what the difference between
them, but FYI, xftfont.c now contains this line:

  FcConfigSubstitute (NULL, pat, FcMatchPattern);

I read the manual of fontconfig but couldn't understand the
difference between FcMatchPattern and FcMatchFont as the
third arg of FcConfigSubstitute.  Could someone please
explain it?

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[James Cloos]

>>>>> "Kenichi" == Kenichi Handa <handa@m17n.org> writes:

Kenichi> I read the manual of fontconfig but couldn't understand the
Kenichi> difference between FcMatchPattern and FcMatchFont as the
Kenichi> third arg of FcConfigSubstitute.  Could someone please
Kenichi> explain it?

What it is trying to say is that, if FcMatchPattern is specified, then
sections of the fonts.conf that are in:

,----
| <match target="pattern">
|
| </match>
`----

sections are used, but if FcMatchFont is specified, then sections in:

,----
| <match target="font">
|
| </match>
`----

get used.

In the former case, and if FcConfigSubstituteWithPat is called,
the p_pat arg gets matched against the <test> chunks in the
<match target="pattern"> chunks.  Otherwise that arg is not used.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: unicode font-backend + tiling

[Zhang Wei]

Kenichi Handa <handa@m17n.org> writes:

> In article <ulklkxr9k.fsf@gmail.com>, Zhang Wei <id.brep@gmail.com> writes:
>> But the following fontconfig setting still takes no effect:
>>   <match target="font" >
>
> How about changing that line to this as my example.
>
>>   <match target="pattern">

Yes, that takes effect, but another problem arises, my setting is like this:

--8<---------------cut here---------------start------------->8---
  <alias>
    <family>Bitstream Vera Sans Mono</family>
    <family>SimSun</family>
    <default><family>monospace</family></default>
  </alias>

  <alias>
    <family>monospace</family>
    <prefer>
      <family>Bitstream Vera Sans Mono</family>
      <family>SimSun</family>
    </prefer>
  </alias>

  <match target="font" >
    <test qual="any" name="family" compare="eq" >
      <string>SimSun</string>
    </test>
    <test name="pixelsize" compare="more_eq" >
      <double>12</double>
    </test>
    <test name="pixelsize" compare="less_eq" >
      <double>18</double>
    </test>
    <edit name="antialias" mode="assign" >
      <bool>false</bool>
    </edit>
  </match>
--8<---------------cut here---------------end--------------->8---

When I say

emacs --enable-font-backend -fn "Bitstream Vera Sans Mono:pixelsize=14" -Q

the ascii portion will use "Bitstream Vera Sans Mono", and chinese
characters will use "SimSun".

but if I use

<match target="pattern" >

to close the antialias of "SimSun", the ascii portion's antialias is
_also_ closed.

BTW, the following setting seems takes no effect:

--8<---------------cut here---------------start------------->8---
  <match target="pattern" >
    <test name="family" >
      <string>SimSun</string>
    </test>
    <edit name="family" mode="prepend" binding="strong" >
      <string>Bitstream Vera Sans Mono</string>
    </edit>
  </match>
--8<---------------cut here---------------end--------------->8---

this setting substitude ascii portion of "SimSun" with "Bitstream Vera
Sans Mono", it works well in Firefox, but start emacs with:

emacs --enable-font-backend -fn "SimSun:pixelsize=14" -Q

the ascii portion is still "SimSun", not "Bitstream Vera Sans Mono".

Re: unicode font-backend + tiling

[Kenichi Handa]

Sorry for the late response on this matter.

In article <m3psavamle.fsf@lugabout.jhcloos.org>, James Cloos <cloos@jhcloos.com> writes:

> What it is trying to say is that, if FcMatchPattern is specified, then
> sections of the fonts.conf that are in:

> ,----
> | <match target="pattern">
> |
> | </match>
> `----

> sections are used, but if FcMatchFont is specified, then sections in:

> ,----
> | <match target="font">
> |
> | </match>
> `----

> get used.

> In the former case, and if FcConfigSubstituteWithPat is called,
> the p_pat arg gets matched against the <test> chunks in the
> <match target="pattern"> chunks.  Otherwise that arg is not used.

Thank you for the explanation.  But, I still don't
understand when to use FcMatchPattern and when to use
FcMatchFont in a program.

---
Kenichi Handa
handa@m17n.org

Re: unicode font-backend + tiling

[James Cloos]

>>>>> "Kenichi" == Kenichi Handa <handa@m17n.org> writes:

Kenichi> Thank you for the explanation.  But, I still don't
Kenichi> understand when to use FcMatchPattern and when to use
Kenichi> FcMatchFont in a program.

Good point.  I did fail to address that.

FcMatchPattern should be used first to determine exactly which font
should be used, given the user's requested font pattern.

Then, FcMatchFont should be used to determine the details on how to
render that font.

Eg, substitutions like Arial or NimbusSanL for Helvetica, some font or
other for Serif, Sans or Mono, etc are all done during the Pattern step.

Things like controling hinting, rgba, aa, embedded bitmaps, etc are
then done during the FcMatchFont step.

So you need to call the function twice.  First with FcMatchPattern to
get the font, and then with FcMatchFont to get the rendering details
to pass on to FreeType and Xft.

There is some discussion at:

http://fontconfig.org/fontconfig-user.html#AEN25

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6