Summary: | xpdf-2.02: Warning: Cannot convert string "-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1" to type FontStruct | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ferris McCormick (RETIRED) <fmccor> |
Component: | Current packages | Assignee: | Sparc Porters <sparc> |
Status: | VERIFIED INVALID | ||
Severity: | trivial | CC: | prote |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | Sparc | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Ferris McCormick (RETIRED)
2003-03-26 10:33:20 UTC
When you had this problem, did your user's .xpdfrc contain the following lines? include /etc/xpdfrc t1libControl high freetypeControl high Yes, that's exactly what it is, as suggested by the emerge. Ok cool. Do you have a pdf you could attach to the case that causes this problem? I tried a few I have but wasn't able to replicate. If you are going to see the message, any pdf file will get it. It comes from where xpdf is trying to set itself up so that it can display its help message. That is, xpdf sets this up before it even cares if it has a file. If you don't see the message, it means most likely that something is missing on my system and needs reinstalled. The font my band-aid change uses is one of xfree86's fonts in 100dpi; xf86 does not claim to have the 16pt version anywhere on two different systems, so this font must come from somewhere else. I suppose my real question here is where is xpdf supposed to get this font from, so I can fix my system. It looks like xpdf is using the ghostscript fonts (available as app-text/ghostscript). I'm guessing you don't have ghostscript installed? # etcat versions ghostscript [ Applications found : 1 ] * app-text/ghostscript : [ ] app-text/ghostscript-7.05.3-r1 [ I] app-text/ghostscript-7.05.5 [M ] app-text/ghostscript-7.05.5-r1 [M ] app-text/ghostscript-7.05.5-r2 [M ] app-text/ghostscript-7.05.6 It gets constant use. 3132 -rwxr-xr-x 1 root root 3204324 Mar 8 16:56 /usr/bin/gs* However, the message for me is independent of the existence of a configuration file. Thus, testing with lacewing bin # ./xpdf -cfg /dev/null Warning: Cannot convert string "-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1" to type FontStruct lacewing bin # ./xpdf -cfg /etc/xpdfrc Warning: Cannot convert string "-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1" to type FontStruct Hrm, interesting. I'm not able to reproduce it. I'm running it on two different systems, and can't reproduce it with or without the config. I've also tried running X with and without xfs, but it doesn't change anything either. If you run xfontsel can you select the font parameters to match the string above? No, closest are 14, 17, or 18. I am sure I am missing a font, but have no idea where from. My problem completely; sorry for raising the issue. While trying to upgrade to XF-4.3.0-r2, I noticed that my XF86Config file was specifying ".../75dpi:unscaled" etc. This is not right, and I would now say "Reproducible: Never" and this bug (which should never have been opened) should now be closed. problem with user's x config, not xpdf Problem was with the user's XFree86 configuration, not with xpdf. Let me chime in. IMHO, this IS a bug (ok, an annoyance, but the culprit is xpdf anyway). The problem is with xpdf specifying its interface fonts too restrictively - for no real reason. E.g., changing the font spec from "-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1" to "-*-times*-medium-r-normal--16-*-*-*-*-*-iso8859-1" would allow it to pick times new roman; times new roman fonts are usually in the ttf format so any required size would be supplied by X. Same for the other two fonts. As to ":unscaled" - this is the CORRECT way to deal with bitmap fonts unless one is going to suffer from ugly rescaled bitmap fonts. (In reply to comment #13) See Bug 200023 for a ebuild that also implements your proposed fix. |