DevHeads.net

Reply to comment

Re: HEADS UP - Changes to Ghostscript package in F28

By David Kaspar at 01/10/2018 - 09:30

The 'ghostscript-core' is a "main" subpackage in previous subpackage
scheme. It basically contained almost everything from Ghostscript's
compilation, and IIRC few of other packages were requiring this package
directly in their specfiles...

Other packages were not yet updated to requires correct subpackage from new
subpackage layout. Therefore I decided to transform 'ghostscript-core' into
auxiliary subpackage, since it was already there.

This should have allowed new Ghostscript to be rolled out without breaking
build process for them (hopefully completely, or at least it should at
mitigate most of the problems). And the other packages can be then rebuild
immediately once their requirements have been appropriately updated. :)

Why are examples not shipped? For documentation, this seems to be
Since I was doing changes to contents/layout of Ghostscript, I thought it
was a good time to incorporate this change into the package already.​

​The folder /usr/share/ghostscript/conf.d/ actually comes from the package
'ghostscript-chinese'. Ghostscript itself was just configured to check that
folder for configuration before, if there was any.

The folder itself contained mappings for specific locales into
specific CJK-based
fonts. It was used only after 'ghostscript-chinese' was installed. This
solution was introduced into Ghostscript more than a decade ago, and it is
based on ​this project: <a href="https://www.freedesktop.org/wiki/Software/" title="https://www.freedesktop.org/wiki/Software/">https://www.freedesktop.org/wiki/Software/</a>
CJKUnifonts/

If you look at the project, you will that it is basically dead, and the
'ghostscript-chinese' package itself received last update in 2012.

The main purpose of using 'ghostscript-chinese' is to introduce a
workaround for displaying/printing of CJK-based documents which do not have
the correct font embedded (for displaying the glyphs inside the document
text). When document wouldn't have correct CJK font(s) embedded inside it,
then Ghostscript would the closest substitution(s), so the document can be
at least displayed/printed in a readable/legible way. However, the
substitution will never be perfect, and will always be best-effort
workaround.

The above described situation was valid several years ago. Nowadays
upstream has its own solution (i.e. workaround) on doing so, which is based
only on one (different) font - Google Droid Sans Fallback.

I'm still discussing this change with Peng Wu (maintainer of
'ghostscript-chinese') and Akira Tagoh (fontconfig upstream developer)
off-the-list, but for now we have agreed to try use the default upstream's
solution for this scenario.

If it works well, this should mean less maintenance work for Peng
('ghostscript-chinese' could be dropped), and we wouldn't have a downstream
solution that could potentially cause additional issues in the future.
Also, the downstream solutions were really not popular with upstream before
(IMHO they didn't like Fedora at all because of it), and I was working with
them for last half and a year to improve our relationship with them from
Fedora side. :)

I hope I didn't forget to mention something important... :D If something is
unclear, lay it on me! ;)

Reply