On Wednesday 16 February 2005 18:24, Nik wrote: > Hi All, > > I realise that the Scribus community uses PDF for particular > reasons, and so this may be a little off-topic. > > However, I have struggled this week with various PDF documents I > have received that are incompatable with my various PDF readers in > a variety of ways.
No, not off-topic and probably well worth expanding upon... In almost every case I have seen wrt to Scribus, its the reading application which fails. Other applications may not write PDF which is as conformant or advanced as Scribus. There have been many many posts, on the mailing list, as well as bug reports about PDF viewers not handling Scribus PDFs. I've said this many many times: If a PDF viewer cannot view a Scribus PDF, in almost all cases is a bug or unimplemented feature of the viewing application. I have added notes to this effect in 4 different places in the 1.2.2 docs. > > What is needed is a document format that is designed for the easy > and accurate exchange of documents. Sadly, Adobe are taking PDF in > much same direction that Microsoft took the Word file-format, where > frequent changes to the format meant that folks were forever > playing version catch-up. > I have to disagree with that. Each PDF version change has been very well documented by Adobe and in the case of PDF 1.5, a draft was public before implementation. A rough guess is there are more than 3000-5000 pages of reference docs,specs and sample code on PDF available from Adobe. FYI, the PDF references and errata are easily found on Adobe's web site. While Adobe is a commercial proprietary company, the PDF specs and file format are both extremely well documented and come with few real restrictions on use - mostly the requirement to honor the encryption restrictions placed by *the author* not Adobe. > I realise that Adobe always intended to make money from the PDF > format, and that changes to the format are a natural way for them > to accomplish that, but if I can't successfully read the PDF > documents that I receive or download, then PDF is no use to me as a > portable document format. File bug reports with those viewer and attach the unreadable PDFs. Because Scribus has such a powerful exporter, far more capable than even many expensive proprietary apps, we get more reports about 'incompatible' PDF from Scribus. I and others test Scribus PDF regularly for conformity using expensive DTP pre-press tools and pre-flight checking tools. If something is not right, it gets fixed quickly and it rarely happens anyways. The state of open source PDF/EPS/PS viewers is a mixed bag. IMO gv and most of its derivatives are obsolete, broken and not very useful. I am glad that RH has finally dropped gv from FC-4 -its a dinosaur, it's ugly and long been unmaintained. I've not installed gv since I discovered GSview and the understanding that the latest Ghostscript versions are *much* improved in PDF viewing/rendering. The Artifex developers have put a lot of time into improving GS's capabilities with PDF and it shows. Thus, there are a few of us who are working with distro maintainers, CUPS and GS devels to get updated Ghostscript GPL 8.15 into mainstream distros. Its not a trivial task however. Having a newer GS will greatly improve the PDF experience for end users. There are many unfixable bugs in RH and Mandrake, which await a newer GS. On the other hand, there are signs of progress: KPDF in KDE 3.4 is *major* improvement. Their devels 'get it'. Based on Xpdf 3.00, it fixes many of xpdf's weaknesses and adds additional functionality with more to come. I say that not wanting to sound like a kde fanboy, but a few minutes using this will probably convice the most die hard KDE hater how much it has improved. ;-) > > What I am looking for is a document format that is open enough that > anyone who wishes can build a reader and/or creator for it can. The > format needs to have similar power and abilities to PDF. The format > should also be "XML compatable", in that if it isn't stored in XML > (which does compress fairly well), then it should be easily > rendered into XML, so that a text editor can be used to make > changes. > One of the methods PDF uses to compress documents is the file format is non linear in part. Also the use of postscript directives is very efficient space wise. What makes PDF hard to edit directly is the need to create crc like directives based on file size to ensure file content is not corrupted. Yes, it could be better, but PDF, like PS was never envisioned to be an easily editable format. In addition, you can add XML like features such as XMP. One look at: http://partners.adobe.com/public/developer/xml/topic.html , should give you a wealth of specs and references for using XML with PDF. One of the interesting things to see watch with the development of Scribus is the reaction of 'script it, edit it in $editor' mentality developed over long years in *nix, when faced with a highly graphical app like Scribus. :) Yesterday, there was some interesting comments on lwn about the recent story in Linux Journal about using TeX and friends.... I do know and understand the power of the command line - one of the real assets of moving to Linux and Unixes. However, its hard to learn for many, its not perfect and far from efficient for some things. However, there is room and a need for both. Scribus fills that WYSIWYG niche quite well I think. > I am aware of SGML Document Interchange Format, but SGML seems to > have gone out of favour. Does anyone know of a format that fits the > requirements I've described, or could be made to? > > All replies gratefully received. > > Cheers! > Nik. When I first saw Scribus in its early 0.3.x versions, the best design decision Franz made was to concentrate on powerful PDF export in a way that mere mortals can use. I think he's succeeded far far beyond what anyone could have expected in those days. Cordially, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20050216/4d24b210/attachment.pgp
