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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  <70989@debbugs.gnu.org>
> Date: Sat, 18 May 2024 20:25:06 +0800
> 
> 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.

Sorry, can you elaborate a bit, please?  Specifically:

  . which code in get_adstyle_property does this, and how?
  . what is your idea for a fix, which led you to ask about "the
    chances that a font will define two adstyles that collide"?