https://bugs.documentfoundation.org/show_bug.cgi?id=143095
--- Comment #23 from Eyal Rozenberg <[email protected]> --- (In reply to V Stuart Foote from comment #22) > (In reply to Eyal Rozenberg from comment #20) > > Doers decide, and the PDF filters are most definitely not core to the > project. > > So, looking forward to read your code contribution Actually, I had given some thought to may dipping my feet into the LO code; not on this issue, elsewhere; but I was rather offput by the constraint of relying on a lot of old and outdated fundamental code in the name of a frozen interface vis-a-vis extensions. Regardless, it's only half-true that doers decide: There are user needs and interests; there's the TDF; the ESC; there is the design team and perhaps other bodies... those all affect decisions. Also, who knows? Maybe this could be a tender. > --since this will require > a complete refactoring--including likely replacement of the poppler/cairo > and xpdf object import framework with a pdfium based implementation direct > to vcl canvas and ODF archive. I didn't say this is an "easy hack" or something I expect to happen overnight. I mean, even the import filters for MSO formats isn't properly sorted out w.r.t. tables and RTL and a bunch of other things. But it's important that we point clearly in the direction in which to progress. > And as a reality check reminder, we do not edit PDFs, we can only apply > filters to parse their content. And after manipulation in an LO module we > generate a new PDF via export filter. That's how we edit DOC files, and that's also how we edit PDF files. -- You are receiving this mail because: You are the assignee for the bug.
