For Sphinx HTML at least, a "proper" solution might be to create (and
maintain) a Public Domain theme that does not bundle any JavaScript etc.
and uses shared resources from Fedora if needed (or better yet, does not
use any), and ask packagers to manually change the theme to this one. If
that works, we could even provide a convenient macro/script to build it
instead of requiring each package to patch conf.py.
This seems like a somewhat nontrivial effort, but it could be
technically workable.
Some documentation is tightly tied to special features of its preferred
Sphinx theme, but most documentation will build acceptably (just as
good, or slightly degraded) with any theme.
Patching conf.py in one way or another would still be needed, as it
generally contains essential project-specific information,
configuration, and plugin setup. However, in most cases the theme could
be adjusted by simply appending
> html_theme = "my_foo_theme"
to the end of the file to override the upstream setting rather than
patching more intelligently.
As for PDF docs, has anybody checked if they bundle fonts?
Well, a PDF generated via Doxygen that I spot-checked by opening it in
FontForge certainly does: various flavors of Computer Modern, Nimbus
Sans, Nimbus Mono, and DejaVu Sans (all subsetted to include only the
glyphs that are actually used). A PDF generated via Sphinx contained
various flavors of TeX Gyre Heros, TeX Gyre Termes, Nimbus Roman No. 9,
t1xtt, and tcxtt (also subsetted). You can also examine these with
“pdffonts” from poppler-utils. But what’s to be done about it?
All the routes I know of to get PDF documentation from either Doxygen or
Sphinx go via LaTeX; the documentation system can be asked to output
LaTeX, and then pdflatex does the rest, often via a generated helper
Makefile. In many cases, like Computer Modern, the t??tt fonts, and the
TeX Gyre fonts, the font is originally a Type 1 PostScript font and has
no OpenType (TTF/OTF) equivalent in the first place.
I’m not aware of a way to remove embedded fonts from a PDF using free
software, nor am I aware of a way to ask pdflatex not to embed them
(again, in cases where an OpenType equivalent suitable for packaging as
a system font even exists).
If the ban on bundled fonts were interpreted as applying to PDF font
embedding, I think that would be tantamount to a practical ban on the
PDF file format. It’s hard for me to imagine that outcome is what was
intended, but maybe I’m wrong.
-----
The current versions of the cairomm[1] and gi-docgen[2] spec files
demonstrate what generating PDF documentation from Doxygen and Sphinx,
respectively, can look like. (I have found some packages where
Doxygen-generated LaTeX can’t be rendered because it exhausts some fixed
TeX resource limit—upstreams commonly test HTML output only—but these
techniques do seem to work in most cases.)
[1]
https://src.fedoraproject.org/rpms/cairomm/blob/cd53c4ac4f42d38b8f3874a369292bfd9d99fd76/f/cairomm.spec
[2]
https://src.fedoraproject.org/rpms/gi-docgen/blob/10b9115d8103dd59009c35ab53be8dbc743cc01c/f/gi-docgen.spec
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
