https://bugs.documentfoundation.org/show_bug.cgi?id=166835
--- Comment #14 from Eyal Rozenberg <[email protected]> --- (In reply to Mike Kaganski from comment #13) > Note that this needs a never-ending track of what is supported, and what is > not - both because the file format does not support it, and because we > didn't yet implemented it; with every change in the code (fixing an > interoperability bug; introducing a new feature); for a potentially > unlimited number of file format (which are, basically, black box from the > module's perspective: a file format is just a filter, which is pluggable, > and provides means to import and export, and can come from extensions). This point is well-taken. The question is, can this "chasing after our own tail" be circumvented somehow. That is, when we actually export to a certain format, there is effectively some sort of filter deciding what gets massaged into output and what gets discarded. If that filtering is not implicit (e.g. in opaque code which gets XML and produces a stream of chars constituting a DOC or RTF or whatever), but rather explicit/formalized somehow (e.g. set of exported and discarded XML tags) - then that same filtering might be used to implement this feature. And if that's not possible - another option is a lightweight "dummy save" procedure which just invokes the export code without actually saving a file. And if that's not possible either - then maybe WONTFIX. But I feel you're a bit too quick to dismiss this. > The only potentially implementable approach is - checking when saving; and > that would depend on the filter doing that job. We can introduce hooks > allowing filters to report the issues, but not much more. So, I hope I may have suggested how we might be able to do more than just hooks in output filters. -- You are receiving this mail because: You are the assignee for the bug.
