search

openSUSE / suse-xsl

DocBook XSL Stylesheets for SUSE branding
Other
11 stars 10 forks source link

Charis SIL 6.x is incompatible with FOP #438

Closed ghost closed 2 years ago

ghost commented 3 years ago

Within the suse2013 and suse2021-ns stylesheets, we're using Charis SIL as a font for paragraphs in PDFs. This has always worked fine, however, version 6.x of the font, which since mid-Aug 2021 has been shipped via M17n:fonts is incompatible with FOP. The incompatibility shows in the sense that the font can't be embedded into the document for some reason, though on systems with the font installed, the PDF will usually appear correctly. To determine whether a PDF is broken, you can

For the moment, that is fine because we can just switch back to a working 5.x version (as shipped in Leap up to 15.3 by default) in every context that matters. We will also need to migrate suse2021 to the Poppins font eventually (but of course that font has issues with FOP as well--FOP always selects the ultra-light version rather than the regular one).

tomschr commented 3 years ago

Maybe there are two separate issues that come together: as I briefly mentioned in the chat, the font names changed between version 5 and 6. This could be easily solved by adding compatibility links.

The trickier part is when the fonts have changed themselves. That is more difficult.

The issue with Poppins is really unfortunate. Maybe we need to go down this rabbit hole and configure FOP directly. Maybe we need to register fonts in FOP. This would allow to assign the specific font properties to a (font) name.

ghost commented 3 years ago

The Poppins issue could probably be dealt with just 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.

What happened with Charis, I don't know, although I suspect that it's not the file names. Either that font now does something that FOP doesn't like or it's plainly set to non-embeddable (and FOP for some reason respects that setting).

tomschr commented 3 years ago

The Poppins issue could probably be dealt with just a custom package with only a limited number of weights. I.e. just regular+bold (and italics of both).

I would advise against this. Although a custom package would probably technically work, it's something "separate". See my idea below.

To meet our requirements, I would suggest a different approach. I have these ideas in mind:

a. 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.

- or -

b. Register only those fonts in FOP that are really needed (see link in https://github.com/openSUSE/suse-xsl/issues/438#issuecomment-911317423). I'm not entirely sure if this would solve the issue, but it could be worth a try.

Would suggest that we create a small FO file and test the Poppins font. We could combine that with the Charis font(s) as we need to test them too. So we could do that in one go. I will ask on the FOP mailinglist if this attempt wasn't successful.

I'm also surprised about the changes in Charis. If our test wasn't successful we might need to either a) stick to version 5 or b) get help from FontForge and re-export the font to TTF again. That could (hopefully) solve the problem. Whatever it might be.

ghost commented 3 years ago

b. Register only those fonts in FOP that are really needed (see link in #438 (comment)).

I have been talking to Frank about the need for per-stylesheet FOP and XEP config files before, but so far that is not implemented. The XEP and FOP config cannot be determined by the stylesheet. The settings follow the usual precedence rule, 1. DC file - 2. ~/.config/daps/dapsrc - 3. /etc/daps/dapsrc. For us, this is not particularly useful.

And creating one config file as part of the DAPS repo that is somehow supposed to work with all stylesheets is (1) a really weird (i.e. bad) separation of concerns, and (2) does not scale.

ghost commented 2 years ago

@tomschr I promised to add my (broken!) FOP patch here, attempting to work out the issues with Work Sans & Poppins, this is it: 0001-Fix-detection-for-thin-extra-light-black-fonts.patch

quatran commented 2 years ago

[The Charis issue] can't be longer reproduced. It was probably fixed by an update for xmlgraphics-fop.

(edit by sknorr: clarification)

quatran commented 2 years ago

I have opened an Apache Jira Ticket for the issue regarding Poppins

https://issues.apache.org/jira/browse/FOP-3045

ghost commented 2 years ago

Ok, since the Charis issue is reportedly solved but the Poppins/Work Sans issue is still open, I guess we need a new bug. Welcome, #446..

ghost commented 2 years ago

I finally got to checking this again. It appears the issue is fixed by the upgrade from FOP 2.1 to FOP 2.6 (or one of the dependencies of the new FOP).

We are not using either FOP 2.6 or Charis 6.0 in our Leap containers but we probably should ...