Cura: Fedora 26 Machine Settings Font Issue

Created on 19 Sep 2017  Â·  22Comments  Â·  Source: Ultimaker/Cura

I haven't seen any font issues anywhere except for the Start and End Gcode text boxes, the Gcode text is nothing but squares. I can copy contents to a text editor and read it, however...

machine settings_005

Uranium Linux Bug

Most helpful comment

Linux Mint 19.2 Cinnamon
Same problem, sudo apt purge fonts-powerline fixes the problem.

All 22 comments

It seems that it's trying to get a font that is not defined in the theme (called "fixed"). @fieldOfView Do you know what the point of that font was? Is it okay to switch it to default font?

The textareas use a monospaced ("fixed width") font, as is common when editing code.
The font is the system-default fixed width font:
https://github.com/Ultimaker/Uranium/blob/master/UM/Qt/Bindings/Theme.py#L240
I don't know why that would fail. This may be related:
https://bugzilla.redhat.com/show_bug.cgi?id=1330150

The interesting thing is I have Cura installed on another Fedora 26 laptop and the Gcode areas look fine...

Here are the messages I'm getting if I start Cura from a shell:

Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 80: saw unknown, expected number
Fontconfig warning: "/etc/fonts/conf.d/65-0-lohit-bengali.conf", line 32: unknown element "langset"
Fontconfig warning: "/etc/fonts/conf.d/69-gnu-free-sans.conf", line 24: unknown element "langset"
Fontconfig warning: "/etc/fonts/conf.d/69-gnu-free-serif.conf", line 24: unknown element "langset"
QObject::connect: Parentheses expected, signal MainWindow::
QObject::connect: Parentheses expected, signal MainWindow::
QObject::connect: Parentheses expected, signal MainWindow::
QObject::connect: Parentheses expected, signal MainWindow::
file:///tmp/.mount_FXM71A/usr/bin/resources/qml/JobSpecs.qml:160:13: QML TooltipArea: Binding loop detected for property "height"
qml: TableViewSelection: index out of range
qml: TableViewSelection: index out of range

Where is /tmp/.mount_FXM71A coming from?

I would think that is the temporary location the appimage is mounted to.
Only the first 6 entries in the snippet are exceptional, the rest happens on all platforms and is unrelated to fonts.

Oh, that's the appimage. Coudl you (@RodneyBrown) try with the Fedora RPM instead?

https://copr.fedorainfracloud.org/coprs/churchyard/cura-modern/

BTW /etc/fonts/conf.d/10-scale-bitmap-fonts.conf from F26:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

<!--
  If font is bitmap, calculate scale factor.
  Note that color bitmap fonts have scalable=true, while
  non-color ones have scalable=false.  Both groups have outline=false.
  -->
<match target="font">
  <test name="outline" compare="eq">
    <bool>false</bool>
  </test>
  <edit name="pixelsizefixupfactor" mode="assign">
    <divide>
      <name target="pattern">pixelsize</name>
      <name target="font"   >pixelsize</name>
    </divide>
  </edit>
</match>
<!--
  For non-scalable bitmap fonts (ie. non-color), skip
  minor scaling if hinting is enabled.
  -->
<match target="font">
  <test name="outline" compare="eq">
    <bool>false</bool>
  </test>
  <test name="scalable" compare="eq">
    <bool>false</bool>
  </test>
  <test name="hinting" compare="eq">
    <bool>true</bool>
  </test>
  <edit name="scalingnotneeded" mode="assign">
    <and>
      <less>
        <name>pixelsizefixupfactor</name>
        <double>1.2</double>
      </less>
      <more>
        <name>pixelsizefixupfactor</name>
        <double>0.8</double>
      </more>
    </and>
  </edit>
</match>
<match target="font">
  <test name="scalingnotneeded" compare="eq">
    <bool>true</bool>
  </test>
  <edit name="pixelsizefixupfactor" mode="assign">
    <double>1.0</double>
  </edit>
</match>
<!--
  If we *are* going to scale, go ahead and do it.
  -->
<match target="font">
  <test name="outline" compare="eq">
    <bool>false</bool>
  </test>
  <test name="pixelsizefixupfactor" compare="not_eq">
    <double>1.0</double>
  </test>
  <edit name="matrix" mode="assign">
    <times>
      <name>matrix</name>
      <matrix>
        <name>pixelsizefixupfactor</name> <double>0</double>
        <double>0</double> <name>pixelsizefixupfactor</name>
       </matrix>
    </times>
  </edit>
  <edit name="size" mode="assign">
    <divide>
      <name>size</name>
      <name>pixelsizefixupfactor</name>
    </divide>
  </edit>
</match>

</fontconfig>

Perhaps we could distribute a monospace font along, specifically for that area?

The whole idea is that it uses the monospace font specified by the system theme. Doesn't Fedora have a monospace font (I would find that quite strange)? Does this issue reproduce on all Fedora systems, or has @RodneyBrown inadvertently screwed up his font system?

Weird… I have the same issue on a Arch Linux box and I have of course Monospaced fonts installed.
I also got some Fontconfig errors and warnings on Startup.

> ./Cura-3.0.3.AppImage                                                                                                                                                  
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 80: saw unknown, expected number

The Cura version shipped with Arch Linux does not have this problem.

As it turns out (at least the reason of the messages) are covered here: https://bugs.freedesktop.org/show_bug.cgi?id=70258

That is most likely happens if applications links older fontconfig statically/dynamically.

Let me speculate:

The AppImage contains (almost) all Cura needs (including libfontconfig). But it relies on the fontconfig settings configured on the host system, which may be more recent and probably incompatible with the one included in the AppImage.

Hope that helps.

Sounds plausible. We don't explicitly package fontconfig but I don't know how AppImageKit does that sort of thing or how this is done in Qt. Do you know of a way in which we can let libfontconfig use Cura-supplied config settings?

@Ghostkeeper If I understand https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues#fonts-and-font-rendering correct you don't need to ship libfontconfig at all, as it is assumed to be available, but this assumes you dynamically link against an older version of libfontconfig. So on the host system you rely on their libfontconfig (which you assumed anyways)

But as I never done an AppImage for myself I actually don't know this works.

Same bug on Cura 3.4.1 and ubuntu 18.04 Very annoying.

Cura tries to use the system default fixed size font for start/end g-code. On my Xubuntu 18.04, that's DejaVu Sans (comes with package ttf-dejavu). On Fedora 26, I am not sure. Could you guys try installing "DejaVu Sans" for example just to see if it works? Thanks.

@LipuFei I installed ttf-dejavu fonts in my debian 9.5 but I still cannot read the text in that section

I had the same problem with the squares in the GCode window. The culprit was in the $HOME/.fonts folder.

I had the same problem with Cura 4.5.0 on Linux Mint 19.3 Cinnamon. The problem was with fonts-powerline installed via apt-get. Removed/purged it and installed Fontconfig (first option) following instructions from https://powerline.readthedocs.io/en/latest/installation/linux.html
Now Cura and Powerline are showing fonts normally.

Linux Mint 19.2 Cinnamon
Same problem, sudo apt purge fonts-powerline fixes the problem.

Had the same problem with 4.6.1 on fedora 31 the package name differs here:
sudo dnf remove powerline-fonts

Ok I can confirm too it works in ubuntu 18.04 and will follow instructions to use another install for fonts powerline (outside of apt with pip probably...)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

StanislavJochman picture StanislavJochman  Â·  3Comments

konvoj picture konvoj  Â·  3Comments

mnswamp1 picture mnswamp1  Â·  3Comments

wi1k1n picture wi1k1n  Â·  3Comments

probonopd picture probonopd  Â·  3Comments