Where is a character presence tested in a font?

Where is a character presence tested in a font?

[Óscar Fuentes]

About two years ago I reported some problems with not displaying some
characters with certain font and Jason Rumney hinted that it could be a
problem with how the test for existence of those characters is done.

I know nothing about font handling but I'll like to try to improve the
current status anyway. Could someone point me to the source code (or API
name) where Emacs on MS Windows tests for the presence of a given
character on a font?

This is an excerpt of the discussion, with Jason's response below:

> Some characters display fine on GNU/Linux but not on Windows. An example 
> is FISHEYE (?\u25c9) with the Consolas font. Apparently, that font does 
> not include that character. In GNU/Linux Emacs simply uses DejaVu for 
> displaying the character, but not on Windows, where a white space is 
> displayed (the Windows machine also has DejaVu installed.) 
> 
> Is this a known limitation or a bug? 
> 
>      uniscribe:-outline-Consolas-normal-normal-normal-mono-20-*-*-*-c-*-iso10646-1 (#x03) 
>     

The font is claiming to have that character in position 3 in the glyph 
table. I've also seen the same thing with fonts claiming position 1.   
There is nothing in the documentation for opentype or the font related 
Windows API functions that suggests that there is anything special about 
those glyph indexes, or that it is safe to assume that they mean a 
character is missing from the font.  Currently I think we only treat a 
return of 0 as indicating that the character is missing, as that is 
reserved by the truetype and opentype specs for the character ".notdef".

Re: Where is a character presence tested in a font?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 15 Jul 2012 17:44:36 +0200
> 
> Could someone point me to the source code (or API name) where Emacs
> on MS Windows tests for the presence of a given character on a font?

Search for uses of font_has_char.  The Windows implementation of this
just returns -1, but the code that calls it should then use some
alternative strategy (which includes opening the font, AFAIU) to
arrive at the conclusion.

Sorry, I don't know more than this.

Re: Where is a character presence tested in a font?

[Štěpán Němec]

On Sun, 15 Jul 2012 17:44:36 +0200
Óscar Fuentes wrote:

> About two years ago I reported some problems with not displaying some
> characters with certain font and Jason Rumney hinted that it could be a
> problem with how the test for existence of those characters is done.
>
> I know nothing about font handling but I'll like to try to improve the
> current status anyway. Could someone point me to the source code (or API
> name) where Emacs on MS Windows tests for the presence of a given
> character on a font?

Note that the deficient font auto-selection problem is actually not
limited to Windows, as I've written elsewere in the past:

<http://permalink.gmane.org/gmane.emacs.devel/142261>

-- 
Štěpán

Re: Where is a character presence tested in a font?

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Sun, 15 Jul 2012 17:44:36 +0200
>> 
>> Could someone point me to the source code (or API name) where Emacs
>> on MS Windows tests for the presence of a given character on a font?
>
> Search for uses of font_has_char.  The Windows implementation of this
> just returns -1, but the code that calls it should then use some
> alternative strategy (which includes opening the font, AFAIU) to
> arrive at the conclusion.

The alternative strategy is to call encode_char. I notice that while the
uniscribe backend's implementation of encode_char does lookup the code
point for the font, the w32 backend just returns the unicode code point
as long as it is not completely outside the range covered by the font.

As Emacs has since been modified to report the backend and codepoint,
perhaps C-u C-x = now will tell whether the original diagnosis was
correct, or for that character we are falling back on the w32 font
backend.

Re: Where is a character presence tested in a font?

[Jason Rumney]

Štěpán Němec <stepnem@gmail.com> writes:

> Note that the deficient font auto-selection problem is actually not
> limited to Windows, as I've written elsewere in the past:
>
> <http://permalink.gmane.org/gmane.emacs.devel/142261>

That is a different problem - in some cases Emacs can decide that a font
does not support a script, so does not bother checking it for certain
characters which may be present.

In this case, Emacs on Windows is deciding that a font DOES support a
character that is not present in that font.