Error 135 in Acrobat Reader when reading Prawn generated PDFs

[zatmonkey]

Hi guys,

When I'm printing my dive logbook on Diveboard I get the following pdf : https://dl.dropboxusercontent.com/u/6774414/logbook%20%281%29.pdf
this is generated through prawn + prawn/fast_png

prawn (0.12.0)
pdf-reader (>= 0.9.0)
ttfunk (~> 1.0.2)
prawn-fast-png (0.2.3)
prawn
rmagick

As you can see in the screenshot, standard windows acrobat reader can't read it properly (chrome, osx preview and everything else I know never complained)

Any idea what's going on ?

thanks heaps for your help !

[zatmonkey]

diveboard@dev:~$ pdf2ps logbook.pdf
**** Error reading a content stream. The page may be incomplete.
**** Error reading a content stream. The page may be incomplete.
**** File did not complete the page properly and may be damaged.
**** Warning: File has unbalanced q/Q operators (too many q's)
**** Error reading a content stream. The page may be incomplete.
**** Error reading a content stream. The page may be incomplete.
**** File did not complete the page properly and may be damaged.
**** Warning: File has unbalanced q/Q operators (too many q's)
**** Error reading a content stream. The page may be incomplete.
**** Error reading a content stream. The page may be incomplete.
**** File did not complete the page properly and may be damaged.
**** Warning: File has unbalanced q/Q operators (too many q's)
**** Error reading a content stream. The page may be incomplete.
**** Error reading a content stream. The page may be incomplete.
**** File did not complete the page properly and may be damaged.
**** Warning: File has unbalanced q/Q operators (too many q's)

**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> Prawn <<<<
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.

[DoubleOTheven]

I have the same issue. I am using prawn(0.12.0) and the rendered document works fine in preview and chrome, but in Acrobat Reader only the first two pages can be viewed with the following pages being all blank. I am not using templates or repeatable images. Acrobat Reader gives me this error:

"An error exists on this page. Acrobat may not display the page correctly. Please contact the person who created the PDF document to correct the problem."

[DoubleOTheven]

I found the solution to my problem. The method dash() breaks the pdf for acrobat reader. I redrew all lines with a solid line instead of dashed lines and all is well... Oh yeah...

[npj]

I had the same issue, and removing dash() solves the problem for me as well.

[McPolemic]

I can confirm this is still an issue. Just ran into this today, and removing dash fixes the problem.

[practicingruby]

Can someone post a minimal reproducing example that fails on 0.13.2? Once I have that I can re-open the ticket. A quick attempt to reproduce failed for me.

[McPolemic]

Whoops, sorry about this. This isn't the same problem, or indeed any problem. I had set dash(0) in attempt to clear the dash settings, rather than calling undash. dash(0) doesn't really make any sense in this context, so not really a bug.

[practicingruby]

When you write dash(0) do you get an error in Adobe? If so we probably should at least raise an exception instead.

[McPolemic]

Unfortunately, after blowing away gems and updating to 0.13.2 (when trying to make the first example), I can't replicate this bug. I think it was just a matter of an old gem.

dash(0) currently doesn't draw a line, and produces no error in Adobe.

[practicingruby]

@McPolemic Thanks for investigating!

Still willing to re-open if others run into this problem on a recent release, the only reason we closed the ticket in the first place was due to inactivity and a lack of a code sample.

[rbrancher]

The problem remains:

  def draw_dotted_line(start_point, end_point)
      @pdf.stroke do
        @pdf.cap_style :round
        @pdf.dash [0.35, 1.65]
        @pdf.stroke_color [0, 0, 0, 30]
        @pdf.line_width 0.35
        @pdf.line start_point, end_point
        @pdf.dash 0
      end
    end

corrupts the file to Photoshop/Acrobat Reader (but not for OSX Preview).

But:

  def draw_dotted_line(start_point, end_point)
      @pdf.stroke do
        @pdf.cap_style :round
        @pdf.dash [0.35, 1.65]
        @pdf.stroke_color [0, 0, 0, 30]
        @pdf.line_width 0.35
        @pdf.line start_point, end_point
        @pdf.undash
      end
    end

works just fine. No warning, no exceptions.
I've reported just to let you know.

Prawn 1.0.0
Ruby 2.1.1-p76

And thanks for the awesome work. Prawn kicks ass!

[practicingruby]

@rbrancher: Thanks. Time is very limited now so I don't know if/when I'll look into this myself. But if we can get a pull request together I could review that and possibly merge.

Until that happens, additional research is welcome on this ticket as to figuring out the source of the problem.

[jlsync]

the problem might have something to do with Adobe Reader's float/precision support, for instance code that effectively looked something like this (using calculated numbers)...

pdf.bounding_box [0, 19.1990551181102352072], width: 280.80000000000004134, height: 19.199055118110239047 do
  pdf.text "hello"
end

works fine in Chrome browser pdf reader but fails in Adobe Reader. Using .round(ndigits) on my values fixes the problem, with .round(20) being the breaking point for Adobe Reader in this example.

[practicingruby]

Seems plausible. See this mailing list thread for additional context:
https://groups.google.com/forum/#!searchin/prawn-ruby/float$20precision$20in$20prawn/prawn-ruby/IWNaWJBo3I0/lNmYLpnRU9IJ

If you want to try to patch the PdfObject method in PDF::Core, and look for places where we do add_content, we could probably fix this by rounding out to N decimal places (something like 4 places would probably be more than enough)

[packetmonkey]

I think we may want to consider a much higher resolution than 4 places, the newer retina displays have 401 pixels per inch making rounding differences possibly more apparent.

I may be just being pedantic.

[practicingruby]

@packetmonkey: PDF points are 1/72 inch. So rounding them to 4 decimal place gives us a precision of 0.0000013889 inches. 😁

[packetmonkey]

Yep, I forgot we are dealing in PDF points and not directly rendered to screen. It's like we are working on a PDF library or something.

My bad.

[practicingruby]

Here's what the "Developing With PDF" book from O'Reilly has to say on this topic:

While the term "real" is used in PDF to represent the object type, the actual implementation of a given viewer might use double, float, or even fixed point numbers. Since the implementations may differ, the number of decimal places of precision may also differ. It is therefore recommended for reliability and also for file size considerations to not write more than four decimal places

I looked this up in the PDF standard and it too said that it's common for "real" numbers to be implemented as fixed point values. In Appendix C, 5 decimal places is recommended as a maximum.

I think we will go with 4 to be a bit more conservative, but if that causes any problems we can try bumping it up to 5. But it's clear that beyond that we can expect trouble... even the standard tells us that.

[practicingruby]

Upon closer investigation, this issue does not have to do with float rounding (though I'll open a second ticket for that, because it needs to be fixed throughout Prawn)

It has to do with the difference between dash(0) and undash.

This is what dash(0) generates at the PDF level:

[0 0] 0 d

And this is what undash generates:

[ ] 0 d

The latter is what the standard expects for setting dash to an unbroken line.

We don't seem to document anywhere the idea that people ought to use dash(0) to clear dashes, and we do have an undash method, so I think if anything we should cause dash(0) to raise an error... it doesn't make sense to have segments of length 0 followed by gaps of 0!

Thoughts?

[practicingruby]

See #780 for updates about the decimal rounding issue.

[McPolemic]

That sounds good to me. The two options for not creating an erring PDF are to throw an exception on dash(0) or run undash when someone runs dash(0). Looking back on my code, dash(0) doesn't make any sense, so I think it's better to tell people to correct their code rather than just silently fixing it.

[practicingruby]

@McPolemic: That's what I'm thinking too. Unless there is a reasonable use case for dash(0), I think we should disallow it to prevent ambiguous results.

[practicingruby]

Disallowed dash(0) in e65c244