RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1568109 - pcp-webapp-* packages render garbage fonts into PNG-based dashboards
Summary: pcp-webapp-* packages render garbage fonts into PNG-based dashboards
Keywords:
Status: CLOSED DUPLICATE of bug 1647308
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcp
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: pcp-maint
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-16 18:54 UTC by Paul Bransford
Modified: 2019-03-04 00:20 UTC (History)
4 users (show)

Fixed In Version: pcp-4.0.2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-04 00:20:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot of grafana/graphite font rendering issue (45.50 KB, application/x-gzip)
2018-04-16 18:54 UTC, Paul Bransford 		no flags Details
View All

Description Paul Bransford 2018-04-16 18:54:25 UTC 
Created attachment 1422686 [details]
screenshot of grafana/graphite font rendering issue

Description of problem:
pcp-webapp-* web interfaces that use pre-rendered graphs (graphite, grafana using default-png.json) print garbage characters instead of readable labels.

Version-Release number of selected component (if applicable):
pcp-webapi-3.12.2-5.el7.x86_64
pcp-webjs-3.12.2-5.el7.noarch
pcp-webapp-grafana-3.12.2-5.el7.noarch
pcp-webapp-graphite-3.12.2-5.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. `yum install -y pcp pcp-collector pcp-doc pcp-webapi pcp-webjs`
2. `systemctl start pmwebd`
3. browse to `host:44323` and select either "graphite", or "graphana png" demo dashboards.

Actual results:
Graphs draw lines/axis correctly, but text elements are not printed in a readable font. Screenshots attached.

Expected results:
Correct font rendering.

Additional info:
I have attempted to install various font packages (such as liberation-fonts), and in the case of graphite attempted changing the graph parameters to different font faces. Doing so did not change the results. I was unable to find upstream bugs possibly relating to this. I suspect missing fonts, but I'm not sure *what* fonts exactly. If this is indeed correct, a simple fix is to add the font as a package dependency.
Comment 2 Frank Ch. Eigler 2018-04-16 19:20:20 UTC 
If it's easy, it would be handy to get an "strace -f" of the pmwebd process after a fresh startup, during its rendering of one such png.  Here on f27, one can see a bunch of font-related configuration and data files being probed.  The last ones, probably the ones most relevant to pmwebd are:

/usr/share/fonts/dejavu/DejaVuSans.ttf
/usr/share/fonts/dejavu/DejaVuSans-Bold.ttf

which come from dejavu-sans-fonts rpm.  After the above test, would you be able to install just that RPM, restart pmwebd, and see if that fixes it?  Thanks!
Comment 3 Paul Bransford 2018-04-16 22:16:02 UTC 
I don't see references to that font on my strace, only `/usr/share/fonts/lyx/msam10.ttf` - incidentally, this is the font someone mentioned in Freenode ##linux when I asked if anyone recognized this failure mode.

Fortunately, installing dejavu-sans-fonts fixed it!

I'm not 100% on the logic of what font it selects, but it seems if it's expecting a particular font, it should be included as a package dependency. Else, something suitable should be elected as a dependency? Deja-Vu is a pretty nice and very glyph-inclusive font, and doesn't seem to have any undue dependencies - it would make a great suggestion for that.

Thank you, Frank!

(I can upload the strace output if you like)
Comment 4 Frank Ch. Eigler 2018-04-16 22:45:12 UTC 
The code is not expecting a particular font, just anything that matches "sans" as far as Cairo is concerned.  (No need for the strace report.)
Comment 5 Mark Goodwin 2018-04-16 23:07:47 UTC 
We recently added a dep on 'liberation-sans-fonts' to resolve a similar issue in pmchart (which is part of the pcp-gui package). Might be worth checking if those fonts resolve the pmwebd issue too, in the interests of avoiding pulling in another font package when chances are pcp-gui may already be installed too, along with the liberation-sans-fonts package.
Comment 6 Paul Bransford 2018-04-17 21:52:05 UTC 
(In reply to Mark Goodwin from comment #5)
> Might be worth checking if those fonts resolve the pmwebd issue too

Hello Mark,

I can confirm that liberation-sans-fonts does indeed also remedy this issue. (removed dejavu-*, installed liberation-sans-fonts, restarted pmwebd and confirmed legible text is rendered)
Comment 7 Paul Bransford 2018-04-17 21:55:03 UTC 
(In reply to Frank Ch. Eigler from comment #4)
> The code is not expecting a particular font, just anything that matches
> "sans" as far as Cairo is concerned.  (No need for the strace report.)

Should a default font (or set of fonts) be depended on by the cairo libraries, rather than by those packages utilizing Cairo? I realize drawing text is only a subset of Cairo's functionality, but it doesn't hurt to raise the question, I hope.
Comment 8 Frank Ch. Eigler 2018-04-17 22:10:29 UTC 
> Should a default font (or set of fonts) be depended on by the cairo libraries

Yeah, or freetype, which is a common solib of pmwebd and pmchart.
Comment 10 Nathan Scott 2019-03-04 00:20:20 UTC 
Fixed by rebase in 7.7.

*** This bug has been marked as a duplicate of bug 1647308 ***
Note You need to log in before you can comment on or make changes to this bug.