AXIS displays coordinate font incorrectly when font package xorg-fonts-type1 is installed

[michaelweiner]

AXIS coordinate font broken

The coordiate font is not properly displayed under the circumstances described below.
I am not 100% sure if this is a LinuxCNC bug, or a bug in the font I have installed, or in the libraries that are used. However, AXIS is the only place where I have encountered this behavior, that is why I am reporting it here.

Here are the steps I follow to reproduce the issue:

1. (I assume that the LinuxCNC environment is already installed)
2. pacman -S xorg-fonts-type1
3. linuxcnc, then select any ini file that uses AXIS

This is what I expected to happen:

I would like to see the coordinates in a proper font.

This is what happened instead:

I see characters that usually appear when a font does not support certain Unicode characters.

Surprisingly, the font in the DRO tab is always displayed properly.

It worked properly before this:

When the Arch package xorg-fonts-type1 is not installed, the display works correct again, also with a Courier-like font.
Another workaround I found to work was to change the font from "courier" to, e.g., "FreeMono", in the source code of https://github.com/LinuxCNC/linuxcnc/blob/2.7/src/emc/usr_intf/axis/scripts/axis.py, in the function get_coordinate_font():

def get_coordinate_font(large):
    global coordinate_font
    global coordinate_linespace
    global coordinate_charwidth
    global fontbase

    if large:
        coordinate_font = "FreeMono bold 20"
    else:
        coordinate_font = "FreeMono bold 11"
    (...)

Information about my hardware and software:

My system:

$ lsb_release -a
LSB Version:	1.4
Distributor ID:	Arch
Description:	Arch Linux
Release:	rolling
Codename:	n/a
$ uname -a
Linux erde 5.3.8-arch1-1 #1 SMP PREEMPT @1572357769 x86_64 GNU/Linux

LinuxCNC: from AUR (https://aur.archlinux.org/packages/linuxcnc-sim/), version 2.7.14-2

Font package that causes the issue: xorg-fonts-type1-7.7-3 (https://www.archlinux.org/packages/extra/any/xorg-fonts-type1/)

[andypugh]

I am a little puzzled by the fact that changing the DRO font helps, as I thought that the graphical preview screen rendered that DRO using a pseudo-font called "Hershey".
https://github.com/LinuxCNC/linuxcnc/blob/0f91c553a238c3f5e8a52285044761c2dcfd7de5/lib/python/hershey.py
But perhaps that is only used for the numbers plotted on the axes inside the graphical preview?

How badly do you need xorg-fonts-type-1 ?

[michaelweiner]

As far as I understand, the font for the DRO tab is set in redraw_dro() (also in axis.py) whereas get_coordinate_font() is used for the coordinate display in the Preview tab.

Changing this function - or removing xorg-fonts-type-1 - worked for me -- but I unfortunately don't know about the "Hershey" font.

I don't need xorgs-fonts-type-1 badly, so for me it would be totally fine to close the issue. I had opened this ticket on the one hand as I was not sure whether the bug should be attributed to AXIS, and on the other hand to document my workaround to fix the issue.

[rene-dev]

I can reproduce the issue and fix on Ubuntu 20.04, but cant find any package that is causing this.

[rene-dev]

this is the problem: https://gitlab.gnome.org/GNOME/pango/issues/386
so we need to change to a different font, and find one that works on all systems.
@andypugh Hershey is only used on the 3D rendering, not the dro.

[EisbaerLars]

Same prob as @michaelweiner described here.
Is there a working work around which I could use?

[rene-dev]

@EisbaerLars the workaround from the first post works. I will update 2.8 with this fix.

[EisbaerLars]

@rene-dev Little confused what to do now - to change the font from "courier" to, e.g., "FreeMono" like described above I have to change the axis.py file in the 2.8 source code and build it new?

[rene-dev]

if you want a fix now, yes. If you dont want to build form source, you have to wait for a new release.

[EisbaerLars]

Thanks - found the axis file in usr/bin/
And it has the function in - guess I doesn't help to change it there?

[rene-dev]

yes, that also works as a workaround

[EisbaerLars]

Thx - just edited the file and will test tomorrow

[EisbaerLars]

Changing the font in the usr/bin/axis file worked - numbers in the preview screen inside 2.8.1 are back ;-)

[rene-dev]

Which os do you use?

[EisbaerLars]

Mint 20.4 with a 4.9.0-13-rt kernel
In LCNC 2.9 the issue didn't show

[andypugh]

This has just popped up again on the forum.
It seems like an easy fix in some ways. Is the difficulty in knowing of a font that will be present on every possible Linux version?

[EisbaerLars]

Why should it b difficult? Just use the font named above: FreeMono

[andypugh]

Why should it b difficult? Just use the font named above: FreeMono

Can you assure us with 100% confidence that FreeMono is present on all the officially supported platforms (which, incidentally, doesn't include Arch)
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions

[EisbaerLars]

No I can't, but if FreeMono is not available just try another font - the fix takes 10s to apply
For a common solution/font) inside LCNC I guess it must be tested with the 7 versions in your link - I am not a developer - but - assume this should be not an difficult operation either for the guys developing this high sophisticated software?

[andypugh]

We have a buildbot that compiles and runs tests on every software change on every supported platform. (This adds up to 20+ combinations of OS and realtime system: http://buildbot.linuxcnc.org/buildbot/buildslaves
However, it is hard to spot GUI problems as the tests run on a set of headless virtual machines and error out if an attempt to load an openGL GUI like Axis is made.
I am not saying that it is impossible, just that it is more difficult that making a change and saying "it runs fine here"
I could find a spare PC and install Ubuntu Precise and LinuxCNC, then test the change. But it would take a few hours, and would all be to find a possible fix for a problem that only seems to exist in Arch Linux.

[EisbaerLars]

I am not saying that it is impossible, just that it is more difficult that making a change and saying "it runs fine here"

Agreed

[rene-dev]

Its not an arch issue, mint 20 and ubuntu 20 have the same issue.

[rene-dev]

https://packages.debian.org/jessie/all/fonts-freefont-otf/filelist

[andypugh]

Is it simple to check that a font exists on the system? Perhaps a very simple addition to the runtests suite to check for the existence of, initially, FreeMono. Though ideally it would check for all fonts explicitly used.
That would be a fairly simple way to do the required check.

[rene-dev]

a quick way of checking:
fc-list | grep -i freemono.ttf

[andypugh]

fc-list | grep -i freemono.ttf

Appears to fail on the stock LinuxCNC Debian image.
That seems to suggest that this isn't a great fix

[andypugh]

Further testing shows that even if I use a font name that doesn't exist ("NotAFont") then Axis works just fine on Debian.

This is an Arch bug, in my opinion.

[rene-dev]

this is the problem: https://gitlab.gnome.org/GNOME/pango/issues/386

No, like I said Im also having this problem on ubuntu 20.04 see above quote for the reason why this is happening.

[andypugh]

OK. But it still looks like FreeMono might not be the right choice.
Though, "Helvetica" is called out in many places, and I don't see that in fc-list either.

[rene-dev]

https://packages.ubuntu.com/search?keywords=pango

https://packages.debian.org/search?keywords=pango

This is an issue on ubuntu 20.04, 20.10, and all debian releases after buster. We just need to find a font that works, and is available. We can also depend on a specific font package. This only showed up on arch, because arch ships new versions a lot quicker.

[rmu75]

"monospace" should be a reasonable alias pointing to some installed monospace font.

~$ fc-match monospace
B612Mono-Regular.ttf: "B612 Mono" "Regular"

[andypugh]

"monospace" works on Debian 10. And actually picks a nicer font than Courier.

[rene-dev]

If there are no objections, I will change all occurrences to monospace. I think this should go in master only.

[archidea00]

I have the same problem with the font in gmoccapy (Axis shows numbers correctly). Do you have any suggestion how to resolve the issue?

[rene-dev]

@archidea00 if you still have the problem in gmoccapy, please open a new issue with more details. many things have changed since.

[rene-dev]

changed to monospace in master.

[Tinoky]

Hi dear developers! I have the same problem after a local build of 2.9.0-pre0.
I have checked axis.py is well using monospace fonts.
I have settled all localization parameters of my computer to US (I'm currently in France) and this didn't solve the problem.

FYI, this same version of LinuxCNC was working perfectly when installed from a distribution CD, but since I need to build a personal HAL component, I have downloaded and rebuild from the source code, and since that, the display is broken as shown above.

I browsed for hours searching solution but without success.
Do you have any idea where can I found for help?
BR