Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#50297 - [xpdf] doesn't show PDF content on several PDF files.

Attached to Project: Community Packages
Opened by Javier (jevv) - Sunday, 07 August 2016, 09:53 GMT
Last edited by Levente Polyak (anthraxx) - Tuesday, 02 January 2018, 19:58 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:

My bank account sends status of some account through PDF files. Before I had no problems looking at them through xpdf, but now the content is not rendered on xpdf.

Might be that the recent changes on poppler and poppler-glib affected xpdf somehow, or that xpdf requires a re-build given those changes, even though poppler is not a requirement...

Additional info:
* package version(s)
xpdf 3.04-5
poppler 0.46.0-2
poppler-glib 0.46.0-2

* config and/or log files etc.


Steps to reproduce:

See attachment called xpdf_read_pfd.gif and notice how it's empty, whereas the the attachment called gv_read_pdf.gif shows how gv has no problem rendering the PDF.

Just in case, xpdf usually shows several fonts errors, who I usually ignore, given there was no problem rendering these PDFs before, but now that it's failing, here I add some of the errors:

% xpdf Estado_de_cuenta.pdf
Config Error: No display font for 'Courier'
Config Error: No display font for 'Courier-Bold'
Config Error: No display font for 'Courier-BoldOblique'
Config Error: No display font for 'Courier-Oblique'
Config Error: No display font for 'Helvetica'
Config Error: No display font for 'Helvetica-Bold'
Config Error: No display font for 'Helvetica-BoldOblique'
Config Error: No display font for 'Helvetica-Oblique'
Config Error: No display font for 'Symbol'
Config Error: No display font for 'Times-Bold'
Config Error: No display font for 'Times-BoldItalic'
Config Error: No display font for 'Times-Italic'
Config Error: No display font for 'Times-Roman'
Config Error: No display font for 'ZapfDingbats'
...
Syntax Error: Couldn't find a font for 'Courier-Bold'
Syntax Error: Couldn't find a font for 'Courier'
Syntax Error: Couldn't find a font for 'Times-Bold'
Syntax Error: Couldn't find a font for 'Courier'
...
Syntax Error: Couldn't find a font for 'Helvetica-Bold'
...

At any rate, other PDFs are being rendered fine, showing the same config errors...
This task depends upon

Closed by  Levente Polyak (anthraxx)
Tuesday, 02 January 2018, 19:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  4.00-2
Comment by Levente Polyak (anthraxx) - Sunday, 07 August 2016, 19:30 GMT
not sure how xpdf itself should fix this, rebuilding because of poppler make not much sense as it does not link against it.
If you feel like its poppler related please try downgrading those and see if it helps.
Otherwise i would recommend opening a bug report at upstream
Comment by Javier (jevv) - Sunday, 07 August 2016, 22:12 GMT
Hmm, I have no clue what can be going on, :-(. But I xpdf hadn't changed itself recently, so it might be any of the dependencies, though not poppler then...

The same PDFs that were rendered before, now are not rendered, and xpdf hadn't changed... So not sure what to file upstream with, :-(
Comment by Levente Polyak (anthraxx) - Sunday, 07 August 2016, 22:38 GMT
can you try downgrading gsfonts, freetype2 and fontconfig and give feedback if any of those help?
Otherwise try to check your recent package updates in /var/log/pacman.log and what could have correlation with fonts or xpdf
Comment by Javier (jevv) - Monday, 08 August 2016, 05:42 GMT
Downgrading to:

freetype2 2.6.5-1
gsfonts 20160531-1
fontconfig 2.12.1-1

Didn't work, :-(

BTW, gsfonts fails on Type1 when downgrading:

% sudo mkfontscale
Unknown Type 1 weight "Bold Italic"
Couldn't determine weight for P052-BoldItalic.t1
Unknown Type 1 weight "Oblique"
Couldn't determine weight for NimbusSans-Oblique.t1

And then when installing the fonts post-installation fails:

:: Processing package changes...
(1/1) reinstalling gsfonts [############################################################] 100%
Unknown Type 1 weight "Bold Italic"
Couldn't determine weight for P052-BoldItalic.t1
Unknown Type 1 weight "Oblique"
Couldn't determine weight for NimbusSans-Oblique.t1

Well, downgraded didn't help then...
Comment by Javier (jevv) - Monday, 08 August 2016, 05:44 GMT
Attached the pacman.log, just in case...
Comment by Cam Webb (camwebb) - Friday, 12 August 2016, 19:41 GMT
Same problem for me. Since a recent update, I've been having other issues caused by changes in fontconfig. The xpdf issue may also be related to fontconfig.
Comment by Olivier (olive) - Sunday, 14 August 2016, 18:46 GMT
This is due to fonts like n021003l.pfb that are not distributed anymore (it used to be part of gsfonts); see the complete list in /etc/xpdfrc. My solution was to download an old copy of gsfonts (namely gsfonts-20150811-1) and to place the needed fonts in a directory xpdf read (one of the directory /usr/share/ghostscript/fonts/ , /usr/local/share/ghostscript/fonts/ ,/usr/share/fonts/default/Type1/, /usr/share/fonts/default/ghostscript/) or to put them in any directory and configure /etc/xpdfrc accordingly. I am not sure that simply downgrading gsfonts might be a good idea (some other software might need the new fonts). Anyway the xpdf package should provide these fonts or depends or a package that gives them. With pkgfile, it seems that an other package does that (grace).
Comment by Jens G (Thah) - Tuesday, 16 August 2016, 12:25 GMT
I followed Olivier's hint and put the font files from [whatever]/Type1/ of gsfonts-20150811-1 into
/usr/local/share/ghostscript/fonts/. Works just fine.

Upstream's commit message says:

| URW++ update to base 35 from June 2016.
|
| This extends the Greek and Cyrillic glyphs originally supplied in only three
| font families to cover all the relevant fonts in the base 35.
|
| These remain covered by the GPL with the embedding exemption.

There /might/ be some license problem with redistributing these missing fonts.
Comment by Javier (jevv) - Tuesday, 16 August 2016, 20:53 GMT
Hi, this looks more like a xpdf bug ,right? It's dependent on no longer supported fonts... I see gv working fine, but of course ghostview is part of the ghostsript family, so they better be compliant with its own changes, :-)

While fixed, Arch can have a gsfonts2015 package, stuck with the old fonts, and it can be removed when xpdf start depending on the right set of fonts, or start providing them themselves (the fonts it depends on, and gsfonts doesn't provide)...

How about that?
Comment by Jens G (Thah) - Wednesday, 17 August 2016, 07:40 GMT
It's not so clear cut who is to "blame". Ways to fix it would be:

1. xpdf package: Modify /etc/xpdfrc to point to existing, compatible fonts.
2. xpdf upstream: Adapt to existing, compatible fonts in gsfonts.
3. gsfonts package: Provide compatibility links to existing fonts while programs rely on them.
4. gsfonts upstream: Same as 3., because the old names may be considered "tradition" similar to
MTAs that provide sendmail compatible commands.

It seems to boil down to policy.
Comment by Olivier (olive) - Wednesday, 17 August 2016, 08:08 GMT
@Jens Rather to "blame", better to fix. It is not clear upstream actively maintain xpdf anymore and gsfonts is intended to use with ghostscript (which it does properly). I am not sure that actual fonts are compatible (but I may be wrong, I am not a specialist). These fonts takes only a negligible amount of space (1.5 Mb if you only put the pdf fonts, not the whole postscript set) and the fix easy. The packager could simply pack those fonts with xpdf and configure xpdf accordingly. It may better to use a specific location like /usr/share/xpdf/fonts and to configure xpdf accordingly than to use a standard dir in order to not interfere with other softwares.
Comment by Levente Polyak (anthraxx) - Wednesday, 17 August 2016, 12:59 GMT
I'm still investigating alternative solutions, gsfonts only distributes OTF fonts instead of PFB and xpdf seems to only be compatible with PFB, TTF and TTC. I'm trying out some stuff and if that does not work out i will pull them into a xpdf related separated folder.
Comment by Olivier (olive) - Thursday, 18 August 2016, 08:24 GMT
@anthraxx Be careful to check that any other fonts is metric compatible with the missing fonts and are recognized as the standard fonts. Choosing fonts that are not metric compatible will likely result in subtle bugs that are not immediately noticeable (bad kerning or formatting for some pdf file). I think the best and safest way is to ship the missing fonts with xpdf and adjust the paths in /etc/xpdfrc. Note that I have seen that those fonts are shipped with "grace". I do not use this software (I found it with pkgfile) but presumably they face a similar problem.
Comment by Olivier (olive) - Thursday, 01 September 2016, 08:36 GMT
Any progress? The fix is really simple. Just provide the needed fonts (look in /etc/xpdfrc) and configure the paths in /etc/xpdfrc.
Comment by Javier (jevv) - Thursday, 01 September 2016, 18:54 GMT
BTW, though I opened the issue, I have dropped xpdf already. I'll even stop watching the issue. Sorry for that, and I hope I'm not needed to verify anything regarding the issue at all, no matter the direction taken...
Comment by Shawn Rutledge (ecloud) - Sunday, 25 December 2016, 22:18 GMT
This is apparently the same as https://bugs.archlinux.org/task/50757

I agree that something should be done. Maybe follow the suggestion there and put the Type1 fonts into another package like gsfonts-type1 or so, and have xpdf depend on it?
Comment by Olivier (olive) - Sunday, 24 December 2017, 08:32 GMT
Something should be done. We can't completely blame the upstream xpdf developer as some people do on these forums. "Old" gsfonts are not older than the "new" fonts; they appear to be still distributed and maintained by upstream and are compatible with current ghostscript. See https://github.com/ArtifexSoftware/urw-base35-fonts/tree/master/fonts. The name has been changed but I am pretty sure the t1 version are compatible with xpdf (the name is easily changed in xpdfrc). It's just that Archlinux prefer to ship the otf version that while compatible with ghostscript are not compatible with xpdf. We can't blame the upstream xpdf developer to not follow the decision of a particular Linux distribution.

Now the fix is simple and known. These fonts are not resource intensive, so please do something even it it consists of shipping two versions of the same fonts.

Loading...