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

[Po Lu]

Rodrigo Morales <me@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.