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

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

bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT


From: Sean Whitton
Subject: bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX
Date: Tue, 04 Jan 2022 19:10:46 -0700

Hello,

On Sat 01 Jan 2022 at 09:15AM +02, Eli Zaretskii wrote:

> However, the question that I think we should ask ourselves at this
> point is whether there's a reasonable way to process these fonts into
> a font spec that Emacs expects.  So if FcPatternGetInteger and
> FcPatternGetDouble don't do the job, perhaps there's another
> fontconfig function that does, or maybe these fonts need to be
> processed in some slightly different ways (like in a loop, for
> example) to produce the weight matches from them?

I received a helpful reply from Akira TAGOH on the fontconfig list.  The
problematic entries are not in fact additional font weights available to
Emacs, but meta or virtual entries from which applications can extract
information about the range of weights provided by the variable weight
.ttf file.

As we do not need to know the range of weights explicitly, the virtual
entries are no use to us.  We can just skip over them and process the
non-virtual FcPattern entries we get for each weight.  I'm attaching a
patch which detects these virtual entries and skips over them.  Maybe we
could revert and replace the temporary fix with my patch?

As a test, I tried calling FcPatternGetRange on the virtual entry for
Inconsolata-VariableFont_wdth,wght.ttf and I got a range of 40 to 210.
I confirmed that the weights of all the non-virtual entries fall within
this range, inclusive.

-- 
Sean Whitton

Attachment: 0001-Skip-virtual-FcPattern-entries-for-variable-weight-f.patch
Description: Text Data


reply via email to

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