New subject: [Bug 1813230] [RFE] ghostscript add support for variable fonts from fontconfig

13 Mar 2020


      https://bugzilla.redhat.com/show_bug.cgi?id=1813230
Bug ID: 1813230
           Summary: [RFE] ghostscript add support for variable fonts from
                    fontconfig
           Product: Red Hat Enterprise Linux 8
           Version: 8.4
            Status: NEW
         Component: ghostscript
          Assignee: zdohnal@redhat.com
          Reporter: zdohnal@redhat.com
        QA Contact: qe-baseos-daemons@redhat.com
                CC: cosimo.cecchi@gmail.com, dkaspar@redhat.com,
                    extras-qa@fedoraproject.org,
                    fonts-bugs@lists.fedoraproject.org, ian@ianweller.org,
                    jsteiner@redhat.com, klember@redhat.com, me@fale.io,
                    mosvald@redhat.com, tagoh@redhat.com,
                    twaugh@redhat.com, zdohnal@redhat.com
        Depends On: 1813187
  Target Milestone: rc
    Classification: Red Hat
           Pool ID: sst_cs_infra_services_rhel_8
+++ This bug was initially created as a clone of Bug #1813187 +++
Description of problem:
During investigating https://bugzilla.redhat.com/show_bug.cgi?id=1722900 was
found the font mentioned in summary fails with mismatch on
FcPatternGetInteger() from fontconfig when gs asks for FC_WEIGHT value.
I'm not sure whether the font or fontconfig is at fault, so I'm filing the
issue on font package.
I'm willing to help with debug, if needed.
Version-Release number of selected component (if applicable):
abattis-cantarell-fonts-0:0.201-2.fc32.noarch
fontconfig-2.13.92-6.fc32.x86_64
ghostscript-9.50-1.fc32
Steps to Reproduce:
1. gs -dNODISPLAY -dBATCH nasmdoc.ps
Actual results:
You can see in logs a message:
DEBUG: FC_WEIGHT didn't match in /usr/share/fonts/cantarell/Cantarell-VF.otf
Expected results:
No such message
Additional info:
--- Additional comment from Kalev Lember on 2020-03-13 08:32:41 UTC ---
Sorry, I don't know much about fonts and don't think I can be of much help
debugging this. Can you ask Jakub and/or Tagoh if they know what's going on
(CCd)?
--- Additional comment from Nicolas Mailhot on 2020-03-13 08:42:52 UTC ---
On the fontconfig side, that’s basically bug
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/222
No idea if gs also contains problematic weight assumptions, invalidated by the
introduction of variable fonts.
On the packaging side cantarell has probably not been converted to new font
packaging guidelines yet. It needs some name fixing (use of a space-free
ExtraBold qualifier, removal of Regular in Name ID 4 for the Regular face,
making NameID 4 consistent with Name ID 17 for other faces). Though except for
the ExtraBold part, everything else will going to be workarounded in future
fontconfig versions.
--- Additional comment from Nicolas Mailhot on 2020-03-13 08:52:38 UTC ---
(Also fontconfig exposes a generic meta face for variable fonts, this face does
not have any specific weight, it gives the weight scale for the whole family)
--- Additional comment from Akira TAGOH on 2020-03-13 08:58:05 UTC ---
That isn't related to this.
I don't know how ghostscript collects fonts from fontconfig though (probably
using FcFontList()?), the problem here would be that they have dealt with a
meta face as a normal face which has true in FC_VARIABLE and contains a weight
in range but not integer.
That's not a bug in font nor fontconfig.
--- Additional comment from Zdenek Dohnal on 2020-03-13 09:25:03 UTC ---
Hi Akira,
yes, you're right, gs uses FcFontlist() - does the following to get font list:
-----------------------------------------------------
    /* load the font set that we'll iterate over */
    pat = FcPatternBuild(NULL,
            FC_OUTLINE, FcTypeBool, 1,
            FC_SCALABLE, FcTypeBool, 1,
            NULL);
    os = FcObjectSetBuild(FC_FILE, FC_OUTLINE,
            FC_FAMILY, FC_WEIGHT, FC_SLANT,
            NULL);
    state->font_list = FcFontList(0, pat, os);
-----------------------------------------------------
then when it enumerates the fonts it calls (f.e. for FC_WEIGHT):
result = FcPatternGetInteger (font, FC_WEIGHT, 0, &weight_fc);
(similar thing for FC_FILE, FC_FAMILY, FC_SLANT, FC_OUTLINE).
Would you mind telling me/pointing me to a manual how to deal with it
correctly, if it is not a problem of font/fontconfig?
--- Additional comment from Akira TAGOH on 2020-03-13 10:07:42 UTC ---
If ghostscript has no plans to support variable fonts or a plan to support only
named-instances, you can set false to FC_VARIABLE 
 as a query pattern; that should be more simple and easier than your patch
applied in ghostscript; you can take care of the named-instances in VF font
files as same as usual face then. otherwise set FcDontCare to FC_VARIABLE and
need more changes in the code to deal with non-named-instances perhaps.
The meta face which you faced the issue this time provides such information
instead of providing it as one of faces because there are so many patterns to
enummerate everything and quite hard to do. the targetted properties such as
FC_WEIGHT, FC_WIDTH and FC_SIZE has a value in FcRange which means they can use
an unique value between them.
Unfortunately there are no more detailed document though, pango source code may
helps how to deal with them.
--- Additional comment from Akira TAGOH on 2020-03-13 10:16:22 UTC ---
You can see what values the meta face provides. try fc-list -b -v
Cantarell:variable=true for example.
--- Additional comment from Zdenek Dohnal on 2020-03-13 10:40:41 UTC ---
IMO they are not aware of the fact the variable fonts need a special care when
are used from fontconfig.
I'll check with upstream about variable fonts then.
Thank you for the info!
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1813187
[Bug 1813187] ghostscript does not load variable fonts from fontconfig
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1813230] New: [RFE] ghostscript add support for variable fonts from fontconfig