Application Directory primitive bug?

[TiTou]

The Application Directory primitive is giving unexpected output when running inside of a LabVIEW compiled shared library on Linux (so file). I haven't check for LabVIEW built shared library on Windows.

Help says that when running in stand-alone app it should return the folder containing the app.
When running in a built shared library, it behaves differently, as it returns the path of the so file + relative path of calling VI to the application.

[TiTou]

Here's my proof :

I'm reporting this to NI

[TiTou · Accepted solution]

It took some time but I got a response from R&D via (tech support).

R&D's statement is :

it's expected (but not well documented), that the paths differ between Windows and Linux.

But that the behavior is not consistent for static/dynamic calls is not expected.

We filed Bug # 2699859 for this.

You can search for this number in the LabVIEW Release Notes of new versions to see if this bug was fixed.

[raphschru]

(Out of context) Out of curiosity, did you notice that your LabVIEW handles font very badly? (not very sharp and badly centered)

Is it specific to the Linux versions, or rather because you are using the (poorly implemented) zoom feature introduced in LV2023?

Being rather compulsive about "pixel perfect graphics", I find these kind of regressions quite frustrating 😬.

Regards,

Raphaël.

[Christina_R]

The root cause of the misaligned fonts on some Linux distributions is in the OTF version of Nimbus Sans. Replace this font with a metric-compatible alternative, such as the Type1 version of Nimbus Sans, any version of Liberation Sans, etc.

For example, Ubuntu 20.04 is installing both OTF and T1 variants of this font, allowing for the following workaround in ~/.config/fontconfig/fonts.conf 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <selectfont>
  <rejectfont>
   <glob>/usr/share/fonts/opentype/urw-base35/Nimbus*.otf</glob>
  </rejectfont>
 </selectfont>
</fontconfig>