Bad rendering of numbers with "nimbusSans regular" font

[Potomac]

Hello,

I use archlinux,

with the last version of gsfonts ( 20170829-1 ) I notice that numbers are bad rendered if the font "nimbus sans regular" is used, for example the string "2017", the "1" will be badly rendered,

if I use the previous version of gsfonts ( 20170727-1 ) then all is ok,

you can find a hmtl source code which shows this bug test_nimbus_sans_regular.zip

[deekej]

Hello @Potomac, I have a question about it. Where exactly (how?) did you get the 20170727-1 version of fonts? Because I'm not aware of a release for that date... The prior official release to 20170829 was urw-base35-20160926.zip.

Did you get the 20170829-1 as an Arch Linux package? Or did you build a package yourself from the git repository, based on specific commit?

Please, clarify. Thank you! :)

[Potomac]

Hello,

gsfonts-20170829-1 is an archlinux official package, you can find all the version of this package here :

https://archive.archlinux.org/packages/g/gsfonts/

the bug starts with the last package version called "gsfonts-20170829-1" ( release date for the package : september 16th 2017 ), with the previous version there is no bug, the font "nimbusSans regular" is correctly rendered

[Potomac]

you can see the changes between versions made by archlinux packagers here for the gsfonts package :

https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/gsfonts

[chris-liddell]

So, which version of the font are you using (Type 1, OTF, or TTF)? And can you post a screen shot of the problem?

[deekej]

Looking at the instructions on how to build the package (https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gsfonts), they are shipping the fonts in OTF format for Arch Linux.

And they are not using the official released fonts packages, but the current HEAD of the git repository. That would explain where @Potomac got the 20170727-1 version of his fonts package.

I will check what has changed between those commits, to see if this is actually a font change, or a fontconfig/AppStream issue.

[deekej]

Okay, so looking at this (if I understand the packaginf on Arch Linux correctly from my brief looking into it), this is what has changed for you between the version 20170727-1 and 20170829-1: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gsfonts&id=ee39c3ba75ebf8e34d9cdf3d9bd1eacef7e580f9

I can tell that the fonts version you're using is the same for both 20170727-1 and 20170829-1. The only thing that has changed for you is that Arch Linux is added (is now using) the fontconfig files with priority/ordering value of 69. This might have higher priority than some fonts you were using so far, and thus "hijacking" the fontconfig and using (URW)++ fonts somewhere where you wouldn't expect it.

Selecting the fontconfig ordering/priority value is solely in hands of each Linux distribution, and upstream here can't help you in this matter much. If the change is unbearable for you, I suggest you contact the Arch Linux's maintainer of gsfonts about this, or open a new bug report (if Arch Linux has some Bugzilla tool), and discuss this issue directly with the gsfonts maintainer for Arch Linux.

@chris-liddell, as mentioned above, this is not an issue of (URW)++ fonts nor the fontconfig files. My suggestion is to close this issue.

[Potomac]

here is some screenshots about the problem as attached files

you will see that the "1" in the string "2017" is not correctly rendered

[Potomac]

another screenshot, this time it's the number "4" and "1" which have rendering problems

[chris-liddell]

That's this problem: https://bugs.ghostscript.com/show_bug.cgi?id=697232

[deekej]

Okay, that's strange, because if this is a problem of the fonts itself, than the versions provides by @Potomac do not match... :-/ Sorry for the noise then.