Bug 477397 - Please convert to new font packaging guidelines
Please convert to new font packaging guidelines
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: htmldoc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Goode
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11-new-font-rules
  Show dependency treegraph
 
Reported: 2008-12-20 19:29 EST by Nicolas Mailhot
Modified: 2009-02-11 13:15 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-11 13:15:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2008-12-20 19:29:06 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:55:46 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 Patrice Dumas 2008-12-21 10:09:34 EST
Looking at the font files, there is:

Notice (Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved.)
%Copyright: Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved.
%Copyright:  DejaVu changes are in public domain

Comment Copyright URW Software, Copyright 1997 by URW
Comment Creation Date: 10/21/1999 
Comment See the file COPYING (GNU General Public License) for license conditions.
% Copyright URW Software, Copyright 1997 by URW
% URW Software, Copyright 1997 by URW
% See the file COPYING (GNU General Public License) for license conditions.
% As a special exception, permission is granted to include this font
% program in a Postscript or PDF file that consists of a document that
% contains text to be displayed or printed using this font, regardless
% of the conditions or license applying to the document itself.

So it looks like those fonts were taken from elsewhere, though it is not 
completly clear to me where they come from. grepping in 
 /usr/share/fonts/default/Type1/
doesn't exactly lead to the same.
Comment 3 Patrice Dumas 2008-12-21 10:10:13 EST
Also are there type1 variants of DejaVu fonts in fedora?
Comment 4 Nicolas Mailhot 2008-12-21 10:25:54 EST
That seems the typical font licensing mess. I don't even want to look at it, that's something for spot if you want to keep those files.

Do you really need the files in Type1 form? I suppose it may be possible to convert DejaVu to Type1 at build time, though since the Type1 format is very limited, that will be a huge mess with quality loss and conflicts with the main dejavu truetype fonts.
Comment 5 Patrice Dumas 2008-12-21 14:12:34 EST
(In reply to comment #4)
> That seems the typical font licensing mess. I don't even want to look at it,
> that's something for spot if you want to keep those files.

I am not sure. In my opinion it could also be that Adam should contact
upstream...

> Do you really need the files in Type1 form? 

As far as I can tell (after a bit of code reading), yes. It even looks like it can only embed .pfa and not .pfb. Those fonts are embedded in pdf or ps produced. I haven't completly understood how the name is constructed from the
html, but the names of the font files that can be embedded are hardcoded in an array, corresponding with

Courier-Bold.pfa
Courier-BoldOblique.pfa
Courier-Oblique.pfa
Courier.pfa
Dingbats.pfa
Helvetica-Bold.pfa
Helvetica-BoldOblique.pfa
Helvetica-Oblique.pfa
Helvetica.pfa
Monospace-Bold.pfa
Monospace-BoldOblique.pfa
Monospace-Oblique.pfa
Monospace.pfa
Sans-Bold.pfa
Sans-BoldOblique.pfa
Sans-Oblique.pfa
Sans.pfa
Serif-Bold.pfa
Serif-BoldOblique.pfa
Serif-Oblique.pfa
Serif-Roman.pfa
Symbol.pfa
Times-Bold.pfa
Times-BoldItalic.pfa
Times-Italic.pfa
Times-Roman.pfa

(all the fonts shipped in htmldoc).

> I suppose it may be possible to
> convert DejaVu to Type1 at build time, though since the Type1 format is very
> limited, that will be a huge mess with quality loss and conflicts with the main
> dejavu truetype fonts.

In any case htmldoc doesn't use fontconfig therefore just packaging them without a possibility to be used by fontconfig could be possible. I don't know if you want to do that, though.
Comment 6 Nicolas Mailhot 2008-12-21 15:08:13 EST
It all looks like pfa forks of well-known (gs/urw/xorg/dejavu) fonts
Unfortunately those fonts seems all one-of-a-kind

So assuming they're all legit license-wise, you'll probably have to package them yourself

It's a pity upstream spent time making its own fonts instead of supporting modern (TTF/OTF/fontconfig) standards.
Comment 7 Nicolas Mailhot 2008-12-21 15:32:49 EST
Thinking about it some more, the correct plan for the htmldoc packager(s) is probably:

1. long-term: ask upstream to move to fontconfig/freetype/pango/cairo
2. short-term:
 * ask upstream what its original font sources were
 * if those fonts exist in type1 form in Fedora, link them from here
 * if those fonts do not exist in type1 form in Fedora, but have some other canonical type1 source, package this source properly
 * if they're strictly an htmldoc production, and have no other proper source (and it can be acertained no license was hurt during their production) package them as htmldoc sub-packages (one per font family). Assuming upstream was smart enough to use its own font names and didn't re-use the name of someone else's font (in which case the fonts need to be rename or they'll conflict with the real fonts). The subpackage logic can be taken from
/etc/rpmdevtools/spectemplate-fonts-multi.spec
Comment 8 Adam Goode 2008-12-21 21:10:14 EST
Any day now I am expecting twins to arrive, so I don't think I will have enough time to properly address this issue. Anyone who would like to fix this problem if very welcome to co-maintain! :)

Besides this issue, the package is basically stable and low-maintenance. It comes from the same upstream as CUPS. (Not sure if that's changed since the Apple deal.)
Comment 9 Nicolas Mailhot 2009-01-11 10:19:31 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 10 Adam Goode 2009-01-11 20:54:17 EST
I don't think it makes sense necessarily for this project to move to pango/cairo or such, as it does no rendering itself, just outputting PDF, PS, or HTML. As such it just uses the .pfa files internally to output PDF and PS.

Also, the fonts all appear to be renamed urw-fonts in PFA format, or Deja Vu fonts in PFA format.

I think the thing to do is:

 * Symlink the URW fonts to the system-installed fonts

 * Modify the code to call pfatopfb at the right time when embedding

 * Not ship the Deja Vu fonts, just map serif, monospace, sans to the 
   URW versions

 * File bugs upstream


Upstream makes few releases and generally moves slowly, so I'm not sure how fast it will go upstream.
Comment 11 Adam Goode 2009-01-11 21:35:59 EST
http://www.htmldoc.org/str.php?L196
Comment 12 Nicolas Mailhot 2009-01-12 01:57:57 EST
(In reply to comment #10)
> I don't think it makes sense necessarily for this project to move to
> pango/cairo or such, as it does no rendering itself, just outputting PDF, PS,
> or HTML. As such it just uses the .pfa files internally to output PDF and PS.

This is one form of rendering too. But anyway the main point for you is to move to fontconfig in any form so you don't have to manage fonts in your package.

> Also, the fonts all appear to be renamed urw-fonts in PFA format, or Deja Vu
> fonts in PFA format.

That's the usual duplication of system fonts in non-fontconfig apps.

> I think the thing to do is:
> 
>  * Symlink the URW fonts to the system-installed fonts
> 
>  * Modify the code to call pfatopfb at the right time when embedding
> 
>  * Not ship the Deja Vu fonts, just map serif, monospace, sans to the 
>    URW versions

Sounds good. However DejaVu has more coverage than URW fonts, so mid-term it would be good to use it again.

>  * File bugs upstream
> Upstream makes few releases and generally moves slowly, so I'm not sure how
> fast it will go upstream.

You'll only know by asking
Comment 13 Nicolas Mailhot 2009-01-12 01:59:48 EST
(In reply to comment #12)
> (In reply to comment #10)

> >  * Not ship the Deja Vu fonts, just map serif, monospace, sans to the 
> >    URW versions
> 
> Sounds good. However DejaVu has more coverage than URW fonts, so mid-term it
> would be good to use it again.

Worst case you'll have to take care of your own Type1 DejaVu package in Fedora
Comment 14 Adam Goode 2009-01-12 08:50:05 EST
Upstream was very fast in responding. They say it is unacceptable to remove DejaVu support, so I will probably have to package Type1 DejaVu. I can then patch htmldoc to use the URW fonts and use popen to call t1ascii at runtime. That should fix things up for now.

Ultimately, htmldoc should use fontconfig, but I think that is long term since (correct me if I'm wrong) htmldoc would have to learn to directly read more font formats for this to be useful. Currently it only reads afm/pfa files and it hardcodes the FontName, so that it doesn't really need to parse or process the font files themselves, only embed.
Comment 15 Nicolas Mailhot 2009-01-12 09:15:09 EST
(In reply to comment #14)

> Ultimately, htmldoc should use fontconfig, but I think that is long term since
> (correct me if I'm wrong) htmldoc would have to learn to directly read more
> font formats for this to be useful.

I think you can specify the font formats you can handle in your fontconfig queries so this part should not be a blocker (ping behdad if you want more info)

That takes care of the symlinking stuff but still requires availability of fonts in one of the formats the app understands.

> Currently it only reads afm/pfa files and
> it hardcodes the FontName, so that it doesn't really need to parse or process
> the font files themselves, only embed.

Also we have lots of OTF fonts in the distro and OTF is the Type1 successor (should be all CFF data inside), so it may be easier for upstream so add support for OTF instead of TTF.
Comment 16 Nicolas Mailhot 2009-01-14 13:37:01 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 17 Adam Goode 2009-01-18 21:15:30 EST
I don't have time to guarantee work on this right now, many crazy things going on. Possibly I can find time before F11 ships!
Comment 18 Adam Goode 2009-01-30 00:45:52 EST
Would it be crazy to use FontForge at runtime to convert the TTF fonts into PFA fonts for each session? FontForge seems to be very fast at this. That way, we wouldn't need to ship any duplicate fonts at all.
Comment 19 Nicolas Mailhot 2009-01-30 01:40:33 EST
looks crazy to me but you can try, it's your package
Comment 20 Adam Goode 2009-02-11 13:15:18 EST
1.8.27-9

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