https://bugs.documentfoundation.org/show_bug.cgi?id=32249
--- Comment #34 from V Stuart Foote <[email protected]> --- (In reply to Eyal Rozenberg from comment #33) >... > This illustrates that, at the bottom line, LO is a PDF editor, and in fact, > is _the_ PDF editor for users who aren't experts in locating software. > > It also illustrates how addressing this issue will make both LO and FOSS > desktop environments more attractive to users. Nope! It again illustrates the bottom line that PDF (ISO 32000-1:2008, or 2:2020) is NOT an editable format, it is a presentation/publication format. Also, it demonstrates reality that LibreOffice is not a PDF editor as we will only ever read content of a PDF to filter import to an ODF XML compliant document canvas. Fidelity of the filter import varies (poppler to sd Drawing objects, or pdfium as image/meta streams as image to a vcl canvas), but in no sense do we do more than read from PDF. Export/print from ODF module to PDF is then a completely different process with a different set of export filters. And it highlights the project's need to scrupulously manage user expectations reinforcing that PDF is not an editable format, and that LibreOffice is NOT a PDF "editor". Improvements can be made to LO filter handling as a PDF reader to import content--witness the adoption of pdfium libs for the insert as image filter paths. But simply put, the internals of the presentation optimized text runs within PDF do not support extraction with the lexical syntax of the original source document from which a PDF was generated. We can provide tools to better organize results of the import filters, reformating them into either paragraph objects or sd draw objects--but there are very real limits to what the project can or should do. -- You are receiving this mail because: You are the assignee for the bug.
