[Scribus] PDF generation (was: Time to defend your use of libPDF)

[Craig Ringer]

Riku Leino wrote:
> Eww, what a troll
> 
> Calum Polwart wrote:
>> "By the way, the PDF generator, Libpdf by Scribus, generates terrible
>> PDF.  It  is extremely inefficient and redundant, and has outright errors in 
>> the font widths and Trimbox."
> 
> I suppose this is all that he said. I'm sure if we could get a proper bug 
> report (http://bugs.scribus.net) it wouldn't take too long for Franz to fix 
> it.

That means _detailed_ and _specific_ about what's wrong; ie what 
redundancies exist, and what the errors are.

In part I suspect he'll be referring to the text output. That *is* 
awful, but I understand from Franz that it has to be as a workaround for 
issues with some processing applications & RIPs.

PDF validation is also somewhat difficult, as Riku can attest. Adobe 
Acrobat Pro, and Enfocus PitStop, are very useful for checking the 
suitability of well-formed PDF documents for print/prespress use. 
They're not very good at checking the low-level structure and details - 
for example, when faced with dodgy PDF Acrobat often crashes or goes 
into an infinite loop instead of reporting the error. Since PitStop just 
relies on Acrobat's PDF APIs, it's no better.

Access to a really solid tool to verify PDF at a low level would no 
doubt be rather helpful. Suggestions?

It's worth noting that most of what Scribus calls "libpdf" is actually 
neither a library, nor generic code implementing PDF. it's a module that 
converts in-memory Scribus documents, fonts, and images to PDF data 
stream snippets and writes them out. There is no implementation of the 
PDF document format there as independent from scribus's generation of it.

I've been wondering about using a full PDF library for a while. There 
are a few out there that could potentially be used:
	- cLibPDF
	- LibPDF (pdflib.com)
	- libharu
	- libpanda
Some of these are unusable for Scribus:
	- cLibPDF is non-free ($0 for non-commercial use)
	- LibPDF is non-free ($0 for non-commercial use)

Others look interesting. I've had a look at libharu, and it's pretty 
decent and has been around for a little while. It's only up to PDF 1.2 
and certainly has some limitations, but nothing that couldn't be fixed I 
suspect. I haven't really looked at libpanda yet. I also started work on 
a C++ PDF library before finding any of these, and I've continued on 
that because I think we need a library that's designed to support very 
low-level PDF manipulation where required, is extensible, and is very 
"safe" (generates correct output or throws) to use.

Note that any move to a separate PDF library would involve a partial or 
near-total re-write of Scribus's PDF output code. That's a really big 
job, and one that'd no doubt introduce as many bugs as it solved to 
start with. We can't just "drop in a PDF library" or swap "libpdf" out 
for one. The original poster needs to understand this, and clearly does 
not given the rather confrontational mail subject.

What we need right now is reports of problems, with good reproducible 
examples. Anything else is a ways down the track.

--
Craig Ringer