Work Sans/Poppins do not work because of broken FOP auto-detection

[ghost]

The Poppins font has issues with FOP: FOP always selects the ultra-light version rather than the regular one.

The Poppins issue could probably be dealt with in a few ways:

1. a custom package with only a limited number of weights. I.e. just regular+bold (and italics of both). The issue is mostly that FOP can't deal with thinner and very thick weights (100, 200, 300, 800, 900) properly somehow. [suggestion sknorr]

2. Create a new directory, lets say /usr/share/daps/fonts/, and link only the fonts that you need from the original /usr/share/fonts/truetype/. Additionally, add the first directory into the FOP configuration to be searched for fonts. This may help to exclude the "wrong" fonts files so FOP does only find what are available. Maybe we could insert these links into the suse-xsl-stylesheets package. I think it would be an appropriate place as we need font dependencies anyway. [suggestion toms]

3. Register only those fonts in FOP that are really needed. I'm not entirely sure if this would solve the issue, but it could be worth a try. [suggestion toms]

Quang has opened an upstream issue for this: https://issues.apache.org/jira/browse/FOP-3045

[quatran]

1 and 2 won't work because Poppins Regular Italic isn't recognized by FOP correctly. Poppins Regular Italic is necessary for use case.

3 has the problem that only Daps can ship a FOP config. But the FOP config we need is dependent on the fonts needed by suse-xsl-stylesheets. This would create a circular reference.

@tomschr @fsundermeyer What are your thoughts on this?

[tomschr]

Ok, thanks Quang for your efforts. Seems packaging or directory configs are not a viable workaround. I thought something as simple and basic as font weights should work. That's disappointing.

So it looks like it's a deficiency/bug in FOP.

The circular dependency issue is probably the least of the problems. We could try option 3 and hope to get around this issue.

Another alternative that I can think of (as an option 4), we maybe need to dig deeper into font naming inside the font files. Perhaps we need to re-export the fonts with FontForge into something that is more suitable for FOP. Although it has some downsides (maintenance etc.) it maybe is the only workaround that could potentially fix it. :shrug:

[ghost]

The circular dependency issue is probably the least of the problems. We could try option 3 and hope to get around this issue.

Configuring the font that way should definitely work. The issue is just that we have all of the following options for shipping the config...

1. We use DAPS to ship an FOP config that only works with a specific set of stylesheets (super-ugly imo).
2. We use the stylesheets package to ship the FOP config and each user needs to apply it individually via ~/.config/daps/dapsrc (predictably, most people will not apply this config [1]; also ugly).
3. We use the stylesheets package to ship the FOP config and define the FOP config via the DC files (updating this in all repos/branches is tons of busywork; also pretty ugly).
4. We add functionality to DAPS to auto-discover FOP configs shipped with stylesheet packages, meaning we automatically get the right config for the right stylesheets (imo the correct solution but this needs a DAPS update).

Another alternative that I can think of (as an option 4), we maybe need to dig deeper into font naming inside the font files. Perhaps we need to re-export the fonts with FontForge into something that is more suitable for FOP. Although it has some downsides (maintenance etc.) it maybe is the only workaround that could potentially fix it. shrug

Ideally, we would also like to avoid degrading the font files. I am not sure whether FontForge will export the original kerning and hinting tables again or if it will remove/replace any of them.

---

[1] We use this approach for GeekoDoc already and every couple of weeks, we get questions like "why does my document not validate in the CI? it validates locally !! " and quite often it's people from the doc team asking this. Every time, it turns out they did not set up GeekoDoc correctly. Which just shows how hard this approach is failing.

[fsundermeyer]

1 and 2 are no suitable options, because this only works locally. We would get into trouble when buiulding on OBS (or would have to adjust the spec files). Option 4 is doable, we would need a defined location like <STYLEROOT>/pdf/daps/fop.conf. Option 3 sounds good to me, too.

[ghost]

Thanks for the quick response!

Option 4 is doable, we would need a defined location like /pdf/daps/fop.conf.

Circa 2013 2014, when I didn't yet know that the stylesheet-dependent formatter config approach is not supported by DAPS, I created a place for that already, <STYLEROOT>/formatter-config: https://github.com/openSUSE/suse-xsl/tree/main/suse2021-ns/formatter-config

Decide for yourself if the name is (still) suitable.

[tomschr]

I've talked to Quang and he will investigate if registering a font would be suitable. This is easy and quick to test. We think, this is the best method before we do any other, more complicated things.

If that works, that will give us some benefits:

a. We still can use the auto-detect feature. b. Manual defined fonts overwrite auto-detected fonts (according to the FOP web page). c. We can add our manual definition for Poppins inside the FOP config. Such a fragment will look like this:

<fonts>
   <font kerning="yes" embed-url="/usr/share/fonts/truetype/Poppins-ExtraLight.ttf" embedding-mode="subset">
      <font-triplet name="Poppins" style="normal" weight="100"/>
   </font>
   <!-- more similar entries -->
</fonts>

What Quang will investigate:

• If the font weights from 100 - 900 are all shown in the PDF once the FOP config is used. (Of course we don't use all Poppins font weights, but we need to make sure if this is a font or a FOP problem).
• Does FOP still run even if the Poppins fonts aren't installed? This could solve us from any dependency issues as we could just deliver our modified FOP config and we are done. We will see if that's feasible.

So let's wait and see what Quang will find out.

[quatran]

If the font weights from 100 - 900 are all shown in the PDF once the FOP config is used.

I have registered the fonts in the fop.xconf and it works. So we can safely assume that the auto-detection of FOP does not work for Poppins. The font itself is fine.

Screenshot: left before - right after

The used fop.conf and FO as an attachment.

poppins.zip

Does FOP still run even if the Poppins fonts aren't installed?

Yes. Only if it isn't demanded by the FO.

Edit: Fix slanted fonts

[ghost]

@quatran Thanks! Minor thing: Those italics do not look right currently, they are slanted too much. You should definitely switch to simulate-style="false" for those before committing this anywhere.

[quatran]

@sknorr Thanks. I have fixed this.

[tomschr]

That's great! Thanks Quang, that looks very promising!

I think, from what Quang found, we could proceed as follows:

1. Use Quang's configuration with a) autodetection enabled, and b) the font structure for Poppins. FOP can still find other fonts. If needed, we could amend the config with our additional font structures.
2. Change the FOP config in the daps repo accordingly.

This has the following benefits:

• We don't have to create a config detection mechanism.
• We avoid any (circular) dependencies.
• The font weights are correct.
• We aren't forced to install the Poppins font package if we want to use daps without our stylesheets.

There is one, possible downside:

• Different font paths for Debian, Fedora etc. This issue could be mitigated with a configure/autoconf mechanism. Frank? :wink:

What do you think?

[fsundermeyer]

We already have differnt fop-configs (generic, RedHat, SUSE) handled by autoconf, so that shoul not be a problem (https://github.com/openSUSE/daps/tree/main/etc/fop)

[ghost]

On that point:

We avoid any (circular) dependencies.

Those are actually not avoided -- whenever we'd need another ~incompatible font in the stylesheets, we would still have to update both the DAPS and the suse-xsl-stylesheets package. (And both of SUSE's last two fonts, Work Sans and Poppins were incompatible. It stands to reason that upon a redesign this pattern would continue.)

Different font paths for Debian, Fedora etc. This issue could be mitigated with a configure/autoconf mechanism.

I hadn't thought about this ... but indeed if we wanted support someone would have to check the file names on those OSs etc.

[tomschr]

Just to summarize what we (Quang, Stefan, and I) discussed in our meeting.

Stefan thinks, adding the modified FOP config to the daps repo would still be an unclean solution. However, for the time being and due to resource constraints, we follow this approach.

Quang will open a pull request on the daps repo with his modified FOP config.

Thanks to all!