https://bugs.documentfoundation.org/show_bug.cgi?id=48459
--- Comment #31 from László Németh <[email protected]> --- (In reply to RGB from comment #25) > I'm reopening this issue to discuss the viability of the recently > implemented solution: I suggest to reopen Bug 46023 (I planned to do that) for a general, style-level, ODF-enhancement-based inline heading support. This bug is only about basic/core inline heading support. The good thing, that these are not mutually exclusive. The solution for the basic inline heading support can be part of the style-level solution, too. > > 1- As shown in Bug 163650, the use of frames to simulate inline headings > creates problems when those headings are numbered. Because every single > example I've ever came across for "inline headings" uses numbering, this > issue alone renders the proposed solution invalid. Single level numbering is supported. Multiple-level numbering would be a nice enhancement, at least, over OOXML/MSO interoperability, because it seems, MSO doesn't support multi-level numbering either (it does exactly what Writer is doing now according to my investigation). > > 2- Specially when using multi-column layout, a normal heading could easily > take more than one line, breaking the text flow and making the proposed > solution non functional (the frame will take the whole paragraph width, > pushing the following text to the next line and breaking the "inline" > feature). This means only that in corner cases, we got the same behavior, as before. As I mentioned at the end of Comment 29, it's possible, that this is only a layout problem, and we can interpret/fix Writer layout for variable-width multi-line frames anchored as characters as Firefox/Google Chrome do with display:inline <div>s, i.e. following the end of the inline heading "within" the frame, i.e. without breaking "inline" feature. It's worth to note, that with the recent fixes, DOCX import and export works, as intended: The exported DOCX document contains OOXML-compliant inline headings (style separators), opened without interoperability or layout problems in MSO. Also similar (X)HTML/CSS-compliant export is achievable with the recent workaround. > > 3- The proposed solution is not a proper one, but a workaround. The only way > to achieve a proper solution would be a change in how Writer processes > paragraphs, allowing a paragraph break without a line break (LaTeX does > exactly that). With the last patches, also on the basis of the above, this is more, than a workaround. This is already Writer core and DOCX filter enhancements, so no need to install extensions. It solves also OOXML interoperability, it will solve HTML export, PDF bookmark export etc. problems soon, and likely can be an excellent base for the future ODF/UX extensions. > > I know that ODF does not, at the moment, allows the implementation of a > proper solution, but workarounds should not be presented as proper > solutions, even if there are no proper solutions in sight, because > workarounds *always* break. And as discussed above, this particular > workaround breaks quite easily. For that reason I ask the developers to > consider retracting the patch. > > Workarounds (there are more than one for this issue) could be packaged as > extensions. Adding a boolean variable "inline" to ODF paragraph settings, automating/creating/removing/hiding the frames, fixing frame layout seem for me the simplest way to create the style-level inline heading support. But this won't solve that MSO still contains a workaround for the multiple inline headings in the same paragraph layout (based on special character styles). The bottleneck is the development, related to the highly complex Writer core, and we must choose the priority: better interoperability, i.e. full support of MSO's own workaround for inline headings, or continuing with more HTMLish/style based, standard-friendly approach. I think, it's easier to get support for interoperability. -- You are receiving this mail because: You are the assignee for the bug.
