This is with xfree-4.2.1-r2, which on my system, at least, has no such font. The source patch ============================================================================== ============================================================================== --- xpdf/XPDFViewer.cc.orig 2003-03-26 14:46:01.000000000 +0000 +++ xpdf/XPDFViewer.cc 2003-03-26 14:26:23.000000000 +0000 @@ -1606,7 +1606,7 @@ aboutBigFont = createFontList("-*-times-bold-i-normal--20-*-*-*-*-*-iso8859-1"); aboutVersionFont = - createFontList("-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1"); + createFontList("-*-times-medium-r-normal--17-*-*-*-*-*-iso8859-1"); aboutFixedFont = createFontList("-*-courier-medium-r-normal--12-*-*-*-*-*-iso8859-1"); ============================================================================== ============================================================================== gets rid of the warning. I am pretty sure this is not new with xpdf-2.02, because I recall having made this change before but not reporting it. Reproducible: Always Steps to Reproduce: 1.'emerge -u xpdf' and start it up 2.Check to see if there is such a font in fonts/100dpi/fonts.dir 3. I really don't know if xpdf is trying to use a font which is no longer available, or if xfree should have such a font but doesn't, or if my system is just missing this font for some reason. In any case, it matters only for the '?' about text for xpdf and for aesthetic reasons (warning on startup). For completeness, here's the configure command that got used: ================================================================== ./configure --prefix=/usr --host=sparc-unknown-linux-gnu \ --mandir=/usr/share/man --infodir=/usr/share/info \ --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib \ --enable-freetype2 \ --with-freetype2-includes=/usr/include/freetype2 --with-gzip ==================================================================== and link is ==================================================================== g++ -mcpu=v8 -mtune=v9 -O2 -pipe -Wno-deprecated -fpermissive \ -DHAVE_CONFIG_H -I.. -I./../goo -I. -I/usr/include/freetype2 \ -I/usr/X11R6/include -o xpdf Annot.o Array.o BuiltinFont.o \ BuiltinFontTables.o Catalog.o CharCodeToUnicode.o CMap.o Decrypt.o Dict.o \ Error.o FTFont.o FontEncodingTables.o FontFile.o Function.o Gfx.o GfxFont.o \ GfxState.o GlobalParams.o JBIG2Stream.o Lexer.o Link.o NameToCharCode.o \ Object.o Outline.o OutputDev.o Page.o Parser.o PDFDoc.o PDFDocEncoding.o \ PSOutputDev.o PSTokenizer.o SFont.o Stream.o T1Font.o TTFont.o \ TextOutputDev.o UnicodeMap.o XOutputDev.o XPDFApp.o XPDFCore.o \ XPDFTree.o XPDFViewer.o XPixmapOutputDev.o XRef.o xpdf.o \ -L../goo -lGoo -lXm -lXt -lXp -lXext -lXpm -lt1 -lfreetype -lSM -lICE \ -L/usr/X11R6/lib -lX11 -lm =========================================================================
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.