GNU bug report logs -
#19993
25.0.50; Unicode fonts defective on Windows
Previous Next
Full log
Message #98 received at 19993 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 12, 2015 at 08:16:39PM +0200, Eli Zaretskii wrote:
> support these characters. This is now fixed in commit fc10058 on
> master. You should now be able to type "C-x 8 RET 1d400 RET" and see
> the character displayed.
>
> While at that, I also added the missing subranges that for some reason
> unknown to me were commented out; for many of them, I could verify
> that adding them makes the corresponding characters displayable by
> default, where they previously weren't. (I couldn't verify that for
> some of the scripts for which I have no fonts.) A few subranges were
> left out, and I added comments explaining why.
A lot of thanks!
> With that out of our way, part of the problem is solved. Part, but
> not all of it. Because it is true: Emacs searches the fonts installed
> on the system mostly by requiring only that the font supports the
> script to which the character belongs, but without opening the font
> and checking whether the specific character we are about to display
> has a glyph in the font. Here's the crucial piece of code (from
> fontset.c):
>
> /* Find a font best-matching with the spec without checking
> the support of the character C. That checking is costly,
> and even without the checking, the found font supports C
> in high possibility. */
So, this explains why U+2099, U+27e8, U+27e9 are not shown here (while
supported by a lot of fonts). Thanks for investigating this!
> Assuming that we want to become smarter about this, we could do one or
> both of the following:
>
> . have a database of fonts which are _not_ to be used for certain
> scripts, because it is known that their coverage is poor
>
> . have a more elaborate default fontset that favors specific fonts
> for scripts which these fonts are known to support well
>
Did you look into the link I provided (about how Firefox does it)?
http://search.cpan.org/~ilyaz/UI-KeyboardLayout/lib/UI/KeyboardLayout.pm#There_is_no_way_to_show_Unicode_contents_on_Windows
As my experiments show (I did not try to read the source code) the
logic of falling back goes this way:
• If document’s fonts can show a char, stop;
• If (user-configurable) fallback fonts for a Subset can show a
char, stop;
• If (user-configurable) universal fallback fonts can show a
char, stop;
• Otherwise, scan all fonts to find one supporting a char.
(The third case is the “x-unicode” pseudo-subset mentioned in the link
above.)
Emacs:
• Supports different fallbacks for different subsets;
• But it supports only one fallback font per character.
(Well, it allows specifying more than one font, but as you saw,
only one of them will be actually used — at least in the case
when the fonts would claim having chars in all the ranges — as
most of “good universal fonts” would do.)
The second one is a significant show-stopper, since it is very hard to
boil down things to one font.
Myself, I only use scripts with “simple shaping”, so all of my needs
are covered by 4 fonts:
DejaVu *
Symbola
Junicode
Unifont Smooth
(with Unifont Smooth last, since though I’m still working on
un-uglifying Unifont, there is a limit to algorithmic beautification,
and it is always going to be MUCH worse than all the
alternatives — when alternatives exist).
BTW, is font-family search caseless? Since last year, the family was
changed from
unifont
to
Unifont
(in the unifondry’s TTF distribution).
> One problem with both of these is that it's hard to recommend fonts
> because many good fonts are non-free.
For simple rendering (no shaping), there is a lot of possibilities.
Ilya
This bug report was last modified 10 years and 154 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.