80

There is no qt4 program that will edit PDFs and I think KDE really needs it. I also would like it if the devs made sure to get the feature in okular for konqueror also. If this will make Okular bloat I would rather just have another utility to edit these to types of files (especially PDF {postscript would be a bonus})

Thanks

Maybe KDE should invest a little into GNU PDF to make this possible. It could draw some people to KDE if it had the first [usable] open source PDF editor. Also thanks for voting.

What about Lyx?
AFAIK it can edit postscript. Not sure about PDF.

stephenmac7 wrote:Maybe KDE should invest a little into GNU PDF to make this possible. It could draw some people to KDE if it had the first [usable] open source PDF editor. Also thanks for voting.

Inkscape can edit PDF's (well, at least single pages), and I do consider it quite usable...

The corresponding application in KDE world would be Karbon (part of KOffice), and apparently it also has a PDF import filter now, but I haven't tried it yet.

Lyx? Hmm, that is a WYSIWYM document editor. Also I am asking for it to edit large pdfs (100-500 pgs) and also to create pdfs.

stephenmac7 wrote:Also I am asking for it to edit large pdfs (100-500 pgs)

If you only need to make a small change (e.g. delete/insert a picture, change a color, etc.) in a large PDF document, you can load the individual page on which you need to make the change into Inkscape (or Karbon), edit, and save it to a new (single-page) PDF file.
Then you can use one of the free open-source command-line PDF toolkits (Pdftk, PDFsam, PDFjam, ...) to re-assemble your PDF with the edited page substituted.

A more streamlined work-flow (e.g. for multiple changes throughout the document), would be:

1. Burst the PDF, e.g.:

   Code: Select all

   pdftk "old.pdf" burst output "pages/page_%02d.pdf"

   
   
2. Make changes to individual pages
   
3. Join the PDF, e.g.:

   Code: Select all

   pdftk "pages/*.pdf" cat "new.pdf"

   
   

stephenmac7 wrote:and also to create pdfs.

For that, you can just use use KOffice or OpenOffice.

I am making large edits and also it would just be very, very helpful also no one really wants to pay $500 for Adobe Professional and not even be able to use it on GNU/Linux. It is an idea! Your criticism of the idea is like saying there is no need for a file manager because you can use the coreutils to do it in the command line!

stephenmac7 wrote:It is an idea! Your criticism of the idea is like saying there is no need for a file manager because you can use the coreutils to do it in the command line!

I'm not trying to criticize, I'm trying to be realistic.

There's a very simple reason for the lack of usable PDF editors: The PDF file format just wasn't designed for editing!

It's not a word processor file format like DOC or ODT, it's a document exchange format designed for publishing or exchanging finalized documents.

The information stored in a PDF is closer to what gets sent to your printer, than to what gets stored in a word processor document file.

Consider the following example:

Say you open up a word processor and create a document that contains a paragraph of free-flowed text with justified alignment, and on top of it you create a colored star shape for which, in the shape settings, you choose the option to make the surrounding text neatly flow around it.

Now, when saving to ODT (or any other structural document markup file format) on the one hand, and saving to PDF on the other, very different information gets stored:

When saving to ODT, structured information about the objects contained in the document is stored:
-----------------------------
- A page object with margins so-and-so and background so-and-so, containing as sub-objects:
- a free-flowed paragraph (with alignment "justified", additional paragraph formating so-and-so, and text content such-and-such), and
- a shape object (with shape type "star", text-wrapping type "wrap text around shape", position and size so-and-so, and additional formatting such-and-such).
-----------------------------

This allows any ODT-capable software to "reconstruct" the original appearance of the document - both for viewing and for editing - by drawing the star object as specified, and taking the paragraph text and flowing it across the page and around the star shape as described in the document file.
So when the user re-opens the file at a later point and adds text to the middle of the paragraph, the word processor still knows to treat the whole text as a free-flowed paragraph, and to wrap it around the star shape as expected.

When saving to PDF, the information making up the high-level ("logical") document structure is lost, and only the low-level ("physical") markup is retained. Let's say the free-flowed paragraph in the above example begins with the word "Hello". Then the information stored in the PDF would be of the form:
-----------------------------
- A page with geometry so-and-so, and on this page:
- a character "H" at position so-and-so
- a character "e" at position so-and-so
- a character "l" at position so-and-so
...
...(and so on, for the whole text)...
...
- a vector path with coordinates so-and-so, stroke so-and-so and fill color so-and-so
-----------------------------

A PDF viewer can read this information and draw the corresponding document very quickly and accurately. It doesn't suffer from the problems of word processor formats like ODT, for which e.g. different viewers or editors might have very slightly different text flowing/wrapping algorithms, which might potentially "break" the layout of the document when opened with a different viewer or editor, or on a different operating system platform, than the one it came from. PDF's look the same everywhere, because there's no logic involved in drawing them: it's just like printing on screen.

However, this means that a program won't (easily) be able to present the PDF document in a form suitable for editing: How should it know how all those characters and other objects sitting at certain positions on the page logically make up continuous text that's merely flowed and wrapped in a peculiar way?

Inkscape, when loading a PDF page, already applies some simple heuristics to join adjacent characters on the same line into a single text object.
Anything more than that would be just (very, very complicated, and probably still insufficient) guess work.

(Disclaimer: I'm not a PDF expert myself. If someone around here is, please correct me if I got something wrong.)

I see what you mean. When I create PDFs in the first place I do it with latex but if I download it as a PDF I have no latex code, therefore needing to edit the PDF. Thank you for clarifying this for me. Again I wrote this as a idea for making Okular more useful.

Well, I suspect that even if the KDE developers do find a way to somehow provide proper PDF editing support, they'll probably prefer to offer this functionality in KOffice rather than inside Okular, which is supposed to be a document viewer, not full-fledged editor. (You never know, of course... After all, it already has PDF annotation support...)

In any case, don't be discouraged - users who share ideas about how KDE could be made better are certainly appreciated in the KDE community...

Regarding PDF editing in Okular:

Thinking about it some more, I think one thing that really would be kinda neat to have in Okular, and certainly technically possible, would be "page operations" like removing pages, or rearranging the order of the pages in the document.

Since every page in a PDF is basically a stand-alone document (I think), this should be possible.

I'm imagining an "Edit >> Page Operations" menu, with the following (and possibly more) actions:

- remove current page
- move current page within the document
- insert another document before/after the current page
- open current page as new document

Maybe a separate brainstorm thread should be opened for this though...

That would be nice... to have a page operations menu. I do agree that this could go into koffice somehow. I use koffice but do not know if it should be in kwrite or in another program such as kpredi (Horrible name but that was just an example). Then again as you said.. you never know.

Well, I still am not sure about the status of this... is it just going to sit here?

No one?

I really agree. KDE needs urgently a pdf editor. Linux in general needs one...