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>

[gt_thetic]

I have tested this font solution on a Lubuntu Virtual Machine with LabVIEW Community Edition 2024 Q3 and 2025 Q3 and it has worked.

Thanks for this info.

[Taggart]

---

@Christina_R wrote:

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>

---

Christina, I tried this on RedHat 7.9 and it did not work. Is this solution Ubuntu specific? Is there a different recommended solution for RedHat?

thanks,
Sam

[elset191]

App Directory also returns the wrong path in a .rtexe on Linux
https://forums.ni.com/t5/LabVIEW/Application-Directory-in-RTEXE/m-p/4428391#M1305899

[gt_thetic]

Hi Sam,

I feel this is Ubuntu, and variants, specific, just with how files "local to the user profile" are handled.  I don't know exactly how to format the solution for a RedHat based distro, but the content that Christina pasted is verified against the Ubuntu manual (man pages).  I know that RedHat and CentOS have the Fonts Tweak Tool.  Maybe this link is a start:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/desktop_migration_and_admin...

I'll let Christina chime in with R&D knowledge.

[rtollert]

The only distribution-specific part of the workaround is the install path to the OTFs. All distributions use fontconfig, which can be user-overridden at uniform locations. I lost my CentOS 7 VM recently in a Proxmox-related mishap so unfortunately I can't just look this up terribly quickly.

Superficially, the Fonts Tweak Tool is only going to work if you are interested in substituting a metric-compatible font, as opposed to attempting to use the same font in a different form. The end result, a user-specific fontconfig file, will differ vs the posted .conf but will be materially a similar kind of thing. I can't guarantee that it will actually help.

I'm actually kind of a little surprised you're seeing this in RHEL 7. The last time I looked into this bug for RPM-based distributions specifically, the OTF variants of Nimbus weren't even getting installed by default for RHEL7, only for RHEL8 and later. One potentially viable workaround is perhaps to locate where the Nimbus Sans OTFs are getting installed, figure out which package is installing them, and see if you can just remove that...