another font-selection inconsistency

another font-selection inconsistency

[Miles Bader]

(1) If I start a new emacs, and evaluate the following in *scratch*:

       (set-face-attribute 'default nil :family "Dejavu Sans Mono" :height 100)

    Then the resulting font _is_ dejavu sans mono, but is not
    anti-aliased.  C-u C-x = says:

       -dejavu-dejavu sans mono-medium-r-normal--13-94-100-100-m-80-iso8859-1

(2) If I then, in the same emacs, do:

       (set-frame-font  "Dejavu Sans Mono-10")

    Then the resulting font is _still_ dejavu sans mono, but _is_
    anti-aliased (it's fairly clear it's the same font, just with
    anti-aliasing turned on).  C-u C-x = says:

       -unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso8859-1

(3) If I then turn around, and do step (1) again, the font "stays"
    anti-aliased, so clearly some state that set-frame-font changes, but
    set-face-attribute:family:size does not, made a difference...]

This is particular annoying because `set-frame-font' only works with the
default face... for other faces, one must use set-face-attribute.

-Miles

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.

Re: another font-selection inconsistency

[Jason Rumney]

Miles Bader wrote:
>     Then the resulting font _is_ dejavu sans mono, but is not
>     anti-aliased.  C-u C-x = says:
> ...
>     Then the resulting font is _still_ dejavu sans mono, but _is_
>     anti-aliased (it's fairly clear it's the same font, just with
>     anti-aliasing turned on).  C-u C-x = says:
> ...
> (3) If I then turn around, and do step (1) again, the font "stays"
>     anti-aliased, so clearly some state that set-frame-font changes, but
>     set-face-attribute:family:size does not, made a difference...]
>   

A couple of days ago, Kenichi Handa stated that there is currently no 
priority given to backends. I think fixing this would clear this up. 
Another thing that might help is making sure that Truetype fonts are not 
being provided to the xfont backend through your X configuration, but 
that's a workaround not a solution. Having a consistent priority for 
backends is also important on Windows, where opentype fonts are provided 
by both the uniscribe backend (with complex script support and other 
features) and the gdi backend (with some minor differences in processing 
for Windows 9x compatibility). My impression before the font-backend 
branch merge was that there was a consistent priority, even if it was 
undocumented, but recently there is definitely not.

Re: another font-selection inconsistency

[Miles Bader]

It seems to be the "foundry" info that makes the difference -- using
(set-face-attribute 'default nil :family "unknown-Dejavu Sans Mono"
:height 100) works "properly" even the first time.

A bit confusing, as I don't think most users think about the foundry much,
especially when there's only one font by that family name.

Here's what fc-list says btw:

   $ env - HOME=/tmp fc-list 'Dejavu Sans Mono' file family foundry
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:foundry=unknown
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:foundry=unknown
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:foundry=unknown
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:foundry=unknown

   $ env - HOME=/tmp fc-list 'Dejavu Sans Mono:foundry=unknown' file family foundry
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:foundry=unknown
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:foundry=unknown
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:foundry=unknown
   /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:foundry=unknown

   $ env - HOME=/tmp fc-list 'Dejavu Sans Mono:foundry=dejavu' file family foundry

-Miles


-- 
Philosophy, n. A route of many roads leading from nowhere to nothing.

Re: another font-selection inconsistency

[Kenichi Handa]

In article <484E682B.2080404@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> A couple of days ago, Kenichi Handa stated that there is currently no 
> priority given to backends. I think fixing this would clear this up. 

Ok, I'll modify the font selector to pay attention to the
order of backends.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: another font-selection inconsistency

[Kenichi Handa]

In article <E1K6PiJ-0005v9-Sj@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:

> In article <484E682B.2080404@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:
> > A couple of days ago, Kenichi Handa stated that there is currently no 
> > priority given to backends. I think fixing this would clear this up. 

> Ok, I'll modify the font selector to pay attention to the
> order of backends.

I've just installed it.  But, the change is bigger than what
I expected at first.  I hope it doesn't introduce a new bug,
but please keep close watch on font selection.

By the way, by the side effect, I think the following
problem is fixed too.

> > > Hmmm, strange.  In my environment,
> > >   ESC : (set-frame-font "Aurulent Sans Mono")
> > > surely works.

> > Oddly _that_ works for me too, as does the "-fn" option.  It's
> > `customize-face' and `set-face-attribute' that don't seem to work.

> > The set-face-attribute form I tried to use was:

> >    (set-face-attribute 'default nil :family "Aurulent Sans Mono")

---
Kenichi Handa
handa@ni.aist.go.jp

Re: another font-selection inconsistency

[Stefan Monnier]

>> In article <484E682B.2080404@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:
>> > A couple of days ago, Kenichi Handa stated that there is currently no 
>> > priority given to backends. I think fixing this would clear this up. 

>> Ok, I'll modify the font selector to pay attention to the
>> order of backends.

> I've just installed it.  But, the change is bigger than what
> I expected at first.  I hope it doesn't introduce a new bug,
> but please keep close watch on font selection.

> By the way, by the side effect, I think the following
> problem is fixed too.

I think the default order should be (xft x) rather than (x xft).


        Stefan