Red Hat Bugzilla – Bug 833531
The arrow glyphs for <menuitem> entries are boned in the PDF output.
Last modified: 2014-01-15 10:47:15 EST
Description of problem:
The arrow glyphs for <menuitem> entries are boned in the PDF output, not 100% clear whether this is:
1) a font issue on the machines we are using to read it; or
2) a font issue on the machine used to build the pdf (my laptop); or
3) an issue with the PDF generation mechanism (it is possible when I built the PDF it was not with fop).
Assuming one of the 2 or 3 is the case then the easiest solution is probably to produce the next published build via internal brew and/or get the jenkins machine set up with the correct deps (the aim would be to have a build environment similar to that provided by brew, but external so other contributors can see and use it).
<jclift> sgordon: With the oVirt install guide (3.0 version), noticing there are square symbols instead of chars sometimes. i.e. pg 67, right under where it says "To add network to hosts". Any idea if that's a problem with fonts not being installed when the pdf is being created, or is it my system missing fonts to view it?
* rgolan1 has quit (Quit: Leaving.)
* tvvcox has quit (Ping timeout: 480 seconds)
* alourie has quit (Ping timeout: 480 seconds)
<sgordon> jclift, i see the same behavior but it does look like a font issue, though maybe on the build machine
<sgordon> it is those glyphs for menuitems
<sgordon> that look like an arrow -->
<jclift> Yeah, I was suspecting that would be the case.
<jclift> You up for creating a BZ about it?
* wdeheiden (~email@example.com) has left #ovirt
<sgordon> i guess so, tbh i think that it will just go away if i pump it via brew as a scratch build next time i publish
<sgordon> there is an outside chance i built it on a machine that uses the new backend for pdf generation though
<sgordon> so best track it in case i need to forward it on (that will be the default in publican 3)
Opening the PDF for the RHEV version of the guide  on the same machine the glyphs render correctly, so would assume this is indeed an issue with the environment the oVirt one was built in.
setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.