GNU bug report logs - #70989
29.3; Calling isearch-forward when using Unifont throws error "Invalid font name"

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Rodrigo Morales <me <at> rodrigomorales.site>
Cc: 70989 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#70989: 29.3; Calling isearch-forward when using Unifont throws error "Invalid font name"
Date: Sat, 18 May 2024 20:25:06 +0800

Rodrigo Morales <me <at> rodrigomorales.site> writes:

> #+BEGIN_SRC text
>              position: 1 of 145 (0%), column: 0
>             character: ; (displayed as ;) (codepoint 59, #o73, #x3b)
>               charset: ascii (ASCII (ISO646 IRV))
> code point in charset: 0x3B
>                script: latin
>                syntax: < 	which means: comment
>              category: .:Base, a:ASCII, l:Latin, r:Roman
>              to input: type "C-x 8 RET 3b" or "C-x 8 RET SEMICOLON"
>           buffer code: #x3B
>             file code: #x3B (encoded by coding system utf-8-unix)
>               display: by this font (glyph code):
>     ftcrhb:-GNU-Unifont-medium-normal-normal-Sans-Serif-16-*-*-*-c-80-iso10646-1 (#x3C)

Thanks.  The field in question is the adstyle produced from an
FcPattern's FC_STYLE attribute by get_adstyle_property in the ftfont
driver.  What are the chances that a font will define two adstyles that
collide when dashes (and other characters not representable in an XLFD)
in one are replaced with a substitute?  I expect that they are
negligible, and as such it should suffice to substitute some fixed
alternative for such characters where they appear in adstyles and
perhaps other fields also, if it should ever come to that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.