wrong kerning in SS-5 PDF form fields

Thank you for your bug report, could you also report it upstream to the people writting the software on https://gitlab.gnome.org/GNOME/evince/issues ?

Done: https://gitlab.gnome.org/GNOME/evince/issues/1127

Should I also report the bug to the xpdf and Okular developers, since it is not isolated to Evince?

Status changed to 'Confirmed' because the bug affects multiple users.

Update: poppler issue here:

https://gitlab.freedesktop.org/poppler/poppler/issues/753

THanks!

Looking at `ss-5.pdf`, I saw the same rendering issue. The problem appears to be associated with font substitution. In particular, CourierStd is replaced with Ubuntu, which obviously won't render properly.


I was able to correct the issue by installing the `fonts-urw-base35` package and creating a file `~/.config/fontconfig/conf.d/10-pdf-aliases.conf` with the following contents:

    <?xml version="1.0"?>
    <!DOCTYPE fontconfig SYSTEM "/etc/fonts/conf.d/fonts.dtd">
    <fontconfig>

    <alias binding="same">
      <family>CourierStd</family>
      <accept>
      <family>Nimbus Mono PS</family>
      </accept>
    </alias>

    </fontconfig>

This problem can likely be fixed by adding font substitution rules to the appropriate font packages.

Thanks for the comment and details, unsure why it does pick Ubuntu font as an alternative to CourierStd and if that's a problem with the fonts or configuration

Gunnar do you have any clue maybe about the issue there or an opinion about the proposed config?

On 2020-10-26 10:33, Sebastien Bacher wrote:
> Gunnar do you have any clue maybe about the issue there or an
> opinion about the proposed config?

One thing I know is that no Ubuntu font is mentioned at all in the default fontconfig configuration, neither on Ubuntu nor Kubuntu.

But the dconf settings differ.

Ubuntu:

$ gsettings get org.gnome.desktop.interface font-name
'Ubuntu 11'
$ gsettings get org.gnome.desktop.interface monospace-font-name
'Ubuntu Mono 13'

Kubuntu:

$ gsettings get org.gnome.desktop.interface font-name
'Noto Sans, 10'
$ gsettings get org.gnome.desktop.interface monospace-font-name
'Monospace 11'

My gut feeling tells me that the comma in 'Noto Sans, 10' should not be there, and that it might cause confusion.

This is one thing I would try on Kubuntu:

gsettings set org.gnome.desktop.interface font-name 'Noto Sans 10'

However, while I checked this on my groovy installs, the bug reporter seems to be on Kubuntu 18.04. So things may be different there.

CourierStd is not defined in any of the config files at `/etc/fonts/conf.d`, so it falls back to sans-serif, not monospace. On my computer, the sans-serif fallback is set to Ubuntu.

In config files at `/etc/fonts/conf.d`, creating duplicate rules for "CourierStd" each time "Courier" or "Courier New" is mentioned should fix the problem.

On my computer, `grep -Rl Courier` lists the following files:

    30-metric-aliases.conf
    45-latin.conf
    60-latin.conf

Using `apt-file search`, the package those files belong to is `fontconfig-config`.

Right xiota, and I think adding CourierStd to 45-latin.conf is sufficient.

I could reproduce the problem on Ubuntu 20.10, so it's not a Kubuntu specific issue as I first suspected. Instead, just as you said, it's because CourierStd isn't currently mentioned anywhere in the config files.

Proposed fix attached as a debdiff.

The proposed patch might not fix the problem on all machines because not all monospace fonts have the same metrics as Courier. So it would be good to also add the following to 30-metric-aliases.conf:

   <alias binding="same">
     <family>CourierStd</family>
     <accept>
       <family>Nimbus Mono PS</family>
       <family>TeX Gyre Cursor</family>
       <family>Cousine</family>
       <family>Liberation Mono</family>
       <family>Cumberland</family>
       <family>Cumberland AMT</family>
     </accept>
   </alias>

On 2020-10-27 00:06, xiota wrote:
> not all monospace fonts have the same metrics as Courier

How important is that? Are you aware of any monospace font where it would still be messed up?

Since what I propose is an Ubuntu only patch, I would prefer to keep it as simple as possible. If someone (you?) would propose an upstream merge request

https://gitlab.freedesktop.org/fontconfig/fontconfig

the addition you would like to see would be more motivated IMO.

I just checked a few fonts. The fonts I thought might have problems are mostly fine. Only some consecutive capitals clash, like WWW.

Ubuntu Mono looks bad (too much space), but it's readable.

I'll submit a request at the fontconfig gitlab.

On 2020-10-27 02:32, xiota wrote:
> I just checked a few fonts. The fonts I thought might have problems are
> mostly fine. Only some consecutive capitals clash, like WWW.

I checked the PDF form with evince, and on Ubuntu CourierStd is replaced with "DejaVu Sans Mono" and on Kubuntu it's replaced with "Noto Sans Mono". In both cases that's the highest fontconfig priority for monospace as shown by this command:

fc-match monospace

I think we'd better assume a reasonable default, which both of those are.

> Ubuntu Mono looks bad (too much space), but it's readable.

How do you make it replace CourierStd with Ubuntu Mono? Do you have custom font configuration which affect it?

> I'll submit a request at the fontconfig gitlab.

Nice. :) Once that one reaches Ubuntu we will then be able to drop my patch.

The following config would be better than the one I proposed earlier:

    <alias binding="same">
      <family>CourierStd</family>
      <accept>
      <family>Courier</family>
      </accept>
    </alias>

    <alias>
      <family>CourierStd</family>
      <default><family>monospace</family></default>
    </alias>

I submitted a request to fontconfig:

    https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/262

-----

What one person considers sane isn't necessarily so.
*Assuming* sane defaults isn't really sensible.

Here are some examples, not directly related to the issue at hand:

  * In a "sane" configuration, we'd expect a list of monospace fonts
    when requesting the generic monospace font family. Similarly for
    the generic serif and sans-serif families. However, the following
    commands show that fonts of all three types are included in all of
    the generic families.

       fc-match -s monospace
       fc-match -s sans-serif
       fc-match -s serif

    Normally, it doesn't cause problems because fonts of the right
    type are at the beginning of the list. However, if a specific font
    is requested, an obviously incorrect substitution can be made
    (eg, sans-serif font shown when serif was requested) because fonts
    of all types are in all of the lists.

  Maybe developers in the past thought it was fine because some
  config further along could be assumed to have sane defaults?
  Or maybe they thought it was just a theoretical problem that
  wouldn't ever occur? But it's not just theoretical. I have
  encountered real issues, which is why I know of it at all.

  * Many people believe that if they request a font that isn't
    installed, Ubuntu will substitute a font it "thinks" looks
    similar. They don't realize that it has to be defined in the
    config files.

    So if they request a font that's not defined, like CourierStd,
    Ubuntu will fallback to sans-serif, even though every human
    immediately knows the Courier substitutions should be used –
    and that would be the sane default. But here, we're explicitly
    deciding *not* to, even knowing there is a theoretical risk of
    problematic substitutions in the future.

> How do you make it replace CourierStd with Ubuntu Mono?
> Do you have custom font configuration which affect it?

I created custom config files to define the fallback fonts after
having issues with strange fallback font selection a few years ago.
The problem is associated with the generic font families including
fonts of the wrong type (described in my previous comment #17).

Ok, I changed the Ubuntu patch in accordance with your suggestion. Maybe a bit better...

As regards your upstream issue, you probably increase the chances that it gets attention if you submit a merge request.

Thank you. I have done as you suggest. Upstream merge request is here:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/128

This bug was fixed in the package fontconfig - 2.13.1-4.2ubuntu2

---------------
fontconfig (2.13.1-4.2ubuntu2) hirsute; urgency=medium

  [ Gunnar Hjalmarsson ]
  * debian/patches/08_recognize_CourierStd_as_monospace.patch:
    - Recognize CourierStd as a monospace font (LP: #1824260)

 -- Łukasz 'sil2100' Zemczak <email address hidden> Mon, 02 Nov 2020 18:26:27 +0100

Status changed to 'Confirmed' because the bug affects multiple users.

Affects me using fully updated Ubuntu 20.04.4 LTS

I used the changes noted in your fontconfig merge request (applied to files in /etc/fonts/conf.avail/ 30-metric-aliases.conf and 45-latin.conf) and it cleared up kerning issues I was having with a different PDF form! Thanks Gunnar and xiota!