On Wed, May 28, 2008 at 2:21 PM, chasd <chasd@xxxxxxxxxxxxxx> wrote: >> *Tools used*: >> >> • gnome-games.i386 1:2.22.1.1-5.fc9 >> • cups-pdf.i386 2.4.7-1.fc9 >> • cairo.i386 1.6.4-1.fc9 >> • evince.i386 2.22.1.1-1.fc9 >> • AdobeReader_enu.i486 8.1.2-1 >> • inkscape.i386 0.46-2.fc9 >> • selinux-policy.noarch 3.3.1-55.fc9 (this will make sense later) > > From your tools list, it would be better to create them with InkScape to > begin with, and bypass PDF. > A PDF is not considered an editable format, even though there are tools that > allow it. > Editing PDFs gets messy quickly. Thanks for the feedback. Well ... there are times when all you have is a PDF as the source material to work from. So it is certainly nice to have the refined tools to dig into the contents and modify things. But as I am trying to illustrate with this simple example, the PDF generation that is available to all apps that can print has some issues also. There is also a bit of a correction. I mistakenly thought that gnome-print uses cairo as a backend to generate PDFs. From what I understand now, it does it all itself internally so blame or praise in my test was falsely placed on cairo and should be on gnome-print. I guess I have to read more about how all the pieces fit together ... > This is configurable in /etc/cups/cups-pdf.conf > There are several options there which could solve the issues of where the > file is written, the user that writes it ( not sure about context ), and the > filename. Thanks ... I'll take a look. >> • Imports incorrectly in Inkscape > > InkScape just got PDF editing support, it isn't going to be as good as Adobe > Acrobat. No doubt. I found that Inkscape does an excellent job as a first iteration though and was hoping to point out some places it doesn't. I have a personal project underway that is taking PDFs and adding editable PDF form fields on top. I have found that using Inkscape to convert the PDF pages to SVGs and import those into Scribus where I can add the form fields and some simple javascript gives OK results. The SVG font translation into Scribus 1.3.4 is not so stellar though. I am hoping that 1.3.5 is better. >> • multiple of binary streams when viewed in text editor > > A valid PDF can be binary encoded. You may not want that, but it is valid to > the specs. > Also note that a valid PDF can have edits appended to the end of the file > that over-ride something in the body, and there is a checksum involved so a > parser knows it got all the data, you can't just "cat foo >> bar.pdf" and > have it work. A PDF may look like a simple ASCII-based format ( sometimes > anyway ), but it much more complicated than that. Doing the overlay/substitution thing is more appropriate in many situations but not all. Xournal does this quite nicely with its PDF Annotation functionality. I wish I could do this also with Scribus in my project described above as I am simply adding new content but the importing of PDFs in Scribus is .... marginal. However, you are always increasing the file size this way and increasing the rendering time. >> Printing with Ideal Fictional Dream PDF Printer: > > Print to SVG or the PDF-Mars format instead. > <http://labs.adobe.com/technologies/mars/> > Mars uses XML as the file format for PDF instead of the traditional PDF > gorp. The Mars file format uses the "zip-it-up" ODT format, and has > everything described as XML referencing each page as an SVG. Although there > are few Mars tools available right now ;) That would be the problem. Is there a package in the Fedora distro that will enable a "Print to SVG" option? /Mike -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
