I have a problem with the various PDF files from the pathfinder product lines. On Linux I have two alternatives to open these files, one is Adobe Reader, the other is xpdf/KPDF (or any other reader based on the poppler rendering engine). If I use Adobe Reader, the files, especially the pictures are very, very dark and slightly greenish and the text ist also dark and fuzzy and difficult to read. If I use KPDF, the text and pictures are fine, however, each and every capital letter A (and only A) in any paragraph headline is missing - although if I copy and paste the text, the As are there, they just don't get displayed.
Do you have any idea what's going wrong here?
I don't know if this is of any use, but maybe it helps: a friend of mine who is on the KDE development team has talked to a developer of the poppler renderer about the missing As, and that developer surmised it might be due to a non-standard PDF.
Linux acrobat displays the pathfinder pdfs (at least up to #6) correctly. kpdf however someties has problems with the layers of the pictures (e.g the sihedron rune was displayed on top of character pictures without being transparent). Which versions are you using?
I'm using Adobe Reader 8.1.2 or KPDF 0.5.9 (from KDE 3.5.9), or even xpdf 3.02. Both KPDF and xpdf use the poppler rendering engine which I have tried in several versions (0.6.1, 0.6.4, and 0.7.3).
As for Adobe Reader displaying correctly: open up two windows, one with Adobe Reader, and one with KPDF or xpdf, and just look at the cover of a Pathfinder PDF in both windows, and you'll see what I mean about the quality of Adobe Reader's rending.
|
I use Linux as well, and I've noticed some colors look off compared to the printed version, but it never bothered me.
In any case I think it's a problem with the Acrobat Reader port to Linux, not something that Paizo is doing wrong, in fact they probably use Adobe products to create the PDFs anyway. As a matter of fact, I've noticed this issue with PDFs from other publishers.
You can see the difference in color between Adobe Reader (on the left) and KPDF (on the right) here:
And here's an example of the missing As in KPDF:
Note: Adobe Reader running in a Windows VM shows the same (correct) color scheme as KPDF, so it's only the Linux Adobe Reader version that screws up the colors.
Chief Technical Officer
|
I use Linux as well, and I've noticed some colors look off compared to the printed version, but it never bothered me.
In any case I think it's a problem with the Acrobat Reader port to Linux, not something that Paizo is doing wrong, in fact they probably use Adobe products to create the PDFs anyway. As a matter of fact, I've noticed this issue with PDFs from other publishers.
Yep—sounds like you should inquire with Adobe. Unless you maybe have some color management preferences within Reader? (I'm hereby giving you permission to share these files with them or with the poppler people, so long as it's done strictly as a troubleshooting technique.)
Our PDFs are almost all made from Adobe InDesign and then tweaked in Adobe Acrobat. (If a PDF contains only maps, it may have started with Adobe Illustrator instead of InDesign.) The only non-Adobe part of the process is our watermarker, but it merely inserts some objects and wouldn't affect colors or embedded fonts.
Vic, thanks four your input. Actually Adobe Reader is supposed to respect embedded color profiles, and it offers no preferences to change anything in this regards. Still strange though, that the Linux Reader messes up.
It's good to know that your PDFs are generated with Adobe software, as that means the probability of them being non-standard is slim. Probably the missing As are poppler's fault then.
Thanks for granting permission, too. I have provided the poppler people with a link to the free CoCT Player's Guide which shows missing As, too.
Here's another snapshot of missing As, this time taken with Okular, lastest version taken directly from the KDE subversion repository. Okular is the document viewer in KDE 4 and this version uses poppler 0.7.3:
|
Chief Technical Officer
|
Here's another snapshot of missing As, this time taken with Okular, lastest version taken directly from the KDE subversion repository. Okular is the document viewer in KDE 4 and this version uses poppler 0.7.3:
This is a long shot, but have you repersonalized and redownloaded the document? It could be that somehow the embedded font got a couple of bits tweaked, or something... not that that should be able to happen but, you know... computers.
This is a long shot, but have you repersonalized and redownloaded the document? It could be that somehow the embedded font got a couple of bits tweaked, or something... not that that should be able to happen but, you know... computers.
It happens any Pathfinder PDF, even the newest ones like the Alpha Playtest PDF, so I guess that's not the point. My guess is that something is probably wrong with the font that these headings are using, and Adobe Reader is more forgiving than poppler in rendering the letter A. Or maybe it's just a bug in poppler.
I have the same problems with paizo pdfs on Linux, including the missing As...It hasn't bothered me yet, as the same file can be viewed on windows perfectly.
Yup.... I've seen it too. Repersonalizing the pdf doesn't change it. Hey Paizo! Get a Linux LiveCD of your favorite distro and reboot! This way you guys can tinker with your pdfs and check them in Linux.
...and maybe you'll the dark side! :)
--Ray.
I just figured I'd add that I'm having the problems with A rendering using Xpdf on FreeBSD, too. Since Poppler is based on Xpdf code, I imagine that Zaister's estimation is correct -- either it's a font issue, and Adobe Reader is more forgiving of the error, or it's a Poppler (and Xpdf) bug.
When running Xpdf from a terminal emulator, I get this line over and over again in the terminal window while browsing through the Pathfinder RPG Alpha:
Error: Illegal entry in bfchar block in ToUnicode CMap
This seems to lend credence to the idea that there's something not right with the font itself, especially since that error message correlates in at least some cases with an "incomplete font object copy". I've seen the same thing with more than one PDF, so it's not just a matter of "personalizing" the PDF going wrong on one occasion.
I don't know if any of the above information would be of any help to the fine folks at Paizo, but I figured I'd offer it just in case. It doesn't render the Pathfinder RPG Alphas unusable, but I would hope this problem wouldn't present itself with any PDFs I might purchase for real money in the future.
|
Just to add more info:
I checked the Alpha 3 PRPG document on Fedora 7. When I used Evince (my default doc viewer in GNOME) I saw the "missing A's" problem. Evince (my version 0.8.2) is based upon poppler 0.5.4. The PDF looks great under Windows.
I am going to yum to be sure I am up to date on everything and give it another try.
Edit: nothing related to Evince or poppler came through on yum so the problem remains.
Contributor
|
I was having many repeated brutal problems with Paizo pdfs in Evince, the Pathfinder Alpha docs being the worst of the bunch. Then both of my computers died and I'm currently using a machine running Vista :-( but at least my pdfs work.
Actually Evince was also a problem for a bunch of other pdfs, like GM Gems. I didn't notice the problem with the As, but I had major layer-related problems. In the alpha, several of the tables came up with the text under the background colour. I had to select all the text in the table to highlight it so I could read it. Also, the border art made big shadows across the page. It was brutal. I mostly blame Evince, but some pdfs were worse than others.
|
I might not be much help as I don't currently have access to a Linux machine, but I use Foxit reader which is free.
It can be found here
I also use linux, and wouldn't mind having the PDFs work better in another viewer :)
They work fine for me in acroread, so I'll continue using that one.
It's pretty clear that Poppler doesn't like one of our fonts, but since they're the only renderer with this problem, the fix needs to come from them.
My guess, based on what I know of the situation (as I indicated above), is that the problem is actually with the font -- and poppler/xpdf is less forgiving of this particular font problem than acroread. It's a bit like having a defective fuel injection system that gets the fuel/air mixture just slightly wrong, such that on one car there's only a negligible fuel efficiency problem, but on another it results in significant degradation in performance, a tendency for the engine to stall, and a complete inability to pass emissions tests.
Now, that may not be the case -- it may actually be a poppler bug -- but that seems the less likely case based on my limited knowledge of the situation (including sifting through debugging information for xpdf). I'm mildly disappointed that you've decided to write it off as "a poppler problem" without bothering to actually check, though, since it seems that your entire justification for that conclusion is the fact that only users of poppler-based PDF readers have been vocal about having a problem.
By the way, poppler isn't just a PDF reader. It's a widely used PDF rendering library, and problems that affect poppler affect more than a dozen different PDF reading applications. Looked at from the point of view of individual PDF reading applications, it's more like a dozen that don't work and two or three (Adobe Reader, acroread, and maybe Foxit) that do.
I may get in touch with the poppler people about this to ask if they have any more insight to provide on the question of whether it's a poppler problem or a font problem, and thus whether or not it would be appropriate for the poppler developers to do anything about it. I was hoping we'd get a better response from Paizo than a "sounds like a problem on your end" rubber stamp.
As I've indicated elsewhere in this thread, it's not that big a deal for a free alpha test -- but, if this problem remains, it will affect my PDF purchasing decisions in the future.
|
Chief Technical Officer
|
My guess, based on what I know of the situation (as I indicated above), is that the problem is actually with the font -- and poppler/xpdf is less forgiving of this particular font problem than acroread.
You might be right about the font being hinky—in fact, I suspect you are—but if poppler is supposed to be an effective replacement for the industry standard, then they need to render as accurately as the industry standard. If they're not doing so, that *is* their problem. And judging by the types of bug reports I see on their site, it is similar to other problems they have, and that they actually want to fix.
By the way, we state that our PDF downloads "require Adobe Reader 5.0 or later." We use an all-Adobe workflow to help ensure compatibility with the industry standard reader, but there's just no way we can guarantee compatibility with every engine on every OS.
...it seems that your entire justification for that conclusion is the fact that only users of poppler-based PDF readers have been vocal about having a problem.
Well, given that well over 15,000 people have downloaded this PDF, and only users of poppler-based PDF readers are complaining, I think it is a safe assumption that it's limited to poppler. (We do hear about it when there are issues—Foxit wasn't displaying some of our PDFs correctly either, until Foxit issued an update.)
You might be right about the font being hinky—in fact, I suspect you are—but if poppler is supposed to be an effective replacement for the industry standard, then they need to render as accurately as the industry standard.
I think you're misusing the word "accurately" here, if there's something "hinky" with the font. The situation seems to be that poppler works correctly, but that's not good enough in this case -- it has to also work with stuff that's broken. While I agree that improving adoption of poppler-based PDF readers depends to some extent on being able to render everything Adobe Reader does, that doesn't mean there's anything technically wrong with poppler itself.
If they're not doing so, that *is* their problem.
In some respects, this is true. It is also Paizo's problem, however. See my comment on my own purchasing habits below.
By the way, we state that our PDF downloads "require Adobe Reader 5.0 or later." We use an all-Adobe workflow to help ensure compatibility with the industry standard reader, but there's just no way we can guarantee compatibility with every engine on every OS.
I'm aware that there are limits to the resources that can be devoted to this kind of problem -- and only Paizo can make the determination of where the line between worthwhile effort and too much effort actually lies.
You should be aware, though, that this doesn't change the basic fact that poppler rendering issues, particularly when they're not poppler bugs per se, will affect my future PDF purchasing decisions, for as long as I fail to find a PDF reader I like more than xpdf (or something else based on, or sharing code with, poppler). Period. I'm sure I'm not the only person more reluctant to spend money on PDFs that don't work correctly in my PDF reader of choice -- and PDF readers that are based on or share code with poppler probably comprise a substantial second place in the PDF reader application market.
Whether that second place is a big enough share of the market for Paizo to decide it justifies the effort involved in, say, fixing or replacing an offending font, is not something I'm qualified to judge. It is in part in hopes that somewhere between Paizo and the xpdf and poppler developers the problem will be fixed -- but it is also as a service to Paizo that I bring up the fact that at least one customer (me) may not spend as much money at Paizo as long as this remains a problem.
Do with that information what you will.
Well, given that well over 15,000 people have downloaded this PDF, and only users of poppler-based PDF readers are complaining, I think it is a safe assumption that it's limited to poppler. (We do hear about it when there are issues—Foxit wasn't displaying some of our PDFs correctly either, until Foxit issued an update.)
I'm glad you brought up Foxit as well, because I was just about to mention it. I saw some Foxit complaints both here at the Paizo forum and in the #pathfinder channel at irc.otherworlders.org over the last few days. I'm a little confused by the fact that you've just contradicted yourself, with the phrasing you used -- saying that only poppler-based PDF reader users are complaining and in the same paragraph referring to complaints you've received from Foxit readers.
Anyway . . . I hope this gets fixed one way or another, because I'd really like to feel justified in buying some Paizo PDFs in the future. As things currently stand, however, that's not likely to happen.
|
Just as a note, because I am a foxit user myself on my windows box, the issue people were having with foxit was a problem within foxit. As in it worked one version, didn't work the next, and then was corrected in an update. There was a change made within the reader itself that broke its compatibility with some aspects of the pdfs, and that was corrected in a later release.
I think that an aspect of your argument is slightly off in this case however. You are arguing that poppler is rendering the fonts much more stringently and thus correctly, since apparently it blocks or refuses to render some part of the font that the other readers allow to get through. And your argument is that Paizo should alter fonts to meet with this standard.
This is one of those things that is common among web designers who don't like to occasionally do some design that is technically 'incorrect' in HTML because it will look better in IE(being the most popular browser) due to some shortcut or another in the method IE uses to read the script, but this comes at the cost of it looking worse in other browsers that are faithful to the exact specifications of the standard.
I think the difference in this case is that .pdf is Adobe's standard, at least in terms of having been developed by them. Poppler may render more strictly and in a way that rings true as being 'correct' to some(and with their market share that is a fair sum of people) but that doesn't mean it is necessarily more in line with the standard. As they grow in popularity(popplerity?) either there will be updates to the standard to reflect this desire of strictness, or poppler will have to adapt to render things as they are expected to be rendered by the vast majority of users.
Either way, they are a third party software manufacturer and its a pretty impossible mark to set for Paizo to be expected to produce products that meet whatever any given third party company(yes, even those with some market share) believe the standard -should- be. Their products meet what it is.
-Tarlane
|
Chief Technical Officer
|
Vic Wertz wrote:
Well, given that well over 15,000 people have downloaded this PDF, and only users of poppler-based PDF readers are complaining, I think it is a safe assumption that it's limited to poppler. (We do hear about it when there are issues—Foxit wasn't displaying some of our PDFs correctly either, until Foxit issued an update.)I'm glad you brought up Foxit as well, because I was just about to mention it. I saw some Foxit complaints both here at the Paizo forum and in the #pathfinder channel at irc.otherworlders.org over the last few days. I'm a little confused by the fact that you've just contradicted yourself, with the phrasing you used -- saying that only poppler-based PDF reader users are complaining and in the same paragraph referring to complaints you've received from Foxit readers.
What I was trying to say is that only users of poppler-based PDF readers are reporting *this particular problem*—improper display of the letter "A." As I understood your earlier post, you were suggesting that the only reason I consider this a poppler problem is that only poppler users were complaining about it. I'm agreeing that that's true, and given the sample size, it seems justifiable.
The only major problem I'm aware of with Foxit was a completely different symptom—entire pages would be rendered blank; an update to Foxit solved that problem.
I hope this gets fixed one way or another, because I'd really like to feel justified in buying some Paizo PDFs in the future. As things currently stand, however, that's not likely to happen.
I'd like to have it fixed too, but I feel pretty confident that the most likely course for such fix is for the poppler folks to fix it. Have you reported it to them? (I don't think it would be as useful coming from me, because I have no ability to follow up with them, since I'm not using their software.)
Argh. The lack of convenient email-notice thread subscription here really interferes with my ability to keep track of discussions. I forgot all about this one for a while, and didn't realize there had been more posts made.
I think that an aspect of your argument is slightly off in this case however. You are arguing that poppler is rendering the fonts much more stringently and thus correctly, since apparently it blocks or refuses to render some part of the font that the other readers allow to get through. And your argument is that Paizo should alter fonts to meet with this standard.
Actually, that's not what I'm saying at all. What I'm saying is that the fact Paizo uses a broken font (and it appears that it is broken, regardless of how it may be rendered by one PDF reader or another) may cost Paizo some business. It may even affect Paizo's PDF sales quite a bit, since not only are Poppler-based and Poppler-related PDF readers probably the second most popular block of PDF clients in circulation right now, but Pathfinder RPG likely boasts a larger than average percentage of customers who use it instead of something like Adobe Reader, thanks to the natural sympathy a lot of open source software users would have toward an OGL successor to D&D 3.5.
I think the difference in this case is that .pdf is Adobe's standard, at least in terms of having been developed by them.
I don't know if you're aware of this fact, but PDF is now an ISO standard.
As I understood your earlier post, you were suggesting that the only reason I consider this a poppler problem is that only poppler users were complaining about it. I'm agreeing that that's true, and given the sample size, it seems justifiable.
I think you missed a subtle distinction, there: the fact it is only reported by users of Poppler-related PDF readers is not proof that it's a bug in Poppler, any more than the fact that brownouts only cause problems for computers that aren't plugged into a UPS is a problem with the computers that aren't plugged into a UPS. In that analogy, the problem is the brownouts, not the computers. If there's a broken font being used, and some PDF readers manage to display it in a manner that appears "correct" to users anyway, it's still a problem with the font -- not with PDF readers who display the font in a manner that looks broken.
I'd like to have it fixed too, but I feel pretty confident that the most likely course for such fix is for the poppler folks to fix it.
It's possible you're right -- but if it's a problem with a broken font, I have to wonder why you insist that to satisfy customers of a single publisher a bunch of debugging and patching should be done, rather than the font simply being fixed. In general, a broken font is easier to fix than it is to work around by writing a bunch of special case handling code to make up for the deficiencies in the font. In fact, many developers refuse to bloat up their applications with special case code whose only purpose is to make up for someone else breaking stuff.
Have you reported it to them?
I have not reported it to the Poppler developers, because I'm not technically using a PDF reader that uses Poppler. I'm using xpdf, which shares some code with Poppler -- so I reported it to Glyph & Cog, the guys who develop and maintain xpdf, instead. I'm waiting on a response.
I can see how the darker colors might look better -- if the quality of the image weren't degraded. It doesn't look like the image just has darker colors, though. Instead, it looks like there's some kind of problem involving rendering it with too much contrast by eliminating lighter shades, creating a bias toward darker colors. That, of course, ends up giving you degraded image quality.
Try playing around with enhanced contrast filters in Photoshop or the GIMP to see what I'm talking about in terms of degrading image quality, if what I said above isn't terribly clear.
Well, I've talked to Derek Noonburg of Glyph & Cog. He had the following to say (collected from two separate emails in our exchange):
>> That's kind of an odd case. The letter 'A' is CID (character ID) 0,
>> which is supposed to be reserved for the 'notdef' (not defined) glyph.
>> And FreeType is not rendering that glyph. I'd say the bug is arguably
>> in the PDF generator, not FreeType. (It looks like the PDF file was
>> generated by Adobe InDesign, but this isn't the first time I've seen
>> Adobe not quite following their own specs.)I can talk to the FreeType guys, but it does look like this usage is out
of spec (with regard to the CFF font spec), so it's not really a
FreeType issue as such.
In other words, as already discussed, this is a problem with the way the font is specified in the document. Judging by Mr. Noonburg's comments, though, it looks like it's a problem with how the font was specified in the document by the PDF authoring tool, and not with the font itself (where the latter was my guess).
note: FreeType is the font rendering engine used by poppler and Xpdf to render "TrueType" fonts.
Just as a catch-up: in the meantime the culprit library, whether it was poppler or freetype, seems to have been fixed. Paizo PDFs are now displaying the previous missing 'A' letters in my current version of Okular in KDE 4.