From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 70989@debbugs.gnu.org, me@rodrigomorales.site
Subject: bug#70989: 29.3; Calling isearch-forward when using Unifont throws error "Invalid font name"
Date: Sun, 19 May 2024 15:37:09 +0800 [thread overview]
Message-ID: <87jzjq6ymy.fsf@yahoo.com> (raw)
In-Reply-To: <86wmnqbala.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 19 May 2024 09:05:21 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
> Sorry, I still don't understand what you are saying. Could you please
> talk me through the code in that function, and tell where does
> "Sans-Serif" come from and how is it "injected" into the font's
> attributes?
>
> What I see there is the call to fond_intern_prop, and if the result is
> accepted by font_style_to_value as a valid value of FONT_WIDTH_INDEX,
> it is returned. But "Sans-Serif" is not supposed to be a valid width
> of a font, so I'm confused.
Where does FONT_WIDTH_INDEX come into play? The attribute responsible
is FONT_ADSTYLE_INDEX, which is set to "Sans-Serif" by:
font. */
FT_Face ft_face;
ASET (entity, FONT_ADSTYLE_INDEX, get_adstyle_property (p));
if ((ft_library || FT_Init_FreeType (&ft_library) == 0)
in ftfont_pattern_entity. The XLFD generated from a font with such an
adstyle is not parsable, the character `-' being the field separator in
XLFDs, and gives rise to parser errors such as Rodrigo encountered when
I-search, by proxy, attempted to deconstruct the XLFD back into a font
spec.
> In what string or symbol name that is being processed in
> get_adstyle_property?
Its return value.
next prev parent reply other threads:[~2024-05-19 7:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 18:39 bug#70989: 29.3; Calling isearch-forward when using Unifont throws error "Invalid font name" Rodrigo Morales
2024-05-16 19:31 ` Eli Zaretskii
2024-05-16 20:09 ` Rodrigo Morales
2024-05-17 6:13 ` Eli Zaretskii
2024-05-17 11:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-17 15:14 ` Rodrigo Morales
2024-05-18 12:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-18 15:34 ` Eli Zaretskii
2024-05-19 0:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-19 6:05 ` Eli Zaretskii
2024-05-19 7:37 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-05-19 7:49 ` Eli Zaretskii
2024-05-19 11:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-19 11:42 ` Eli Zaretskii
2024-05-19 13:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-19 13:19 ` Eli Zaretskii
2024-05-20 13:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jzjq6ymy.fsf@yahoo.com \
--to=bug-gnu-emacs@gnu.org \
--cc=70989@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
--cc=me@rodrigomorales.site \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.