Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures

[Markus Hitter]

Package: fonts-urw-base35
Version: 20200910-4
Severity: important
X-Debbugs-Cc: m...@merchantsedition.com

Dear Maintainer,

* What led up to the situation?

Installing and using font Nimbus Mono in a programming oriented text
editor.

* What exactly did you do (or not do) that was effective (or
ineffective)?

Type words which expose ligatures in font Nimbus Mono. For example
'office' or 'affected'. Verified in Gedit and Geany.

* What was the outcome of this action?

Several characters, like 'ffi' or 'ff', get squeezed into the width of
a single character. That's counterproductive, as the whole point of a
monospaced font is to use the same width for every character.

* What outcome did you expect instead?

Character sequences like 'ffi' to be three characters wide. Character
sequences like 'ff' to be two characters wide.

-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fonts-urw-base35 depends on:
ii xfonts-utils 1:7.7+6

fonts-urw-base35 recommends no packages.

Versions of packages fonts-urw-base35 suggests:
pn fonts-freefont-otf | fonts-freefont-ttf <none>
pn fonts-texgyre <none>

-- no debconf information

[fab...@greffrath.com]

Control: forwarded -1
https://github.com/ArtifexSoftware/urw-base35-fonts/issues/31
Control: tags -1 confirmed upstream

[fab...@greffrath.com]

Hi Markus,

could you please check if replacing the OTF versions of the fonts with
the TTF ones fixes the issue for you?

https://github.com/ArtifexSoftware/urw-base35-fonts/issues/31#issuecomment-1168348674

Thanks!

- Fabian

[Markus Hitter]

Fabian,

thanks for taking care of this and for looking up the upstream bug. I'm just not sure how using the TTF version of a font could fix the OTF version.

Looking at the discussion of the upstream bug it looks like these folks have not more knowledge about fonts than me, so I researched how these ligatures could be removed without having original source files. Lo and behold, it looks like I have found a way and fixed variant Regular already. Tomorrow I plan to apply the same procedure to the other variants, triple-check everything and then make a pull request upstream.

Markus

[Markus Hitter]

Bugfix provided in the upstream bug.

Now comes the hardest part: encouraging upstream maintainers to accept the bugfix. They usually feel alienated if some unknown idiot (me) comes along and solves a long standing issue quickly. Last time (bugfix for Gitk) I solved this by writing poems :-)

Markus

[Fabian Greffrath]

Am Donnerstag, dem 29.09.2022 um 18:06 +0200 schrieb Markus Hitter:
> Bugfix provided in the upstream bug.

I've seen that, thank you!

> Now comes the hardest part: encouraging upstream maintainers to
> accept the bugfix. They usually feel alienated if some unknown idiot
> (me) comes along and solves a long standing issue quickly. Last time

I think the underlying issue is that even Artifex isn't the actual
author of the fonts, but (URW)++. So, Artifex is bound to wait for
(URW)++ to provide for upstream fixes, and this takes longer and
longer. The problem with your patch is that it would have to go the
other way round, i.e. first to (URW)++ so that they can use it as a
base for theit further development. This case is very unlikely to
happen, though. :(

> (bugfix for Gitk) I solved this by writing poems :-)

Let's hope it helps this time as well. :D

Cheers,

- Fabian

[Markus Hitter]

Would you mind making a packaging patch? This would solve the problem at least for Debian (and Ubuntu) users, giving upstream as much time as they want or need.

[Fabian Greffrath]

HI Markus,

sorry, no chance! This has to be solved upstream, there will be no
isolated Debian/Ubuntu solution to this. This issue affects
Ghostscript, all PDF renderes, LaTeX, etc. across all distros. Thus,
you have already done the right thing by forwarding your solution to
upstream (or at least their distributor). It's up to them now.

You know, the reason why we ditched the gsfonts package in favor of
fonts-urw-base35 was that the former contained an unmaintained Debian-
specific fork of the fonts. Patching the fonts-urw-base35 package in
Debian would create the exact same situation again. ;)

Thanks anyway!

Cheers,

- Fabian

[Markus Hitter]

That's an odd reasoning. So you want to keep the bug, because removing it would solve the problem not only for one, but for many applications and thousands of users? For me, such a huge impact would encourage me even more (and was actually the reason why I filed a bug at all and spent 3 days to find not only a simple works-for-me fix, but the best possible solution I could find).

There is no reason to believe that upstream fixes this bug anytime soon (by applying the patch or some other way). Upstream bug is over a year old, with no attempts to solve it, not even a comment from the repo owner. Last commit to the upstream repository is almost a year old. URW++'s last contribution is over 5 years old. Clear signs of abandoned development.

Also, once upstream solved the problem, removing the packaging patch again is trivial. Even better, upstream might see next year that the fix works fine and commit it as 'proven working'.

I'm not surprised at all that Debian runs into unmaintained upstream software. That's simply how the software world works. Developers write some code, are happy with the result, then they move on to their next project. 5 years later this software is still useful, but original developers have long forgotten what they did back then. When a bug is found, they're just as clueless as anybody. Only few very big projects receive continued development for many years.

Debian's answer to this can't be to ignore known bugs in unmaintained projects. Or worse, drop their packages. Much better is to also maintain fixes. AFAIK, all major OS developers do this, Apple, Microsoft, Google, you name it. Debian's packaging patch mechanism is there for a reason, it should be used for the best experience of Debian users: bug-free software packages.

Markus

[fab...@greffrath.com]

Hi Markus,

Am 03.10.2022 23:43, schrieb Markus Hitter:
> That's an odd reasoning. So you want to keep the bug, because removing
> it would solve the problem not only for one, but for many applications
> and thousands of users? For me, such a huge impact would encourage me
> even more (and was actually the reason why I filed a bug at all and
> spent 3 days to find not only a simple works-for-me fix, but the best
> possible solution I could find).

of course I don't *want* to keep the bug open. It's just that I won't
apply a "Debian only" solution.

I won't package a different font than the one that Ghostscript uses.

This isn't just merely a bug fix in a program. As you stated yourself,
the sheer impact of this change is massive, as it affects how certain
documents are rendered. This needs a coordinated approach and you have
already done the best that could be done by posting a detailed solution
to the upstream bug tracker. Let's just hope it gets picked up, either
by URW++ themselves or by Artifex at least.

Thanks,

- Fabian

[James Cloos]

as a side note (i can't see the proposed patch, so ignore this if the
patch does this already), but do be sure not to remove the lig glyphs
from the fonts, but rather just any gsub (or the like) features which
replace char sequences with the ligs.

ie, anything which replaces f i with fi, etc, should go, but the fi glyph,
the mapping from U+FB01 to that glyph, and so on for the others, should
all remain.

-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6