[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 V Stuart Foote changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #22 from V Stuart Foote --- It was confirmed, but a clear => WF of OP or later comments where attachment 196061 needs to be edited for line ends prior to import. Other than WF here--two paths forward, either enhance the Writer Web module and its filters to parse current CSS and HTML5 and write out viable CSS/HTML5 content. Or *dump* Writer Web module and its HTML4 Transitional implementation completely, instead refactoring the filters to import Web documents into the core modules and implicitly converting them to native ODF. Export as/print to HTML/XHTML to handle publication, just like PDF and EPub. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 Dieter changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 Buovjaga changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #21 from Robert Großkopf --- (In reply to Heiko Tietze from comment #20) > (In reply to robert from comment #18) > > Writer cannot even import the plainest of plain HTML... > Wouldn't call it simple. But let's check the details. > > The first line ends with " To " > followed by "| +-- <...snip>". I see no line break such as , , or > #13. What exactly should the HTML filter accept as line break (or IOW what > is the standard here)? Seems the import filter doesn't know anything about "white-space" With option "pre" it will accept all spaces and won't set more than one space to one. It will also accept or \n. Also import filter ignores display:none. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #20 from Heiko Tietze --- (In reply to robert from comment #18) > Writer cannot even import the plainest of plain HTML... Wouldn't call it simple. But let's check the details. The first line ends with " To " followed by "| +-- <...snip>". I see no line break such as , , or #13. What exactly should the HTML filter accept as line break (or IOW what is the standard here)? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 rob...@prino.org changed: What|Removed |Added CC||rob...@prino.org --- Comment #19 from rob...@prino.org --- Created attachment 196061 --> https://bugs.documentfoundation.org/attachment.cgi?id=196061&action=edit Writer cannot even ender the simplest of simple HTML... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 rob...@prino.org changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #18 from rob...@prino.org --- Writer cannot even import the plainest of plain HTML (see the attached), which is rendered perfectly OK, even with Word XP, dating back from 2001. However, what's worse, it actually opens the link, which in this case is harmless, but might, in other scenarios, pull in all kinds of nasty stuff. If you want to compete with this other office suite, you need at least render such simple html correctly! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #17 from Heiko Tietze --- All comments vote for WF. One the one hand we want to support as many formats as possible and do have support for HTML but on the other we surely cannot catch up with Internet browsers. We might be able to improve in some area but likely not in case of complex layouts. So the recommendation is to create a more simple document that LibreOffice can load rather than spending a lot of effort. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #16 from jan d --- WONTFIX also makes sense to me. > The utility of LibreOffice as an HTML4 editor continues to degrade. yes – > There are ongoing suggestions to remove the Writer Web module. > And to instead improve the import filters for importing to Writer, > Draw, Impress, or Calc as ODF only documents. Makes sense to me and seems to be easier to handle UX-wise, too, since it would be an import/export, just like the other formats. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #15 from Buovjaga --- (In reply to Buovjaga from comment #14) > If you look at the source document, it uses position:absolute, floats, > display:inline, percentage widths, max-width, margins. All of these are > specified in the CSS standard to work and play together in a certain way. Just to clarify as there was a misunderstanding in a chat channel, I think this report should be closed as wontfix due to being unrealistic. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #14 from Buovjaga --- (In reply to Heiko Tietze from comment #12) > I think key is the anchoring of images that we do 'To Character', by > default. At least after opening Writer with the document as parameter > (loading via Ctrl+O stalls infinitely; and opening from the start center > runs the document in Writer Web) and manually switching the anchor from 'As > Character' as it always is (obviously ignoring tools > options > writer > > formatting aids > image anchor) brings text next to the image. > > Ultimately we will not reach pixel-perfect representation, as browsers with > different engines works differently. How about using a table in the HTML > sources? If you look at the source document, it uses position:absolute, floats, display:inline, percentage widths, max-width, margins. All of these are specified in the CSS standard to work and play together in a certain way. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=95 ||861, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||5282, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2204 CC||vsfo...@libreoffice.org Blocks||103302 --- Comment #13 from V Stuart Foote --- Review the see also list for discussion of what would be needed to move forward from the LO filter support of HTML4.0 transitional and CSS 1.1 styling, to make LO relevant for current W3C/WHATWG web standards. There are ongoing suggestions to remove the Writer Web module. And to instead improve the import filters for importing to Writer, Draw, Impress, or Calc as ODF only documents. With corresponding export filter work to render ODF back to web content. The utility of LibreOffice as an HTML4 editor continues to degrade. So there is nothing actionable here for the HTML of the OP (and here we simply don't handle the class= positioning of the embedded css on filter import). IMHO => NAB and => WF for any effort to address this single issue. Dev's with UX-advise agreement should decide what to do with the Writer Web module. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103302 [Bug 103302] [META] Writer's web layout/view bugs and enhancements -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #12 from Heiko Tietze --- I think key is the anchoring of images that we do 'To Character', by default. At least after opening Writer with the document as parameter (loading via Ctrl+O stalls infinitely; and opening from the start center runs the document in Writer Web) and manually switching the anchor from 'As Character' as it always is (obviously ignoring tools > options > writer > formatting aids > image anchor) brings text next to the image. Ultimately we will not reach pixel-perfect representation, as browsers with different engines works differently. How about using a table in the HTML sources? (In reply to Buovjaga from comment #11) > Then we should ask design team, if they think LibreOffice should include a > web browser competitive with the major players and also to adapt our > document model completely according to the requirements. We shouldn't include a complete browser. But since we are proud to filter data from almost any source, we need to support HTML too. At least the basic features. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 Buovjaga changed: What|Removed |Added Ever confirmed|1 |0 Status|NEW |UNCONFIRMED Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #11 from Buovjaga --- (In reply to Robert Großkopf from comment #10) > The behavior is confirmed. LO isn't designed for creating web pages or > browsing through web pages. So this might be an enhancement request. Then we should ask design team, if they think LibreOffice should include a web browser competitive with the major players and also to adapt our document model completely according to the requirements. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 Robert Großkopf changed: What|Removed |Added CC||rob...@familiegrosskopf.de Severity|normal |enhancement Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #10 from Robert Großkopf --- The behavior is confirmed. LO isn't designed for creating web pages or browsing through web pages. So this might be an enhancement request. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 Armondo Lopez changed: What|Removed |Added CC||armlo...@csumb.edu --- Comment #9 from Armondo Lopez --- I can confirm that this behavior is still present in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded and Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #8 from Buovjaga --- (In reply to Dieter from comment #7) > (In reply to Buovjaga from comment #6) > > LibreOffice is not a web browser. LibreOffice's document model can not be > > mapped to the layout capabilities of browsers. > > I agree, but what does it mean for this report? It means the request in this report can't happen unless we get the ambition to do web layout in Writer. I don't know how that would work, but everything is possible. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 --- Comment #7 from Dieter --- (In reply to Buovjaga from comment #6) > LibreOffice is not a web browser. LibreOffice's document model can not be > mapped to the layout capabilities of browsers. I agree, but what does it mean for this report? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154434] FILEOPEN HTML: Writer loses HTML layout
https://bugs.documentfoundation.org/show_bug.cgi?id=154434 Buovjaga changed: What|Removed |Added CC||ilmari.lauhakangas@libreoff ||ice.org Summary|FILEOPEN HTML: Writer loses |FILEOPEN HTML: Writer loses |HTML style formating|HTML layout --- Comment #6 from Buovjaga --- LibreOffice is not a web browser. LibreOffice's document model can not be mapped to the layout capabilities of browsers. -- You are receiving this mail because: You are the assignee for the bug.
