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
[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_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 (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
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)
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)
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
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.
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
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
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
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...).
(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)
(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
Created attachment 350862 [details] Example for reproducing font problem (with using OTF STIX fonts)
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
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.
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.
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?
Looks like it's fixed to me. Thanks
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Closing based on comments #c16 and #c17.