Bug 477445 - [python-matplotlib] Please convert to new font packaging guidelines
[python-matplotlib] Please convert to new font packaging guidelines
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: python-matplotlib (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Spura
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
Blocks: F11-new-font-rules 562421
  Show dependency treegraph
 
Reported: 2008-12-20 19:37 EST by Nicolas Mailhot
Modified: 2015-09-09 15:50 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 07:00:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Example for reproducing font problem (with using OTF STIX fonts) (610 bytes, application/octet-stream)
2009-07-07 17:02 EDT, David Barton
no flags Details
Output on F22 (11.89 KB, application/pdf)
2015-07-08 10:50 EDT, Jonathan Underwood
no flags Details

  None (edit)
Description Nicolas Mailhot 2008-12-20 19:37:26 EST
This bug has been filed because we've detected your package includes one or several font files:                                                                                                                                                             repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb' -f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e 's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq                                                                                                                                                             Unfortunately the script does not detect symlinks to other packages, so if that's your case, you can close this bug report now.                                                                                                                                                              Otherwise, you should know that:                                                                                                                                                              - Fedora guidelines demand the packaging of fonts in a separate package or subpackage: http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages                                                                                - our font packaging guidelines recently changed, and every package that ships fonts must be adapted to the new templates available in the fontpackages-devel package. http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18) http://fedoraproject.org/wiki/Fedora_fonts_policy_package http://fedoraproject.org/wiki/Simple_fonts_spec_template http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts                                                                                                                                                              Please make your package conform to the current guidelines in rawhide.                                                                                                                                                             If your package is not principaly a font package, depending on a separate font package or subpackage is the prefered solution. If your application does not use fontconfig you can always package symlinks to the files provided by the font package and installed in the correct fontconfig directories.                                                                                                                                                              It is preferred to make a font package or subpackage per font family, though it is not currently a hard guidelines requirement (it may become before Fedora 11 is released). The definition of a font family is given on http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family                                                                                                                                                              The new templates should make the creation of font subpackages easy and safe.                                                                                                                                                              The following packages have already been converted and can serve as examples: - andika-fonts - apanov-heuristica-fonts - bitstream-vera-fonts - charis-fonts - dejavu-fonts - ecolier-court-fonts - edrip-fonts - gfs-ambrosia-fonts - gfs-artemisia-fonts - gfs-baskerville-fonts - gfs-bodoni-classic-fonts - gfs-bodoni-fonts - gfs-complutum-fonts - gfs-didot-classic-fonts - gfs-didot-fonts - gfs-eustace-fonts - gfs-fleischman-fonts - gfs-garaldus-fonts - gfs-gazis-fonts - gfs-jackson-fonts - gfs-neohellenic-fonts - gfs-nicefore-fonts - gfs-olga-fonts - gfs-porson-fonts - gfs-solomos-fonts - gfs-theokritos-fonts - stix-fonts - yanone-kaffeesatz-fonts                                                                                                                                                           If you have any remaining questions about the new guidelines please ask them on fedora-fonts-list at redhat.com
Comment 1 Nicolas Mailhot 2008-12-20 19:56:53 EST
[Since the bot made a mess of the text here it is again in properly indented form.]

This bug has been filed because we've detected your package includes one or several font files:

repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb' -f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e 's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq

Unfortunately this script does not detect symlinks to other packages, so if that's your case, you can close this bug report now.

Otherwise, you should know that:

— Fedora guidelines demand the packaging of fonts in a separate package (or subpackage):
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

— our font packaging guidelines recently changed, and every package that ships fonts must be adapted to the new templates available in the fontpackages-devel package:
  – http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18)
  – http://fedoraproject.org/wiki/Fedora_fonts_policy_packagehttp://fedoraproject.org/wiki/Simple_fonts_spec_templatehttp://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

Please make your package conform to the current guidelines in rawhide (you can use the fontpackages package in F9 or F10 to test, but only submit changes to rawhide please).

If your package is not principaly a font package, depending on a separate font package or subpackage is the prefered solution. If your application does not use fontconfig you can always package symlinks to the files provided by the font package and installed in the correct fontconfig directories.

It is preferred to create a font package or subpackage per font family, though it is not currently a hard guidelines requirement (it may become before Fedora 11 is released). The definition of a font family is given on:
http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family

The new templates should make the creation of font subpackages easy and safe.

The following packages have already been converted by their packager and can serve as examples:
❄ andika-fonts
❄ apanov-heuristica-fonts
❄ bitstream-vera-fonts
❄ charis-fonts
❄ dejavu-fonts
❄ ecolier-court-fonts
❄ edrip-fonts
❄ gfs-ambrosia-fonts
❄ gfs-artemisia-fonts
❄ gfs-baskerville-fonts
❄ gfs-bodoni-classic-fonts
❄ gfs-bodoni-fonts
❄ gfs-complutum-fonts
❄ gfs-didot-classic-fonts
❄ gfs-didot-fonts
❄ gfs-eustace-fonts
❄ gfs-fleischman-fonts
❄ gfs-garaldus-fonts
❄ gfs-gazis-fonts
❄ gfs-jackson-fonts
❄ gfs-neohellenic-fonts
❄ gfs-nicefore-fonts
❄ gfs-olga-fonts
❄ gfs-porson-fonts
❄ gfs-solomos-fonts
❄ gfs-theokritos-fonts
❄ stix-fonts
❄ yanone-kaffeesatz-fonts

If you have any remaining questions about the new guidelines please ask them on:
fedora-fonts-list at redhat.com
Comment 2 Nicolas Mailhot 2009-01-11 10:20:11 EST
To help packagers manage the transition to the new guidelines, we've published the following FAQ

http://fedoraproject.org/wiki/Shipping_fonts_in_other_packages_(FAQ)
Comment 3 Nicolas Mailhot 2009-01-14 13:37:50 EST
FPC approved those two additional guidelines recently, please take them into account if you need to create or update a fonts package or subpackage:

– 2009-01-14: naming
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282009-01-13%29

— 2009-01-06: exact splitting rules
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29

(packagers that can drop font files and just depend on an existing font package are not impacted)
Comment 4 Nicolas Mailhot 2009-02-18 14:32:46 EST
This is a reminder for all the packagers that still have bugs open about adapting to font packaging guidelines there is only one month left before Fedora 11 beta:
http://fedoraproject.org/wiki/Releases/11/Schedule

A week of this month will see the Fedora 11 mass rebuild, that will load the build farm:
http://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild

As already converted packages showed it is quite possible to make mistakes during the conversion. Please make releng and QA happy and don't wait till the last minute to do your changes (avoid pre-beta panic). If possible start before the mass rebuild so we don't burn cycles on incorrect packages.

The PackageKit enhancements stated for Fedora 11 assume fonts and font-using packages are sane (basically respect packaging guidelines). It is quite possible that not-converted packages will interact with the F11 font autoinstall feature in "interesting" ways.
http://fedoraproject.org/wiki/Features/AutomaticFontInstallation

We don't want that

There is extensive documentation on the wiki and most of your questions have likely already been answered there. Please do read the FAQ before making more work for the support team by asking questions answered there.
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29
Comment 5 Jef Spaleta 2009-02-23 13:06:08 EST
I  think I took care of this awhile ago by just excluding the fonts from the package and adding
Requires:       dejavu-fonts-sans

for the default situation.

Since scripts based on python-matplotlib can be configured to use additional fonts in plotting output, It will be interesting to know how to get it to call the font autoinstaller when a new font family is requested.

I'm going to close this bug out, as I think I've correctly addressed this in the packaging. Please re-open if needed.
Comment 6 Nicolas Mailhot 2009-02-23 13:37:54 EST
dejavu-fonts-sans existed before FPC engaged in naming bikesheding. Since FPC changed the rules just before F11 alpha it was kept as provides to avoid alpha breakage. However, it will be gone in this evening's rawhide

Behdad is probably the one you want to talk to if you want to know what will trigger font autoinstall in F11
Comment 7 Jef Spaleta 2009-02-23 15:51:00 EST
shrug.. I take it I just need to change that requires definition to match the naming.

-jef"bikesheds are a poor analogy where I live...sleddog doghouses..i can relate to"spaleta
Comment 8 Bug Zapper 2009-06-09 06:25:10 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 David Barton 2009-07-07 09:13:58 EDT
Unfortunately now Matplotlib doesn't work properly with STIX fonts (as included in the upstream matplotlib package for scientific graphs) since the Fedora supplied ones are in OpenType format rather than TTF (as supplied by Matplotlib).

Matplotlib is unable to do font subsetting on OTF fonts and it's fallback option of including the whole font doesn't appear to work (the resulting PDF doesn't have any text...).
Comment 10 Nicolas Mailhot 2009-07-07 10:20:37 EDT
(In reply to comment #9)
> Unfortunately now Matplotlib doesn't work properly with STIX fonts (as included
> in the upstream matplotlib package for scientific graphs) since the Fedora
> supplied ones are in OpenType format rather than TTF (as supplied by
> Matplotlib).

Stix upstream is OpenType CFF only. They've promised to look at OpenType TT in the next version, but who knows when it will be released. So our Stix font packages are unlikely to include OpenType TT any time soon (and even if Stix finaly releases OpenType TT versions I don't think we really want to package two versions of the same fonts, they are huge and that only encourages app authors not to fix their font support. CTAN made the mistake of encouraging the packaging of fonts in multiple formats and as a result is stuck with all of them since now people got used not having to support newer formats).

In the very short term the matplotlib maintainer will probably have to package the built-in Stix TTFs as proper matplotlib font subpackages. But do remember this is not a sustainable workaround since it has the exact same drawbacks as private libs and we'll ask to kill them in later Fedora releases.

> Matplotlib is unable to do font subsetting on OTF fonts 

Well, that's a big matplotlib issue, OpenType CFF is one of the three major modern font formats (with OpenType TT and Apple AAT, but rumors are Apple is realising it can't sustain AAT alone when everyone else chose OpenType), and it's the default in many font creation tools, so it will become more and more common.

Please work with upstream so they fix their font backend (or switch to modern font libs such as fontconfig/cairo/poppler that can handle modern fonts)

> and it's fallback
> option of including the whole font doesn't appear to work (the resulting PDF
> doesn't have any text...).  

That's strange since Opentype CFF is Adobe's child as PDF, so it's probably the most PDF-friendly modern font format. But Stix does all kinds of unusual and complex things. It's not a simple font set (all the more reason not to ship different variants that will have subtle conversion problems)
Comment 11 Jef Spaleta 2009-07-07 15:40:36 EDT
(In reply to comment #9)

Can you do me a huge favor? Can you attach a simple example script and matplotlibrc file that I can use to reproduce the problem locally without having to rely on my own trial and error to produce it.   

-jef
Comment 12 David Barton 2009-07-07 17:02:15 EDT
Created attachment 350862 [details]
Example for reproducing font problem (with using OTF STIX fonts)
Comment 13 Bug Zapper 2010-04-27 08:35:50 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Bug Zapper 2010-06-28 07:00:10 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 15 Sven Lankes 2010-07-17 17:27:51 EDT
Reopening with FutureFeature keyword added to avoid automatic bugzapper actions in the future.

While it doesn't look that this issue is going to be fixed anytime soon, we should still have the bug open to be reminded about it.
Comment 16 Jonathan Underwood 2015-07-08 10:50:18 EDT
Created attachment 1049892 [details]
Output on F22

This is the output of pdffontproblems.py on Fedora 22. I think this shows that the problem with the STIX fonts is now addressed and this bug can be closed, right?
Comment 17 David Barton 2015-07-20 07:57:27 EDT
Looks like it's fixed to me.

Thanks
Comment 18 Fedora Admin XMLRPC Client 2015-09-09 15:30:12 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Fedora Admin XMLRPC Client 2015-09-09 15:50:58 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Note You need to log in before you can comment on or make changes to this bug.