bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12693: [cygwin] Setting fonts with non-ascii names throws error quit


From: Kazuhiro Ito
Subject: bug#12693: [cygwin] Setting fonts with non-ascii names throws error quit
Date: Mon, 14 Sep 2020 20:38:31 +0900
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 Emacs/28.0.50 (x86_64-w64-mingw32) MULE/6.0 (HANACHIRUSATO)

> > (set-frame-font "MS ゴシック-14") raises an error on Cygw32 build
> > but not on MinGW64 build.  x-select-font function returns encoded
> > string on Cygw32 build.  Let-binding locale-coding-system to the
> > correct codepage can avoid the problem.
> >
> > ;; Chose "MS ゴシック-14"
> > (x-select-font)
> >
> > -> "\202l\202r \203S\203V\203b\203N-14"
> 
> Hm...  I don't use Windows, so I can't test this, but perhaps the result
> from `x-select-font' should use `detect-coding-string' or something on
> the result (and then decode it) so that we get a correct string in Emacs?

As discussed in the original thread, Emacs uses ANSI version of
Windows API to handle fonts.  Strings passed to or received from APIs
should be encoded in or decoded from ANSI codepage.  To do that,
ENCODE_SYSTEM and DECODE_SYSTEM macros are used (See src/w32font.c).
It means that locale-coding-system is used around Windows font API.
That works well on MinGW64, because locale-coding-system is the same
with ANSI codepage.  But on Cygw32, locale-coding-system is normally
utf-8 and it is not ANSI codepage.  This is the cause of the problem.

My original post makes Emacs use ANSI codepage for Windows font API.
Further discussion indicates to make Emacs on Windows use unicode API
if available.  But no progresss after that.

-- 
Kazuhiro Ito





reply via email to

[Prev in Thread] Current Thread [Next in Thread]