Bug 5528 - Font path list is likely very out of date
Summary: Font path list is likely very out of date
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Agent (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Samuel Mannehed
URL:
Keywords: linma_tester, nikle_tester, prosaic
Depends on:
Blocks:
 
Reported: 2015-05-12 11:21 CEST by Samuel Mannehed
Modified: 2021-11-16 14:04 CET (History)
4 users (show)

See Also:
Acceptance Criteria:
* The default configuration of vsmagent/fontpath should not contain out of date paths. * The comment explaining the config parameter should not contain out of date paths. * Legacy X11 applications that still don't use fontconfig should still work.


Attachments

Description Samuel Mannehed cendio 2015-05-12 11:21:03 CEST
Currently, the list looks like this:

# The font path to use
#
# RHEL 6 server/desktop:
#          catalogue:/etc/X11/fontpath.d
# RHEL 5
#	   /usr/share/X11/fonts/misc, /usr/share/X11/fonts/75dpi, /usr/share/X11/fonts/100dpi
#	   /usr/share/X11/fonts/Type1, /usr/share/X11/fonts/TTF, /usr/share/fonts/default/Type1
# Ubuntu:
#          /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1
# SLED:
#          /usr/share/fonts/misc, /usr/share/fonts/75dpi, /usr/share/fonts/100dpi,
#          /usr/share/fonts/Type1, /usr/share/fonts/URW, /usr/share/fonts/Speedo,
#          /usr/share/fonts/cyrillic, /usr/share/fonts/truetype, /usr/share/fonts/misc,
# Solaris:
#          /usr/openwin/lib/X11/fonts/Type1, /usr/openwin/lib/X11/fonts/Type1/sun,
#          /usr/openwin/lib/X11/fonts/F3bitmaps, /usr/openwin/lib/X11/fonts/Speedo,
#          /usr/openwin/lib/X11/fonts/misc, /usr/openwin/lib/X11/fonts/75dpi,
#          /usr/openwin/lib/X11/fonts/100dpi, /usr/openwin/lib/X11/fonts/TrueType
#

I believe that the intention of this list was that we wanted to show examples which could cover most different paths we know of. We should at least consider changing "RHEL 6" to something along the lines of "Modern Linux distributions".
Comment 1 Pierre Ossman cendio 2020-11-18 10:06:36 CET
We don't even support RHEL 6 these days so this list is likely massively out of date.
Comment 2 Samuel Mannehed cendio 2021-09-07 16:27:17 CEST
The '/etc/X11/fontpath.d' folder doesn't exist on Ubuntu 18.04 or Ubuntu 20.04, so the solution doesn't seem to be as simple as just listing that path.
Comment 3 Samuel Mannehed cendio 2021-09-07 16:36:57 CEST
The situation seems unchanged on Ubuntu, the old paths are still used. The same seems to apply to SUSE.
Comment 6 Samuel Mannehed cendio 2021-09-07 16:45:49 CEST
Seems like a small effort to change this now that I've already looked into it. I'll try to verify on all major platforms that the change doesn't break anything.
Comment 7 Samuel Mannehed cendio 2021-09-09 15:43:11 CEST
All looks fine. Using server build 2265 I tested xterm in a ThinLinc session on RHEL7, RHEL8, Ubuntu 18.04, Debian 11, SLES 12 and SLES 15. Using my modified fontpath xterm ran without complaints on all platforms.

To verify that xterm did indeed use the paths from 'vsmagent/fontpath' I set that config param to " " and tested starting xterm. While xterm started on all platforms despite the empty fontpath I got a lot of complaints on stderr, errors like these:

> xterm: cannot load font "-Misc-Fixed-bold-R-*-*-13-120-75-75-C-60-ISO8859-1"

To catch stderr from xterm I started it from a different terminal.

Note that it seems we don't have any documentation for this configuration parameter in the TAG.
Comment 8 Niko Lehto cendio 2021-09-13 15:56:05 CEST
Tested server (build 2271) containing the fix on CentOS 8.

Followed the test procedure described in comment #7:
- Running xterm gave the described error messages with fontpath set to: " "
- Running xterm gave no errors with the new fontpath given in
  r37380 and r37381.
Comment 9 Linn cendio 2021-09-13 16:27:03 CEST
Testing against the acceptance criteria:

* The default configuration of vsmagent/fontpath should not contain out of date paths.
   It does not.

* The comment explaining the config parameter should not contain out of date paths.
   It does not.

* Legacy X11 applications that still don't use fontconfig should still work.
   Tested with server build 2272 on the following dists:
    ✓ Ubuntu 20.04
    ✓ Fedora 33
    ✓ Fedora 34
    ✗ CentOS 7*
  
   * On CentOS 7, I get a warning both when the fontpath is set and when it is empty, indicating that the applications are not a good fit for this test. I tried with both xterm and xclock. Since the legacy applications work despite the warning, this behaviour is accepted for now.

Warnings from CentOS 7:

> [cendio@lab-246 ~]$ xterm
> xterm: cannot load font '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'
> [cendio@lab-246 ~]$ xclock
> Warning: Missing charsets in String to FontSet conversion
Comment 10 Pierre Ossman cendio 2021-11-12 09:16:51 CET
Only one out of three places was changed, so this is unfortunately incomplete.
Comment 12 Pierre Ossman cendio 2021-11-15 09:35:16 CET
That should be everything. The only hits for the old paths are now in some man pages (that we don't include).

Checked that vsmagent did the right thing by turning up the logging to DEBUG. Couldn't get any good output from Xvnc, so ran "strings" on the binary to check the compiled in fontpath.
Comment 13 Linn cendio 2021-11-16 14:04:04 CET
Tested with server build 2345 on the three dists listed below with applications xterm and xclock, which work well. The code changes also look good.

For CentOS 7 and Fedora 33 we get warnings for one or both applications, but since the applications themselves work as expected this is accepted for now. For more info see comment 9.

  ✓ Ubuntu 18.04
  ✗ CentOS 7*
  ✗ Fedora 33**

* CentOS 7: The same warnings as mentioned in comment 9 is seen when running both xterm and xclock.

** Fedora 33: Running xclock gives this warning:

> [tester@linma ~]$ xclock
> Warning: Missing charsets in String to FontSet conversion

Note You need to log in before you can comment on or make changes to this bug.