* Where is a character presence tested in a font?
@ 2012-07-15 15:44 Óscar Fuentes
2012-07-15 16:22 ` Eli Zaretskii
2012-07-15 18:36 ` Štěpán Němec
0 siblings, 2 replies; 5+ messages in thread
From: Óscar Fuentes @ 2012-07-15 15:44 UTC (permalink / raw)
To: emacs-devel
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".
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Where is a character presence tested in a font?
2012-07-15 15:44 Where is a character presence tested in a font? Óscar Fuentes
@ 2012-07-15 16:22 ` Eli Zaretskii
2012-07-16 2:46 ` Jason Rumney
2012-07-15 18:36 ` Štěpán Němec
1 sibling, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2012-07-15 16:22 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Where is a character presence tested in a font?
2012-07-15 16:22 ` Eli Zaretskii
@ 2012-07-16 2:46 ` Jason Rumney
0 siblings, 0 replies; 5+ messages in thread
From: Jason Rumney @ 2012-07-16 2:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Where is a character presence tested in a font?
2012-07-15 15:44 Where is a character presence tested in a font? Óscar Fuentes
2012-07-15 16:22 ` Eli Zaretskii
@ 2012-07-15 18:36 ` Štěpán Němec
2012-07-16 2:49 ` Jason Rumney
1 sibling, 1 reply; 5+ messages in thread
From: Štěpán Němec @ 2012-07-15 18:36 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-07-16 2:49 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-15 15:44 Where is a character presence tested in a font? Óscar Fuentes
2012-07-15 16:22 ` Eli Zaretskii
2012-07-16 2:46 ` Jason Rumney
2012-07-15 18:36 ` Štěpán Němec
2012-07-16 2:49 ` Jason Rumney
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).