https://bugs.documentfoundation.org/show_bug.cgi?id=48887
--- Comment #51 from V Stuart Foote <[email protected]> --- (In reply to David Spring from comment #50) Sigh... you really are missing the point. No one disputes that there was a wrong turn 54 months ago in implementing an *unconditional* use of data URI (RFC 2397) especially as the Writer import filters were not adjusted to handle that format round trip--making the Writer/Web mode pretty much useless from that point. Import filtering has been restored, but the Writer/Web canvas still needs dev attention to render the markup for the <img src:data... > URIs. But, in point of fact the XSLT based export of ODF documents to XHTML has received prolonged dev attention and provides much better fidelity to the original ODF document than the Writer/Web and HTML export filter has ever achieved. You say your goal is generating ePUB, have you even tested the LibreOffice XSLT export to XHTML as source document for Sigil conversion to ePUB? In that scenario LibreOffice Writer becomes the editing and layout environment--the XSLT conversion generates the fully styled XHTML. Yes the images are embedded base64 there also. But, you would not need normally to tweak the XHTML code directly--but could do so against the XHTML using your markup editor of choice. LibreOffice's XSLT generated markup is XHTML tagged as <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd";> DTD, as opposed to the Writer "save-as" filter which retains its mislabeled legacy <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> DTD. Writer/Web has been a poorly maintained module. This all will get sorted out in some fashion--likely as Andras T. outlined in comment 40. Restoring correct handling of the per document embedding of images in the source ODF--and protecting that linkage and file naming during export to HTML. With this issue, and bug 88038 and bug 95861, as set at appropriate priorities this will be worked out in some fashion. But should note it is entirely possible that in the end we strip out the Writer/Web module as unsupportable while bringing the HTML "save-as" export/import filter more in line with performance/fidelity of the XSLT conversion available in that export module. Ending the illusion of LibreOffice as an HTML code editor. The swhtml filter may even be consolidated with XSLT processing which also could be improved upon. But those are implementation decisions for the dev(s) that elects to take on the task. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
