Bug 477397

[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

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.

Also are there type1 variants of DejaVu fonts in fedora?

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.

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

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.

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

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

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)

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.

http://www.htmldoc.org/str.php?L196

(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

(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

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.

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

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)

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!

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.

looks crazy to me but you can try, it's your package

1.8.27-9