I am the maintainer of the redmine package.  Redmine upstream ships
four NotoSans fonts in the .woff2 format.

https://salsa.debian.org/ruby-team/redmine/-/tree/debian/latest/app/assets/fonts?ref_type=heads

I would like to stop shipping these fonts in the redmine package
and instead depend on a proper Debian font package.

The purpose of this feature request is to ask about the feasibility
of also shipping a noto package that includes the .woff2 format
of the fonts.

If you are open to shipping the .woff2 format but do not have the
available time to implement it, I would be willing to prepare a patch
to do so.

tags -1 + patch
thanks

Dear maintainers,

I have prepared an MR for this issue:
https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/2

Best regards,

Quoting Soren Stoutner (2025-09-22 23:51:38)

You can use sfnt2woff-zopfli during build for the fonts you need.

 - Jonas

I am not sure I fully understand your comment.  Are you suggesting we use
sfnt2woff-zopfli instead of woff2_compress (which is what is currently used in
the MR)?

Quoting Soren Stoutner (2026-04-20 22:43:20)

No, I was just (through a random concrete tool) generally suggesting
that you do what you now make me aware that you already doing already
:-)

 - Jonas

We believe that the bug you reported is fixed in the latest version of
fonts-noto, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1116004@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Manuel Guerra <ar.manuelguerra@gmail.com> (supplier of updated fonts-noto package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 28 Apr 2026 21:57:12 +0000
Source: fonts-noto
Binary: fonts-croscore fonts-noto fonts-noto-core fonts-noto-extra fonts-noto-hinted fonts-noto-hinted-udeb fonts-noto-mono fonts-noto-ui-core fonts-noto-ui-extra fonts-noto-unhinted fonts-noto-unhinted-udeb fonts-noto-web
Architecture: source all
Version: 20201225-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Fonts Task Force <pkg-fonts-devel@lists.alioth.debian.org>
Changed-By: Manuel Guerra <ar.manuelguerra@gmail.com>
Description:
 fonts-croscore - width-compatible fonts for improved on-screen readability
 fonts-noto - metapackage to pull in all Noto fonts
 fonts-noto-core - "No Tofu" font families with large Unicode coverage (core)
 fonts-noto-extra - "No Tofu" font families with large Unicode coverage (extra)
 fonts-noto-hinted - obsolete metapackage to pull in a subset of Noto fonts
 fonts-noto-hinted-udeb - "No Tofu" font families with large Unicode coverage (d-i default) (udeb)
 fonts-noto-mono - "No Tofu" monospaced font family with large Unicode coverage
 fonts-noto-ui-core - "No Tofu" font families with large Unicode coverage (UI core)
 fonts-noto-ui-extra - "No Tofu" font families with large Unicode coverage (UI extra)
 fonts-noto-unhinted - "No Tofu" font families with large Unicode coverage (unhinted)
 fonts-noto-unhinted-udeb - "No Tofu" font families with large Unicode coverage (d-i optional (udeb)
 fonts-noto-web - WOFF2 webfont versions of Noto fonts
Closes: 1116004
Changes:
 fonts-noto (20201225-5) unstable; urgency=medium
 .
   * Team upload
   * Create new fonts-noto-web binary package.
   * Add debian/scripts/generate-noto-web.sh to convert TTF to WOFF2.
     (Closes: #1116004)
   * Update debian/control:
     - Add woff2 to Build-Depends.
     - Define fonts-noto-web package.
   * Update debian/rules:
     - Modernize to use debhelper options instead of CDBS.
     - Execute conversion script after dh_install.
   * Update copyright holders for debian/* stanzas.
   * Delete vendored *.mk files for the CDBS options.
   * Add debian/javascript/*.css files to control web fonts.
Checksums-Sha1:
 ea59c0efb25f252d1c052e8dc96532980530ba66 2795 fonts-noto_20201225-5.dsc
 ce9eb07102fc55d45c9ad923fbbe4a82cfe6fad8 111916 fonts-noto_20201225-5.debian.tar.xz
 2452b7894236c69b78a5fadac72275190df80736 1560528 fonts-croscore_20201225-5_all.deb
 0d3d276cb0804305df3d0392ea475fae8881cc51 12174864 fonts-noto-core_20201225-5_all.deb
 9f520bed61b55719a6cb85218513bf60e0f9d23a 72411788 fonts-noto-extra_20201225-5_all.deb
 356542b4db013cda5f19c1fb38ffc8ee60e2c083 145564 fonts-noto-hinted-udeb_20201225-5_all.udeb
 8a0193c415557e6d929e137dc2f05bac44554b53 4756 fonts-noto-hinted_20201225-5_all.deb
 9f15c88b96a9b66531369fc6c5898204bf264ca4 385636 fonts-noto-mono_20201225-5_all.deb
 623cd748669970c9d66caad8ecbf8466308d2f6a 1408080 fonts-noto-ui-core_20201225-5_all.deb
 e9db88b2297b83b68efacd73705c1f52f89cf36f 14239252 fonts-noto-ui-extra_20201225-5_all.deb
 844f0f510a082996a74264259904c97bacb7954f 10483188 fonts-noto-unhinted-udeb_20201225-5_all.udeb
 be6df0eeb4ee6b7b3d7d14ae0dff1697fda4aa03 4988 fonts-noto-unhinted_20201225-5_all.deb
 3fc0d0355a69b5a9532b21315d80186f90a30af0 892920 fonts-noto-web_20201225-5_all.deb
 b9c67e427ddd36c395531f6d44c0c30b9e52d136 16060 fonts-noto_20201225-5_all.deb
 2df97ff9eefb6913ac5fb32e64cc7cd21f68a7a2 9703 fonts-noto_20201225-5_amd64.buildinfo
Checksums-Sha256:
 8e3d4599bb47b5350eebc883f06dd8a9b99816fbb8fe1d9763a949988e3c39f0 2795 fonts-noto_20201225-5.dsc
 b7c170775e4732a5f58aec04f94a604e6c4c0b45a379aa0e06a84d8c3c85a587 111916 fonts-noto_20201225-5.debian.tar.xz
 3b624e4196661b12129143ddf0ef80f2f946ab94bc2e21a9951e7dc70362458d 1560528 fonts-croscore_20201225-5_all.deb
 da6115ab7211b1877337600b1b7ed1d2cab4d55dd9c288bd515ec1affb750845 12174864 fonts-noto-core_20201225-5_all.deb
 48825565992633c43c08a355993c6078d978f14c7232e65d5a1d3e4395bf902f 72411788 fonts-noto-extra_20201225-5_all.deb
 b65ccd3306eec9b4b81fa121ec2b30bc0730255bbb1dabeeafad238fa6642d79 145564 fonts-noto-hinted-udeb_20201225-5_all.udeb
 ede264d08b81ee46826a98ff4cb620785ca296a757480d3ce3a925cfe9c4d74a 4756 fonts-noto-hinted_20201225-5_all.deb
 bc444775973318f071c26bc9ece0d8458a7013fa1fa0f78cca778d307e5e3691 385636 fonts-noto-mono_20201225-5_all.deb
 d14eaddba40cb773dbcc93920febcb47410609b0468cdb947a64a7d1734cd4fa 1408080 fonts-noto-ui-core_20201225-5_all.deb
 f5f8e91c4f7228700185e429f14de1a84d79f8d1e7b36f78338af49578061177 14239252 fonts-noto-ui-extra_20201225-5_all.deb
 465015ba9adf04e031fe090e61b6bf617025d0cbcc5fed94e99d07220feafbe7 10483188 fonts-noto-unhinted-udeb_20201225-5_all.udeb
 f3a2310cc4cd7a28607220e20a37cb090776917fc38807dd0937a1dc0c437eb8 4988 fonts-noto-unhinted_20201225-5_all.deb
 60b8f7062f174bbbdc6a76dea5b0707cbbab1b57ad3d94cc5d9c6cfb22ceab17 892920 fonts-noto-web_20201225-5_all.deb
 02633c90e031b7735e23a6fb0870daec3b9d5eb8f6d08ad7aefa008fd7733dfc 16060 fonts-noto_20201225-5_all.deb
 8af3f42b1a794d104d2609c139c6ed38ed954a0a186462d7d06bc74eb6292226 9703 fonts-noto_20201225-5_amd64.buildinfo
Files:
 ea7da74d50c9e4cbc3d394d7bfd49541 2795 fonts optional fonts-noto_20201225-5.dsc
 86e94ecee74862f831af08789a8871eb 111916 fonts optional fonts-noto_20201225-5.debian.tar.xz
 61cfb6b507143fef312e2e1484158cde 1560528 fonts optional fonts-croscore_20201225-5_all.deb
 4e90fef759eeafba509df788d2d91771 12174864 fonts optional fonts-noto-core_20201225-5_all.deb
 2f9e0c4718d3bf3a4406e3910e3a9a32 72411788 fonts optional fonts-noto-extra_20201225-5_all.deb
 e335ab642cb1b453c5452ce4b60b1f09 145564 debian-installer optional fonts-noto-hinted-udeb_20201225-5_all.udeb
 df7d9ad166fb58e7120a49b9aaf5ce78 4756 oldlibs optional fonts-noto-hinted_20201225-5_all.deb
 7c8d4124e4e74a55159cde90f1f714d7 385636 fonts optional fonts-noto-mono_20201225-5_all.deb
 dc5d2ba05ad4c0d99928e618669a54da 1408080 fonts optional fonts-noto-ui-core_20201225-5_all.deb
 2feeb05851d2e19e486ffaf49a7fa954 14239252 fonts optional fonts-noto-ui-extra_20201225-5_all.deb
 357094e65c7795d81013cfe2c2ffc28b 10483188 debian-installer optional fonts-noto-unhinted-udeb_20201225-5_all.udeb
 0f97e2ae41068df8aeb3b1915c963606 4988 fonts optional fonts-noto-unhinted_20201225-5_all.deb
 776750f67b3bfedf1fbdc31a71db8316 892920 fonts optional fonts-noto-web_20201225-5_all.deb
 99b738f8bbd3ad5245e5c4fa6e931277 16060 metapackages optional fonts-noto_20201225-5_all.deb
 4e39e0bd7b176f091dd4aa7517781ed3 9703 fonts optional fonts-noto_20201225-5_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEj23hBDd/OxHnQXSHMfMURUShdBoFAmnxG3AACgkQMfMURUSh
dBpYBg/+JDgVc7EhfV/+Fj0beIrbDcwjwcj7QJuR0eytQFLPUaQ1YL8Qzkod5aDp
ASgjVf3QTFz5vgv3dl7GsbWAvLZ4X9gk7MrZQMrtSZLZ4o4KWNJDKjUN21SW+NdB
ygBbth81WI8D89fYQTi3xAwplwet7ZqV2/7ZKIaaYmF3XshAzhTvv5L2jh1bIEDu
BoozvsIPbsjxXEOWKa7zLPnGP3ZhOpaEQ/U7pR4ipC8uADqJ+ZRrP9bU05rep8vD
XJ+heYvfsuzloq9M01cxmjjItzet8St9Z+QhHi1RjSJqC8veVSzo8H9r2IMfdhed
wCfGUMz6KeOJfJ+yHVWImtMbBvTAOcmz1hK2v/Uw1z3Plzh+Rv5isztvRGlDZhjt
H6AVz/cQyz9aFzEQeA8Hp5Ap0pPtUZCgCRhUZiUHisFY8on1E4z3sKdVesbfHo2c
cGJPAj+UnvTKr6CLIBnsIVHGRxaiPsvvUyXBzLCGWa0tJZ1ggn5fi8eWt59Q/i35
lQVA+pWqyGFjNxQ7ZjagAq164oArBcAciNF8mu5wnrvForYxaBXfEiJdyCDczb4l
gTs6i3H2ySxi24/XltgUz0bjJEYAw8ipC227HSVUpY4epSqj1PhSUaN17iQQ5EXD
55oBIAi5SIT96q5Llx1IuxoJAiXBhKI7FkHAj0ygUE/228+gbnw=
=YWTl
-----END PGP SIGNATURE-----

I think is wrong for fonts-noto to provide a binary package
containing only a synthesized variation for a minor subset of its
fonts.

I find it wrong to go ahead and introduce such new package without
discussion.

I think the right cause of action now is to revert that change and drop
the newly introduced binary package fonts-noto-web.

Raising severity to avoid the package change to reach testing.

 - Jonas

Are you saying you would prefer that it shipped all the fonts in WOFF2 format
instead of just a subset?  If so, I would imagine that would be easy to do.

Wow, Jonas, applying a RC bug? That's pretty aggressive!

Could you support your "opinion" with something more technical, like the
Debian Policy, for example? I mean, what technical flaw does fonts-noto-web
have?

And regarding the consensus, the MR was there to discuss it for several
days. A responsible maintainer would have given their opinion directly in
the MR, stating that they disagreed with the update. In any case, if you
need a consensus, we still have time to try to achieve it (or not) instead
of completely blocking the package...

Regarding the fonts-noto update, I imagine you also prefer to keep the
vendorized CDBS options as well...

This only leads me to think that you don't allow anyone to touch your
packages.

I'd like to know Detiste's opinion on this. If the consensus is to roll
back fonts-noto, then that's fine by me.

Sorry if I sound rude.

Best regards,

Hello.

I just would like to point out that the maintainer of a package has
always the freedom to apply the serious severity for bugs in their
*own* package (i.e. it is not really necessary to mention any
precise item in policy).

https://www.debian.org/Bugs/Developer.en.html#severities

serious
[...]
or, in the package maintainer's [or release manager's] opinion,
makes the package unsuitable for release.

Thanks.

Quoting Soren Stoutner (2026-04-29 23:21:23)

With the subset you are quoting, I intended to say that the chosen
solution for the larger problem that I am only vaguely touching in my
full post and not discussed at all before the package change, is one
which I find wrong for several reasons.

No, I will not begin a discussion from "should we do more of this?" but
want to discuss the bigger picture.

 - Jonas

Quoting Manuel Guerra (2026-04-30 02:27:21)

From my point of view, you appear out of the blue and make a radical
change to a gigantic package with zero coordination ahead of that
change.

RC bugs are for more that Policy violations. I already stated my reason
for raising severity.

Interesting that I am to blame here for lack of collaboration. This is
clearly not working: I do not use MRs. I don't know who enabled MRs for
this package, but you should expect MR-style collaboration from those
who did, and not assume that everyone in Debian nor everyone in the
fonts team use that communication style. The fonts team has a
mailinglist that you can expect all team members to follow, if you want
to ensure that all have been heard and all are fine with you doing a
major change.

Oh, and "several days" is in my opinion not an acceptably sized window
for major packaging changes.

We have time until next freeze, indeed.

Do you also assume that I am racist and white and male? Or where did
that accusation spring from, and what on Earth does that have to do
with my putting a pause on an uncoordinated major packaging change?

Please elaborate. I would genuinely want to understand how you reach
that position. Is it my choice of using CDBS or my use of the BTS or
something else that you find a clear indication of me being antisocial?

Why Detiste? Because he has intimate knowledge on the Noto font
packaging, or...?

 - Jonas

Hi,

I m on VAC till Sunday and my phone data plan is depleted so I ll try to
keep short.(PS: I failed)


There were fears about one year ago that I broke the udeb's generation by
changes done in CDBS. Since then I had been validating changes in CDBS by
running debdiff and diffoscope on the result of rebuilding fonts-noto and
other.

I was happy to see Manuel's MR that would had allowed me to have all of
this further behind me.

I was very tempted to cherry pick from his MR only the CDBS -> DH bits and
revert the web package until next week.

I felt that doing that would had been disrepectfull of Manuel's work on my
part, and I saw no one complaining on the bug report.

What's the tipping point: we now have a NEW queue that works correctly.

~

Manuel could fork src:fonts-noto to build his webfont package but that
seems a very technicaly bad "legal" solution and I hope everyone will find
a better consensus.

~

I agree this package is just _too_ big (for Salsa CI for example) and the
plan to switch to newer/smaller splitted upstream releases seems better.
But I have a very shallow knowledge of this package and don't know the
orthogonality with the webfonts and udeb package... I m curious of the
outcome and will keep up reading but I guess I won't have anything more
valuable to contribute.




Greetings

Alexandre

On Wednesday, April 29, 2026 10:27:43 PM Mountain Standard Time Jonas Smedegaard wrote:
do.

I am sorry that this change has generated a lot of anger and bad feelings.  It
was certainly never my intention when submitting this request.  I genuinely
don’t understand what the bigger issues are that have been triggered, but I
would like to understand them so that everyone can reach an amicable
resolution.  As I understand it, the change that adds the WOFF2 fonts and
originally closed this bug report also made some changes from CDBS to DH.

Based on the email communications, I can imagine three possible concerns:

1.  Shipping some of the fonts as WOFF2 without shipping all of them.
2.  Converting the build system from CDBS to DH.
3.  Communicating on an MR instead of the BTS.

There are possibly other concerns that I have not picked up on.

Jonas, do all of the above concern you, or just some of them?

I am really hoping that we can find a way forward on the WOFF2 issue, so that
I can stop shipping fonts inside of the redmine package.  From a personal
perspective, I don’t have a strong position on the other issues and would hope
that we can do whatever accords with your wishes as the package maintainer.

We believe that the bug you reported is fixed in the latest version of
fonts-noto, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1116004@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Smedegaard <dr@jones.dk> (supplier of updated fonts-noto package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 14 May 2026 07:29:18 +0200
Source: fonts-noto
Architecture: source
Version: 20201225-6
Distribution: unstable
Urgency: medium
Maintainer: Jonas Smedegaard <dr@jones.dk>
Changed-By: Jonas Smedegaard <dr@jones.dk>
Closes: 1116004
Changes:
 fonts-noto (20201225-6) unstable; urgency=medium
 .
   * Friendly takeover,
     confirmed by all active maintainers of the package;
     add myself as uploader; update Vcs-* fields
   * drop binary package fonts-noto-web; closes: bug#1116004
Checksums-Sha1:
 1d6e5b5ea217fc357bf38fc5719e7c36af3fe154 2699 fonts-noto_20201225-6.dsc
 12708bed469ae8cbc7a030c335a62b39b14c2e80 111020 fonts-noto_20201225-6.debian.tar.xz
 38aae6faeb1f8fa54c18de62abb7998d6e3e6608 8824 fonts-noto_20201225-6_amd64.buildinfo
Checksums-Sha256:
 df8a81f0d6fd5740c8a7f11f2d6241d0b3b1ca19a2b3c9d4705a01350b1adf78 2699 fonts-noto_20201225-6.dsc
 589476694940ec77f62d9d9377df878e7090b404652429823fa45085b053c650 111020 fonts-noto_20201225-6.debian.tar.xz
 67ae15ff5fd11771b571976f935dc8eb6fa8b6522fdc7f2ec27ab67244716ed5 8824 fonts-noto_20201225-6_amd64.buildinfo
Files:
 80d9404e4bcd4bc6b7f49e999ac27ad7 2699 fonts optional fonts-noto_20201225-6.dsc
 16c41598b471014e7e77e186b136d972 111020 fonts optional fonts-noto_20201225-6.debian.tar.xz
 eb6557847d5d8c539baea1087cfc747b 8824 fonts optional fonts-noto_20201225-6_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmoFX9oMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhWkIP/RqEC6eVoETRC3wnVmDaEAub2O+TL/v8IUnWvTu9
PLJ3P5WZGwZ4nCJEXn0Q++PPIYVAVk9r26exfcVp5qw8JpQy6iRE1FhHarwjbHOy
6mxwpDdO64MMppSC9UhzLReNV2eXbp+4k5RwSxl4Ogew6MohZ3kmHxln/e8LB9WP
ObzrLY18ZnyBCxaGilhDXa0OBZk1XSTwoDEvJFJWfQsl4IiFvCTZ6TuR5w8+3SFq
IgNQkTx0uc0Mk9YKykzI5As2uyxDxBkkpkgszVllNj1Kf89EjOZSBZGEYkkNvUBP
LTAuIhpaUf0NcqI87jjxE5O9mO6PkEvqNU4Jr2Qax0nUYFhd2fDCvO26nXiCCa5v
lKXmanJYoTCTBTVOkHzVB+ys1z4wxCxC+X0CRtnPhH7EupLfmezdxvq4rOOvd/5M
drdKnI41HwCVF/Zxef0rZPMnyJlIPy9tJlTUTkdLNUXiGc0ch5mxzk1Zv1f+Ng7e
VrOYsVmyllN+l86ksmJH1Cl4h7fZsJ6svj0gjtwPm7mFNXjS1+34OWitOZYJLI3z
lnI5iMtpP6F515glhLnVFfpmPRaeNP4ziD1fZx6yRDv/KnTtHLeDUKei8WQkcUUj
CFz6xJIKG+AU7gBv7MWWG43oA5QmO5FqhnilonVhCaN2fUkkyU0FzUgKe4aA6GEN
x8LR
=tXuT
-----END PGP SIGNATURE-----

Jonas,

Is there a way we can ship the .woff2 versions of these fonts?

Hi Soren,

Quoting Soren Stoutner (2026-05-14 19:04:29)

I see several ways:

 a) have redmine build-depend on fonts-noto and a compressor,
    and compress during build
 b) have redmine depend on fonts-noto and a compressor,
    and compress during install
 c) introduce new source package src:fonts-noto-web that
    build-depends on fonts-noto and a compressor
    and compresses during build,
    and then have redmine depend on fonts-noto-web
 d) introduce new source package src:webfonts-common
    which offers a hook for packages to request compression of fonts,
    and have redmine depend on and provide hook for webfonts-common
 e) convince maintainers of javascript-common to implement a hook
    for compressing fonts,
    and have redmine depend on and provide hook for webfonts-common
 f) convince maintainers of fonts-noto to build-depend on a compressor
    and extend the package with webfont-support,
    and have redmine depend on that

 - Jonas

It seems to me that the way this is generally handled in Debian is (f), which
is to have the fonts-noto source package compress and ship the woff2 fonts.

In some cases they use a separate package called -web or something similar.

https://tracker.debian.org/pkg/fonts-dejavu
https://tracker.debian.org/pkg/fonts-atkinson-hyperlegible
https://tracker.debian.org/pkg/fonts-tlwg

In other cases, they ship the woff2 fonts in a binary package that includes
other font formats.

https://tracker.debian.org/pkg/fonts-materialdesignicons-webfont

Is this something you would consider as the maintainer of the fonts-noto
package?

Quoting Soren Stoutner (2026-05-15 18:52:10)

How did you reach that conclusion?

Here is a quick'n'dirty count:

jonas@cairon:~$ apt-file search -l .woff2 | grep -c .
858
jonas@cairon:~$ apt-file search -l .woff2 | grep -c ^fonts-
35

What am I missing?

 - Jonas

Those are exactly the types of bugs I am attempting to fix.  Specifically,
those trigger the following 2 lintian tags:

https://udd.debian.org/lintian-tag/font-in-non-font-package

https://udd.debian.org/lintian-tag/font-outside-font-dir

You can see how those affect redmine:

https://udd.debian.org/lintian/?
email1=&email2=&email3=&packages=redmine&ignpackages=&format=html<_error=on<_warning=on<_information=on&lintian_tag=#all

As you noted, .WOFF2 fonts are particularly affected by this (858 times),
because a lot of upstream packages ship them in their tarballs, especially web
applications.  The purpose of this bug report is to handle this in a more
Debian-appropriate way for noto by shipping the .WOFF2 fonts in a font package
and then linking to them from the web application.

Quoting Soren Stoutner (2026-05-26 01:52:39)

Sorry, I lost you there.

You state Debian use a specific approach, and I ask you how you
conclude that. I still don't read from this follow-up an elaboration on
that.

Do you mean to say that you agree that Debian currently package WOFF2
fonts in each binary package that needs them, and that you instead
*envision* a different approach?

Earlier, you asked how it could be done. It seems you don't care how it
can be done, you already know how you want it done and only care to
discuss that. I am not really excited to engage in that type of
conversation, and hope that I am mistaken about that impression of your
conversation scope here.

 - Jonas

It seems we have been suffering from a lack of communication, which isn’t my
intention.  Let me try to describe the problem from the beginning in a way
that I hope will be more helpful.

I believe it is the general consensus in Debian that fonts should only be
packaged by font packages and that these fonts should be installed inside
/usr/share/fonts/.

This general consensus is expressed in the following two lintian tags:

https://udd.debian.org/lintian-tag/font-in-non-font-package
https://udd.debian.org/lintian-tag/font-outside-font-dir

Upstream programs are often packaged with embedded fonts, particularly web
application.  Sometimes these have slipped into the Debian packaging instead
of properly being remove and simlinked to the appropriate Debian font package.
Debian contains a number of such packages with inappropriate embedded fonts,
some of which have existed in the archive for quite a long time.  Redmine is
such a package.  Since taking over maintenance of the redmine package, I am
attempting to clean up these packaging bugs.

I do not think that all font packages need to ship .WOFF2 variants.  I
maintain the fonts-adobe-sourcesans3 package, wich doesn’t ship .WOFF2 fonts
because there aren’t currently any package in Debian that would consume them.
However, if a package were to start needed them, and a bug was filed against
fonts-adobe-sourcesans3 request that I ship the .WOFF2 fonts, I would be happy
to do so.

Looking at how this is handled by other font packages, sometimes they ship the
.WOFF2 fonts in a separate binary package (sometimes named -web).  In other
instances they ship them in the same binary package as the other fonts.
Either seems appropriate depending on the size of the font packages and the
maintainer’s preference.

My request is that you ship these fonts as part of the fonts-noto source
package, either in one of the existing binary packages or in a new binary
package.  I genuinely do not understand why there would be any opposition to
doing so.

Quoting Soren Stoutner (2026-05-26 20:00:58)

The above lintian tags are both about system fonts, not recompressions
of fonts targeted web browsers.

I am unaware of any consensus in Debian on how to handle recompression
of fonts for targeting web browsers. The optimal likely involves
subsetting to only include glyphs relevant for the scope of the web
application.

You asked for possibilities, I provided you are list of possibilities
which you then ignored, and insist on the one approach that you try to
frame as already common in Debian. I fail to recognize that to be the
established common approach, and I dislike you framing me as being the
weird stubborn outsider here.

 - Jonas

my

Both of these tags flag against the WOFF2 fonts embedded in Redmine.

https://udd.debian.org/lintian/?
email1=&email2=&email3=&packages=redmine&ignpackages=&format=html<_error=on<_warning=on<_information=on&lintian_tag=#all
instead
fonts
against
to

Perhaps I am incorrect about there being a consensus on this topic.  Would you
prefer if I asked on the Debian Fonts mailing list?

I am not trying to frame you as being a stubborn outsider here.  I am just
trying to discuss my understanding of how these scenarios are typically
handled in Debian.

Quoting Soren Stoutner (2026-05-26 21:33:51)

Right.

I am not interested in discussing only *your* understanding, omitting
other views or ideas or proposals.

 - Jonas.

On Tuesday, May 26, 2026 2:39:50 PM Mountain Standard Time Jonas Smedegaard wrote:
Smedegaard

Can you provide any information that the other ways you proposed dealing with
the situation are the consensus for how WOFF2 fonts should be packaged in
Debian?

I have a question for the Debian Fonts mailing list regarding the correct way
to package WOFF2 (or WOFF or other web font formats).  As background, a number
of applications in Debian include fonts as part of their upstream tarballs.
Generally, it is considered best to remove these fonts from the Debian
packages and depend instead on the appropriate Debian font package.  In the
case of web applications, in recent years the use of WOFF and WOFF2 fonts have
become common.  WOFF and WOFF2 are compressed versions of TTF and OTF fonts.
There are a number of tools in Debian that can perform these conversions, like
woff2_compress or sfnt2woff-zopfli.

There are a number of fonts packages in Debian that already ship WOFF or WOFF2
fonts.  Sometimes they do this in separate binary packages (offen suffixed by
-web) and other times they do this in the same binary package that ships the 
TTF and OTF fonts.  For example:

https://tracker.debian.org/pkg/fonts-dejavu
https://tracker.debian.org/pkg/fonts-atkinson-hyperlegible
https://tracker.debian.org/pkg/fonts-tlwg
https://tracker.debian.org/pkg/fonts-materialdesignicons-webfont

I maintain the redmine package, which is a web application that ships several
WOFF2 versions of NotoSans in the upstream tarball.

I filed #1116004 requesting that fonts-noto start shipping WOFF2 versions of
their fonts so I could stop shipping them in redmine.  The bug report went
unanswered for a while until a DM named Manuel Guerra prepared an MR that
added a new binary package named fonts-noto-web.  This MR was posted to the
bug report, at which point one of the maintainers of fonts-noto, Jonas
Smedegaard, responded to the bug report suggesting one of the utilities for
converting TTF to WOFF2.  Alexandre Detiste reviewed Manuel Guerra’s MR and
sponsored it as a team upload.

After the upload, Jonas Smedegaard objected to the changes, reverting them
entirely with the next upload.  I believe this was the first time than anyone
involved had any indication that he was displeased in any way with what was
being done.  The core of his objection appears to be that he thinks some other
package should produce the WOFF2 fonts instead of fonts-noto.  He expresses
this here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116004#95

My understanding is that there is a consensus in Debian that fonts should
generally be shipped only by font packages, and that those fonts should be
installed under /usr/share/fonts/.  This is reflected in the following lintain
tags:

https://udd.debian.org/lintian-tag/font-in-non-font-package
https://udd.debian.org/lintian-tag/font-outside-font-dir

Jonas’ opinion is that this only applies to font formats like TTF and OTF, not
WOFF and WOFF2, even though these two lintian tags flag against the WOFF2
fonts in redmine.

https://udd.debian.org/lintian/?
email1=&email2=&email3=&packages=redmine&ignpackages=&format=html<_error=on<_warning=on<_information=on&lintian_tag=#all

My questions for the mailing list are these:

1.  Is there a general consensus in Debian that WOFF2 and other web fonts
should be shipped by font packages (when there is a need for them) and that
they should be installed under /usr/share/fonts/?

2.  If not, what is the recommended way for these fonts to be packaged?

Quoting Soren Stoutner (2026-06-10 01:41:45)

If you seek a general consensus in Debian, then it seems more sensible
to me to raise the question in Debian generally, rather than within a
team context.

That said, I find it sensible to raise it in the team, just wanted to
point out that limited scope of discussion implies limited range of
replies.

 - Jonas

Am 2026-06-10 01:41, schrieb Soren Stoutner:

In the font packages that I maintain, I generally keep the web fonts in
the same package as the TTF/OTF variants, but keep them out of the
/usr/share/fonts name space. The reason is that (1) they are duplicates
anyway and (2) fontconfig may pick them up as valid candidates for font
rendering but they will mostly fail to get rendered. (I think their
headers look like regular TTF fonts, but their actual content is
compressed).

I'd recommend as above.

Cheers,

  - Fabian

1.  Where do you place them?  I see some examples of /usr/share/custom-font-
directory/.

https://packages.debian.org/sid/all/fonts-atkinson-hyperlegible-web/filelist

2.  Is anyone aware of any problems caused by the packages that do place them
in /usr/share/fonts/WOFF/ or /usr/share/fonts/WOFF2/?

https://packages.debian.org/sid/all/fonts-dejavu-web/filelist
https://packages.debian.org/sid/all/fonts-thai-tlwg-web/filelist


Here is an example of a package that does both.  I am not sure what the
purpose of that is:

https://packages.debian.org/sid/all/fonts-materialdesignicons-webfont/filelist

-------- Ursprüngliche Nachricht --------Von: Soren Stoutner <soren@debian.org> Datum: 11.06.26  18:04  (GMT+01:00) An: 1116004@bugs.debian.org, Debian Fonts <debian-fonts@lists.debian.org> Betreff: Re: Bug#1116004: fonts-noto: fonts-noto-web is wrong On Wednesday, June 10, 2026 12:39:36 AM Mountain Standard Time fabian@greffrath.com wrote:> Am 2026-06-10 01:41, schrieb Soren Stoutner:> > 1.  Is there a general consensus in Debian that WOFF2 and other web> > fonts> > should be shipped by font packages (when there is a need for them) and> > that> > they should be installed under /usr/share/fonts/?> > In the font packages that I maintain, I generally keep the web fonts in> the same package as the TTF/OTF variants, but keep them out of the> /usr/share/fonts name space. The reason is that (1) they are duplicates> anyway and (2) fontconfig may pick them up as valid candidates for font> rendering but they will mostly fail to get rendered. (I think their> headers look like regular TTF fonts, but their actual content is> compressed).1.  Where do you place them?  I see some examples of /usr/share/custom-font-directory/.https://packages.debian.org/sid/all/fonts-atkinson-hyperlegible-web/filelist2.  Is anyone aware of any problems caused by the packages that do place them in /usr/share/fonts/WOFF/ or /usr/share/fonts/WOFF2/?https://packages.debian.org/sid/all/fonts-dejavu-web/filelisthttps://packages.debian.org/sid/all/fonts-thai-tlwg-web/filelistHere is an example of a package that does both.  I am not sure what the purpose of that is:https://packages.debian.org/sid/all/fonts-materialdesignicons-webfont/filelist-- Soren Stoutnersoren@debian.org

-------- Ursprüngliche Nachricht --------Von: Soren Stoutner <soren@debian.org> Datum: 11.06.26  18:04  (GMT+01:00) An: 1116004@bugs.debian.org, Debian Fonts <debian-fonts@lists.debian.org> Betreff: Re: Bug#1116004: fonts-noto: fonts-noto-web is wrong On Wednesday, June 10, 2026 12:39:36 AM Mountain Standard Time fabian@greffrath.com wrote:> Am 2026-06-10 01:41, schrieb Soren Stoutner:> > 1.  Is there a general consensus in Debian that WOFF2 and other web> > fonts> > should be shipped by font packages (when there is a need for them) and> > that> > they should be installed under /usr/share/fonts/?> > In the font packages that I maintain, I generally keep the web fonts in> the same package as the TTF/OTF variants, but keep them out of the> /usr/share/fonts name space. The reason is that (1) they are duplicates> anyway and (2) fontconfig may pick them up as valid candidates for font> rendering but they will mostly fail to get rendered. (I think their> headers look like regular TTF fonts, but their actual content is> compressed).1.  Where do you place them?  I see some examples of /usr/share/custom-font-directory/.https://packages.debian.org/sid/all/fonts-atkinson-hyperlegible-web/filelist2.  Is anyone aware of any problems caused by the packages that do place them in /usr/share/fonts/WOFF/ or /usr/share/fonts/WOFF2/?https://packages.debian.org/sid/all/fonts-dejavu-web/filelisthttps://packages.debian.org/sid/all/fonts-thai-tlwg-web/filelistHere is an example of a package that does both.  I am not sure what the purpose of that is:https://packages.debian.org/sid/all/fonts-materialdesignicons-webfont/filelist-- Soren Stoutnersoren@debian.org

themin

That is an informative bug report.  The upstream conversation indicates it
still isn’t resolved.

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/work_items/92

Based on that, I think Debian should consider it a bug for WOFF or WOFF2 fonts
to be installed under /usr/share/fonts/.

It appears that the convention currently used by several packages is:

/usr/share/fonts-fontname/woff/
/usr/share/fonts-fontname/woff2/

Does anyone have any objections if we standardize that as a policy
recommendation and update the lintian tests to match?

-------- Ursprüngliche Nachricht --------Von: Soren Stoutner <soren@debian.org> Datum: 11.06.26  22:22  (GMT+01:00) An: 1116004@bugs.debian.org, Debian Fonts <debian-fonts@lists.debian.org> Betreff: Re: Bug#1116004: fonts-noto: fonts-noto-web is wrong On Thursday, June 11, 2026 1:05:20 PM Mountain Standard Time Fabian Greffrath wrote:> > Is anyone aware of any problems caused by the packages that do place themin> > /usr/share/fonts/WOFF/ or> > /usr/share/fonts/WOFF2/?> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=8> > 63835This refers to Xetex, but may apply to other applications as well.  -That is an informative bug report.  The upstream conversation indicates it still isn’t resolved.https://gitlab.freedesktop.org/fontconfig/fontconfig/-/work_items/92Based on that, I think Debian should consider it a bug for WOFF or WOFF2 fonts to be installed under /usr/share/fonts/.It appears that the convention currently used by several packages is:/usr/share/fonts-fontname/woff//usr/share/fonts-fontname/woff2/Does anyone have any objections if we standardize that as a policy recommendation and update the lintian tests to match?-- Soren Stoutnersoren@debian.org

I apologize for the delay in preparing the documentation.  A number of fires
erupted in the past weeks that needed my attention.  Below is a link to a wiki
edit that I think captures the consensus of how WOFF/WOFF2 fonts should be
handled in Debian.

https://wiki.debian.org/Fonts/PackagingPolicy?action=diff&rev2=47&rev1=45

The highlights of this policy are:

1.  Fonts (including WOFF/WOFF2) should be shipped in font packages.
2.  WOFF/WOFF2 fonts should be shipped in /usr/share/fonts-fontname/WOFF and
/usr/share/fonts-fontname/WOFF2.
3.  Not all fonts packages need to ship WOFF/WOFF2 fonts, but if a package in
Debian needs them, a bug report can be opened requesting they be shipped.
Either the woff2 or the sfnt2woff-zopfli utilities can be used to create the
WOFF/WOFF2 fonts from TTF at package time, and the font package maintainer can
choose whether to ship them in the main font binary package or in a separate
binary package.

Please let me know if there are any objections to these policies or if you
feel that any of the wording in the wiki needs to be adjusted to better
represent what is desired.  Jonas, I would be particularly interested in your
feedback as I want to make sure that you are OK with what is decided.

Hi Soren,

Am 2026-08-25 00:16, schrieb Soren Stoutner:

I'd be fine with these changes, thanks!

  - Fabian

I have opened a lintian MR to update the text of the font-in-non-font-package
tag.

https://salsa.debian.org/lintian/lintian/-/merge_requests/809

On Monday, September 14, 2026 3:37:58 PM Mountain Standard Time Soren Stoutner wrote:
package

I have opened a second MR to create a woff-font-in-wrong-dir tag.  Once this
is merged, this should complete the process of updating the policy
documentation and lintian to reflect what has been decided in this thread.

https://salsa.debian.org/lintian/lintian/-/merge_requests/810

Thank you!

How about font files in eot format? This is also a web format, though a
hopelessly outdated. I'd say we shouldn't ship these files at all, but
if we do, we should store them outside of fontconfig's reach.

  - Fabian

That is a good question.  It looks like Gimp is shipping some of these fonts
in a custom directory.  This is just the first 100 results, so it doesn’t give
a full idea of what is happening in the repository.

https://packages.debian.org/search?
searchon=contents&keywords=.eot&mode=path&suite=unstable&arch=any

The current font-in-non-font-package lintian check looks for EOT fonts, so
when I updated that tag description I added information about it to match what
is the check was already doing.

https://salsa.debian.org/lintian/lintian/-/merge_requests/809/diffs

The current logic of the font-outside-font-dir will flag on EOT fonts if the
are not under /usr/share/fonts.

https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/
Fonts.pm?ref_type=heads#L89

The description of the tag does not mention EOT fonts.

"This package contains a TrueType, OpenType, or Type 1 fonts, but the package
does not install this file under /usr/share/fonts/.”

https://lintian.debian.org/tags/font-outside-font-dir.html

I could see this leading to a scenario where someone moves an EOT font under
/usr/share/fonts because of the lintian tag, thus causing problems with
fontconfig.

We could probably handle this two ways.

1)  Change the logic of the lintian check to not flag EOT fonts except for the
font-in-non-font-package tag.  This would leave it up to package maintainer to
choose where it should be placed and is is a good idea if these fonts will all
eventually be removed from Debian.

2)  Create a new eot-font-in-wrong-dir tag.  For this, we would need to make a
decision as a project where these fonts should be placed (possibly /usr/share/
font-fontname/eot) and update the wiki with that information.  This would make
sense under the assumption that we are going to keep shipping EOT fonts for
the foreseeable future.

Hi Soren,

files in EOT-format are hopelessly obsolete. IIRC they were only
compatible with Internet Explorer (not even Edge)!

I don't think Debian package should ship them at all, but I wouldn't
care if they need to be included for some odd reason (haven't checked
the GIMP case, for example). I would consider them entirely private to
the package that contains them, like other stuff in e.g.
/usr/share/<package>. Thus, I see no reason to factor them out into a
fonts-eot-<package> package. Let's not encourage that, please.

We should, however, take care to keep them out of the /usr/share/fonts
name space under any circumstances! This should be the only necessary
check in my opinion.

Thank you!

  - Fabian

It turns out there are a lot more EOT fonts being shipped in Debian than I
assumed.  Attached is a list with 1436 entries.  Most of these are shipped in
private locations, many of them as part of documentation.  However, the
following packages ship them under /usr/share/fonts:

fonts-font-awesome-legacy
fonts-fork-awesome
fonts-material-design-icons-iconfont
fonts-materialdesignicons-webfont
fonts-roboto-fontface

Perhaps it would be best to update the wiki to state that EOT fonts should be
shipped in /usr/share/font-fontname/eot.  The new woff-font-in-wrong-dir tag
could be renamed web-font-in-wrong-dir.

Quoting Soren Stoutner (2026-09-21 23:10:52)
team to establish a common place to an (ever) obsolete technology.

 - Jonas

Possibly.  However, seeing as how there are 1436 instances of these fonts
being shipped in Debian, we should probably coordinate with those package
maintainers before doing something like that.  You might want to start by
joining the discussion at:

https://lists.debian.org/debian-fonts/2026/09/msg00220.html

A lot of these fonts are being shipped as part of documentation packages.  It
is unclear to me how essential they are to that documentation, but I would
image that before an effort is made to completely remove them from Debian we
probably want to have a larger discussion on debian-devel.

Le mar. 22 sept. 2026 à 06:59, Soren Stoutner <soren@debian.org> a écrit :


Done

A lot of these fonts are being shipped as part of documentation packages.

EOT is an old web format that targeted IE <= 8.
It was never a source format. The font was in TTF and was converted to EOT
for IE8 support.

We should keep the ability to convert from EOT (just in case).

I would be very much surprised if those EOT files were still useful in any
way.
It would be a very good idea to get rid of them.

Looking at one example from the gimp-help-en package, it ships:

gimp-help-en: /usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-
regular.eot
gimp-help-en: /usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-
regular.svg
gimp-help-en: /usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-
regular.ttf
gimp-help-en: /usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-
regular.woff
gimp-help-en: /usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-
regular.woff2

My guess is that upstream ships these binary fonts, and the Debian package
just goes along with it.  These accompany HTML files that are used for
documentation.

https://salsa.debian.org/gnome-team/extras/gimp-help/-/tree/debian/latest/
images/common/fonts?ref_type=heads

The first problem here is that this package shouldn’t ship this font at all
because the source package does not contain the source code for the fonts and
it is not a font package.  Rather, the Debian package should remove these
fonts, depend on the fonts-open-sans package (assuming that is the same font),
and symlink to the fonts that are shipped by that package.

The second problem is that the fonts-open-sans package currently only ships
TTF versions of the font.  So, before the gimp-help-en package maintainer can
do that, the fonts-open-sans maintainer needs to start generating and shipping
WOFF and WOFF2 (and possibly SVG) versions of the font.

Without looking at the code, my guess is that the accompanying HTML files auto
select the font based on the browser’s capabilities.  If that is the case, the
EOT font is never actually called, because, to my knowledge, there is no HTML
rendering engine in Debian that can display EOT fonts.  So, this file could be
safely dropped from the Debian package.

Assuming that all of the above is true, perhaps we should create a lintian tag
informing package maintainers that ship EOT fonts that there is no purpose for
shipping an EOT font in Debian and it should be removed.

Am Montag, dem 21.09.2026 um 23:05 -0700 schrieb Soren Stoutner:

This is probably the best we can do, regardless of the directory these
fonts are installed into.

 - Fabian

Le mar. 22 sept. 2026 à 08:05, Soren Stoutner <soren@debian.org> a écrit :

Yes

The second problem is that the fonts-open-sans package currently only ships
svg < ttf < woff(2)
and Debian ships tools to convert in that direction.

Without looking at the code, my guess is that the accompanying HTML files

Yes.
Note also that GTK or QT HTML doc viewers are based on webkit, and webkit
doesn't support EOT files (even in its windows portage - really, EOT is a
IE8 thing).

Assuming that all of the above is true, perhaps we should create a lintian

Which level for the tag ? Warning ?

Jérémy

I think Warning would be appropriate.  Assuming nobody on this list objects to
recommending the removal of EOT fonts from Debian, we should probably post on
debian-devel asking if anyone is aware of any corner cases that we haven’t
thought of that justifies retaining them.  If there are no objections, we can
update the font policy (using the “should” verbiage, which correlates to a
lintian Warning).

https://wiki.debian.org/Fonts/PackagingPolicy

Then we can create a lintian tag named something like eot-fonts-should-not-be-
shipped (or a better name if someone can think of one) that explains why and
references the policy.  At the same time it would make sense to update the
check for font-in-non-font-package to not flag EOT fonts.

Quoting Soren Stoutner (2026-09-22 08:05:17)

Or the gimp-help-en package maintainer does whatever needed
subsetting/bundling/compression during install, as discussed in this
bugreport.

 - Jonas

I disagree.  It is inappropriate for the gimp-help-en package to ship a WOFF
or WOFF2 font because it does not contain the corresponding source.

Fonts should only be shipped by font packages which do contain the
corresponding source.

A recent effort has been made to clarify Debian policy regarding web fonts,
including WOFF/WOFF2 (Webb Open Font Format) and EOT (Embedded OpenType)
fonts.  This discussion mostly occurred on the debian-fonts mailing list, with
discussion about EOT fonts beginning at:

https://lists.debian.org/debian-fonts/2026/09/msg00193.html


TL;DR
-----

There appears to be no use for EOT fonts in Debian (Debian has no packages
that can display them, no modern browser on the web can display them).  It is
proposed that we create a lintian tag recommending that they not be shipped.
However, we would like to ask on debian-devel to make sure that there wouldn’t
be some unintended consequence we hadn’t considered.


Background
----------

It is common for web pages to include fonts, which are downloaded by browsers
so that the fonts can display as designed even if the user’s computer does not
have the font installed.  Because bandwidth is important for web applications,
efforts have been made to create compressed font formats for use on the web.
An early attempt at these were EOT (Embedded OpenType) fonts.  EOT fonts were
only ever supported by Internet Explorer 6-11.  They were never even supported
in Edge.

https://caniuse.com/eot

There are no rendering engines in Debian that have ever been able to display
EOT fonts, and no modern browser supports them.


Current Status in Debian
------------------------

Currently, there are 1436 EOT fonts shipped in Debian (see attached list,
which was generated by running `apt-file search .eot`).  There are two
problems with the current situation.

1.  In almost all of the cases, these fonts are being shipped in non-font
packages.  This typically happens because upstream packages binary copies of
these fonts in their repositories and they are just being passed along during
packaging.  This is a DFSG issue because these upstream repositories do not
contain the source code for these fonts.  The proper way to ship a web font is
in the font package that contains the corresponding source.  After the
TrueType font is built, a utility can be run to compress it into a WOFF/WOFF2
or EOT font.

2.  Currently, a lintian tag will flag if the EOT font is not placed under
/usr/share/fonts.  However, fontconfig has problems if compressed web fonts
are present in that directory.  We have recently updated the Debian Font
documentation and lintian tags to recommend that WOFF/WOFF2 fonts be placed
under /usr/share/font-fontname/woff and /usr/share/font-fontname/woff2
respectively.

https://wiki.debian.org/Fonts/PackagingPolicy

Something needs to be done so that lintian doesn’t recommend placing EOT fonts
in /usr/share/fonts.


Proposal
--------

In discussing how to modify the lintian checks relating to EOT fonts, it seems
wisest to us to just recommend their removal entirely from Debian (along with
the corresponding utility that can produce them from a TTF font).  There are
no programs in Debian of which we are aware that can display EOT fonts.  Many
of these fonts are contained in documentation packages.  For example, gimp-
help-en package ships:

/usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-regular.eot
/usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-regular.svg
/usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-regular.ttf
/usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-regular.woff
/usr/share/gimp/3.0/help/en/images/fonts/open-sans-v13-latin-regular.woff2

This documentation is meant to be displayed locally using an HTML engine
(libwebkitgtk).  The documentation code usually has fallbacks that check the
HTML engine’s capabilities and degrades from one version of the font to the
next until it finds one that can be supported.  There are a number of desktop
packages that ship the same documentation locally as is displayed on the web,
explaining why all of these fonts would be shipped by default even though, for
the desktop application, only one is really needed.

Seeing as how there is no benefit to shipping these EOT fonts, it felt foolish
for us to recommend that font package maintainers go through the effort of
shipping them, or to modify the lintian tags to create a recommended directory
for their location.  Instead, it just seems best to us that we create a
lintian tag recommending their removal.

However, before doing so we wanted to ask on debian-devel to make sure that
doing so wouldn’t create a problem that we hadn’t considered.

to be displayed with a specific font on embedded/IoT Windows clients
(e.g. some industrial barcode scanners/tablets), which appears to be
the only platform where IE is still supported.


It might also be useful to discuss this with upstreams, to
avoid/minimise changes in Debian packages.  E.g. I talked to some GIMP
people and they basically never thought about why they are still
shipping those fonts (I also filed an issue in their bug tracker as a
reminder).


PS: someone in the #gimp IRC channel mentioned that the same might
apply to the SVG fonts shipped with documentation, which might only be
there for ancient unsupported iOS web browsers?

That is a good point.  Looking over the list of EOT fonts attached to the
grandparent email, do you see any that you think might be targeting embedded/
IoT Windows clients?

I should say that many such devices run Android nowadays.

I don't know all of those packages, but anything that is only
documentation I wouldn't worry about removing EOT (and possibly SVG
fonts too).

ERP software like Tryton maybe?

In general, upstream for each package would be the best place to get an
answer, so maybe the policy (and maybe the linter) can suggest that?

On Saturday, October 10, 2026 10:38:38 AM Mountain Standard Time Jan Claeys wrote:

That’s a good point.

The problem with these EOT fonts in document packages is that they are DFSG-
non-free because they are not built from source (and these packages do not
even contain the source).  They are included as binary font files in upstream
tarballs and passed along during the packaging process.

The only DFSG-free way to ship an EOT font is in a font package, with the TTF
or OTF variant of the font being built from source and then compressed into an
EOT font using mkeot, which is part of the eot-utils package.  Jérémy Lal has
proposed removing eot-utils from Debian unless there ends up being some use
for EOT fonts we haven’t yet considered.

Yes.  If we decide to move forward with having lintian recommend removal of
EOT fonts, I would hope that package maintainers contact upstream to recommend
they be removed there.

Le jeu. 15 oct. 2026 à 19:49, Soren Stoutner <soren@debian.org> a écrit :

There will still be some tools, like node-webfont.
Also soon I'll upload node-svgtofont, which is a nice wrapper to recreate
fonts
out of a collection of svg icons (which is very popular).

EOT files from documentation”.

Probably nobody is going to read documentation for The GIMP or similar
on an appliance running embedded Windows, and in most cases (e.g. for
The GIMP) those font files are not really _needed_ to begin with, just
used for a “house style”, so text would still be readable without them.

On Thursday, October 15, 2026 1:50:39 PM Mountain Standard Time Jan Claeys wrote:

Gotcha.  I misunderstood what you meant.  I agree that I don’t forsee any
possible breaking with removing the EOT fonts from these packages.