Helge Hielscher schrieb: > On Sun, 21 Sep 2008 15:04:25 +0200, Benjamin Dumke wrote: >> 2. You have to be able and willing to dig into the source code. Using a >> precompiled version, I could not have worked on this project, as there >> where several things I stumbled upon that simply were not working for me, >> and that I had to have changed, obviously without waiting for a fix in the >> official svn version, if one were to happen at all. So I am using >> 1.3.5svn, but I'm using it with some changes applied, including changes in >> the hyphenator and the object placement algorithm, as well as additions to >> the scripter and the "Move Pages" dialog. > > Are these patches available somewhere?
My patch to add a "swap pages" function is attached to issue 7388 in the bug tracker. Issue 7389 describes another thing I changed and why I did so (without a patch, though). Apart from a small thing (issue 7429) that has been applied in the meantime, I have not submitted any other changes I made. This is why: Since I'm not a developer, the source code to me is tens of thousands of C++ lines of which I only try to understand those few lines that might do what I want when I change them. Then I do change them accordingly, and when it seems to work, I leave the change in. But just because it *seems* to work doesn't mean it really *does* work (in the sense that it doesn't break something else). An example: I wanted to use optical margins, which did not seem to work at all. I checked the code, and somewhere I found something that seemed weird (in my interpretation of things), so I changed this small thing (one single character, actually), and suddenly I had working optical margins. But this "weird" thing was probably there for a reason, and by changing it, I might well have messed up something else that I just haven't discovered yet -- after all, this is a development version. When I'm done with my mentioned project, I will have more time to look into the code and to discuss this with some devs. But until then I don't know if this even is a bug, and that's why I don't want to make this patch public. > >> 3. You have to know your other tools to use as well as know a few things >> about the PDF standard itself. Scribus (in any version) is not -- nor ever >> will (or should!) -- be a one-for-all tool. One great improvement that >> entered the svn version a few months ago was the ability to embed >> exisiting PDF files into the newly created PDF. Having lots of >> advertisements, most of which I receive as PDF files, this possibility is >> invaluable. However, while Scribus-created PDFs can usually be trusted, I >> cannot trust every single PDF I receive in terms of standards conformance >> et cetera. Since Scribus "only" embeds these PDFs as XObjects, anything >> that is wrong with the one small PDF is now wrong with the whole document. >> Hence I use a combination of Adobe Reader (not free, I know -- except as >> in beer --, but still a very important tool), ghostscript, podofo, and >> possibly others, to end up with a flawless PDF. > > Would you please describe it in more detail? Most resources about checking > PDFs are about Acrobat, PitStop, PDF-Analyzer, etc. - closed source tools > for Windows. I was not referring to preflight checking, but to producing. This has a lot to do with trust: When I have a PDF that is messed-up in one way or the other, and I give it to the Adobe Reader (which is quite relaxed when it comes to standards conformance), have the AR convert the PDF to a PostScript file, I trust that I have a "good" PS. When I then use ghostscript to do a PS->PDF conversion, I trust that I have a "good" PDF (and, for that matter, I also have a transparency-flattened PDF, which might or might not not prevent some problems with your print service). Since I do trust AR and GS to do the right things (when given the right parameters), this is enough preflighting for me. I have yet to be disappointed :-) Greetings, Ben
