(In reply to Mike Kaganski from bug 49697 comment 31) > ...We do not edit PDFs. We have PDF only in Export > dialog, not in Save (As); and that basically means, that application tells > to users, that they import a PDF as Draw document, but when export the Draw > document as PDF, they create a completely new document, unrelated to the > original one - if it has the same name, it simply drops the old, and creates > new. We do *not* claim we edit PDFs. If needed, we may want to emphasize it > in the UI, but that is what it is. > > And additionally, *if* we ever make PDF filter the first-class filter, i.e. > move it from export to save (as): then we need to treat the save protection > the same way as we do for ODF. Save an ODF with only a password for editing > (open file read-only + pw; no open password = no encryption), then open it. > It will not ask any passwords on opening, and will just set the UI to > read-only; this is what would have to happen here as well. Average user likely understand the distinction as academic and expect a "file" to be opened and saved. Plus, if this is done with the user in focus we probably have to open the document in the current module, ie. Writer in most cases, with a fallback meaning startcenter resp. soffice to Draw. Otherwise this report could serve as a reference to the FAQs.
Start with gathering all the PDF features that we don't support, and that any user would definitely expect from a PDF editor (like form filling: meaning, that the software doing that must keep the PDF structure, and put the filled data into the correct form, so that applications processing filled forms would understand it).
(In reply to Mike Kaganski from comment #1) > form filling: meaning, that the software doing that must keep > the PDF structure, and put the filled data into the correct form... We do have similar workflows and could open the PDF (if containing form elements) in a view mode that allows to change only the content.
(In reply to Heiko Tietze from comment #2) So do you suggest to introduce a new "first class" filter, which would open PDFs in a dedicated "view mode", and only allow form filling? Because it would be something completely different than what we have now.
Just collecting ideas and pondering over expectations. The view / forms edit mode sounds reasonable.
PDF is not an "editable" format. Rather it is a presentation and exchange format (its roots in the PostScript page description language) to represent documents, including text formatting and images, in a manner independent of application software, hardware, and operating systems. It is a final fixed output destination, user *touch-up* is possible (but why would project need to, if we are creating/editing the source ODF document?). So just NO. Instead continue to improve current dichotomy of good import filter (for each ODF module) as new source content for new/existing ODF documents, and of good export filter(s) to output ODF documents. But make no efforts toward PDF as a directly manipulated format--it is out of scope of project. PDF form filling is a specific process, and filling interactively or from an ODF source table, i.e. Base or Calc, might be worth pursuing. But that would likely be pdfium based, not cairo/poppler. But that is not this ask. IMHO => WF
Heiko, the title and the opening comment, especially the first paragraph, do not make it clear enough what this bug is supposed to be about. Nor whether this is supposed to be a meta-bug or a concrete bug. If this is a meta-bug at least in part, there are already a bunch of existing issues which should block it. I'll also make two other comments: About "editing PDFs" -------------------- - I talked about this in LibOCon Bucharest 2023: https://events.documentfoundation.org/libreoffice-conference-2023/talk/JDSEVU/ Slides: https://events.documentfoundation.org/media/libreoffice-conference-2023/submissions/JDSEVU/resources/LO_as_PDF_editor_sbZDN5T.pdf Video: https://www.youtube.com/watch?v=98yX0JRHFbQ in a nutshell, LibreOffice is what many people use, or try to use, to "edit PDFs", regardless of whether we want to call it a PDF editor, so the better we support editing PDFs, the more we will help users achieve their goals and the more we would be appreciated as an app. And vice versa. Two different kinds of PDF editing ---------------------------------- This bug is focused on a PDF as the baseline form of a document, with opening and saving expected to retain as much of its structure as-is, and make sure to use its built-in facilities/allowances for various kinds of contents. But - a second kind of PDF editing is when the PDF is thought of as a result of an export from a less-final, more human-editing-oriented format like ODF or OOXML. In those cases, the user has a _conflicting_ expectation, which is the reconstruction of as much as possible of what can be inferred to be the original document's structure and features which are not directly available in PDFs. Both are valid user interests; but they are conflicting in terms of how an import filter, and perhaps even an export filter, should behave in order to adhere to each of them.