As we all know PDF file format is developed by Adobe. Above that, we are all familiar with Adobe’s Acrobat family of applications and Web services as the perfect walled garden to view, create, manipulate, print and manage PDF files.
On Acrobat territory UX is smooth: everything “just works” (alas, Acrobat support for Linux is dropped).
PDF is officially covered by several ISO standards, so FOSS developers have a fair chance to create their own solutions with common sense and best effort. Right? Not quite
PDF format is complicated stuff and does not have “tight” definitions at several points. This leaves space for interpretation, and therefore incompatibility: PDF’s created by one application might be considered invalid by another.
Enter CUPS. On the OSDL Printing Summit in 2006 it was decided to switch the standard print job transfer format from PostScript to PDF, and so PDF became the format of choice to be fed into the print tool chain.
This is why SavaPage stores all incoming documents as PDF. Apart from so being a PDF Creator/Editor, these documents can directly be fed to CUPS via IPP when needed. However, when “native” PDF documents are imported, for instance with Web- or Mail Print, we need to pay attention.
The obvious obstacle is password protected PDF, these documents are of course not accepted. But, what about PDF’s that seem valid after import at first thumbnail sight, but turn out not to deliver when fed into the print chain? Either by obstructing with a plain error, a lack of quality, missing or distorted content, or a very poor performance.
SavaPage has an optional safety net for these cases in the form of a repair program (
pdftocairo). But practice shows that not in all cases repair is 100% successful. When unexpected results occur, we have to investigate and diagnose what is wrong.
So, this is a call to you. If you encounter printing errors as described above, let us know by replying to this topic.
- You can attach screenshot snippets to illustrate your findings.
- Additionally send an email to email@example.com with the culprit PDF. If possible compile a very small PDF with non-sensitive content to prove the defect. If that can’t be done we will of course keep your data private.