asciidoctor / asciidoctor-pdf

:page_with_curl: Asciidoctor PDF: A native PDF converter for AsciiDoc based on Asciidoctor and Prawn, written entirely in Ruby.
https://docs.asciidoctor.org/pdf-converter/latest/
MIT License
1.14k stars 500 forks source link

media=prepress fails to be processed by Kindle Publishing #2477

Closed mementum closed 7 months ago

mementum commented 7 months ago

media values of screen and print do upload and are processed with no problem.

prepress will be rejected. After adding an optimization pass with rghost (and obviously ghostcript in the background) it does then upload. I also tried the Foxit PDF Editor, applying only the cleanup optimization and it also did something which made the format good for Kindle Publishing.

Understanding that finding a very small thing in the PDF generation that could be slightly different could be a huge effort, I would propose that a small hint be added to the documentation, pointing that in case of any problem with the prepress media mode, an optimization pass can iron things out.

Best regards

mojavelinux commented 7 months ago

This looks like a duplicate of #2476.

I would propose that a small hint be added to the documentation, pointing that in case of any problem with the prepress media mode, an optimization pass can iron things out.

I'm open to accepting a pull request to add this information to the documentation.

meonkeys commented 7 months ago

@mementum you can try this workaround. I used it to get a prepress PDF working with Lulu.

Credit to @mojavelinux for the idea.

mojavelinux commented 7 months ago

If we can confirm with local tools that this indeed fixes the validation error, we could consider adding this into the converter when media=prepress. But we have to be able to test it locally.

meonkeys commented 7 months ago

pdftotext appears to be happy with the workaround, as discussed in chat.

I'm using pdftotext version 22.02.0. Came to my workspace via poppler-utils 22.02.0-2ubuntu0.3 on Ubuntu 22.04.3 LTS 64-bit desktop.

mojavelinux commented 7 months ago

Working with meonkeys, I've been able to confirm that this is, in fact, a bug. What's happening is that fill and stroke color commands are being issued without first defining the color space. This occurs when running content is added to an otherwise empty page. (The commands try to set the color of something, but the color space is not defined as either DeviceRGB or DeviceCMYK. That's what it means by incorrect number of arguments for scn/SCN. I think it must default to DeviceCMYK, and an RGB color is one less argument than CMYK).

Here's the point at which I discovered the issue:

Prawn does not check whether the color space has been set when setting up the graphic state for a stamp (running content is implemented as a stamp). So it ends up setting things like the line and stroke color without initializing the graphic state on empty pages.

Ultimately a bug in Prawn. However, the workaround to set the color space if otherwise empty before writing any running content is straightforward and future proof, so we'll just go with that.

mementum commented 7 months ago

Thanks for the fix.

mementum commented 7 months ago

Let me add positive feedback now that version 2.3.11 has been released: media=prepress is accepted by KDP.

mojavelinux commented 7 months ago

Thanks for sharing @mementum! This makes me very happy. :man_dancing: