LO Writer Web view is excellent for writing with less distractions.
The text you write nicely fills the window space, and no screen space is wasted on margins and paper limits. Also, you can see what you write at whatever size you find comfortable at any moment, untied to line lengths and margins in a physical sheet of paper. This is especially important when working on a small screen or in a window.
The issue is that the columns setting carries over to the web view. The way it does it makes no sense: web views have no intrinsic length, but the Web View splits the text in pages of seemingly random length, and those page breaks are shown on screen, which shouldn't happen in a web view.
But most importantly, the column split, which doesn't seem to be right, also ruins the no-distraction writing. You end up with only half the window for writing, with the other half either empty or filled with unrelated text.
You can fix this by setting the format to single column, but it carries over to the normal view, so later you will have to set the right number of columns again for printable output.
The simplest (and maybe the best solution in my opinion) would be to simply ignore the column settings in Web View.
A setting in the View menu could be added, in case somebody actually relies on the current behavior.
A new "Writing" view could be added, which was just Web view without the columns. This could open the way for a more configurable writing view with the possibility to remove more visual noise.
Steps to Reproduce:
1. Write text in two columns in Normal view.
2. Switch to Web view
3. Change columns to one
4. Switch to Normal view
5. Change columns to two.
The web view shows two columns which wrap at unpredictable places showing meaningless page breaks. Only half the window is available for writing, with the other half showing other unclearly related text.
If you set the columns to 1 to have a meaningful view of your text, once you go back to Normal view you will need to set it back to two, remembering to apply the remaining column parameters, which will have been wiped out.
The web view shows a single column of text that fills the window from edge to edge. The column settings are being ignored.
When I go to "Normal" view again, I again see the two-column view just the way I had last configured it.
User Profile Reset: No
Please prepare and attach sample document.
much like the requests to make the pagination in Web view relate to its Normal view layout--eliminating the otherwise functional page layout in columns offers no real benefit.
If you want to use the uncluttered Web view layout to write in, great. Just accept that its VCL handling is calculated against an unisized page (10 meters tall, at the current app frame width minus controls).
Reflowing from Web view to Normal view, or reverse, will otherwise honor the page settings of the document.
If you don't want columns in Web view reformat the page style for the document to single column--you can't have it both ways. Single column in Web view and multicolumn in Normal view.
(In reply to V Stuart Foote from comment #2)
> ...you can't have it both ways...
Second Stuart here. => WF
Reading all these tickets that adopt (to not say abuse) the web view as distraction free writing makes me wonder if such a dedicated mode would be worth to consider.
(In reply to V Stuart Foote from comment #2)
> If you want to use the uncluttered Web view layout to write in, great. Just
> accept that its VCL handling is calculated against an unisized page (10
> meters tall, at the current app frame width minus controls).
> Reflowing from Web view to Normal view, or reverse, will otherwise honor the
> page settings of the document.
> If you don't want columns in Web view reformat the page style for the
> document to single column--you can't have it both ways. Single column in
> Web view and multicolumn in Normal view.
I know that is how it works, but I don't think it is how it should work. I cannot have it both ways *now*, but I think that is a bug, not a feature.
The web view is inconsistent. Why are margins, headers, footers and page breaks ignored, but not columns? They make as just as little sense in a web view, if not even less. Flowing columns in web pages are an extremely rare occurrence, and a very dubious design choice.
The column management in web view is buggy anyway:
I cannot think of any setting where it makes any sense to flow columns counting on a non-configurable 10-meter tall page, which in itself could be considered buggy behavior. I don't think that is how it works, anyway: in documents a lot less than 10m long there will be a column wrap in web view, though both columns are very different in length. And if there are changes in the number of columns (because you have they have to be separately enabled and configured for every section and page style), then it also inserts visible page breaks.
And the behavior changes depending on whether your whole document is in "Default Page" page format, or the first page is in "First Page" format, and whether you change columns while within the web view, or in the Normal view (and then depending on whether you change one style, the other, or both). You can get page breaks at impredictable places, with different lengths, and the text sinuously flowing up and down.
But I don't think fixing the buggy column management in web view is the right thing to do (or even possible). I think that the bug looks like the untested behavior of code that is being used in a setting that makes no sense. The easiest thing to do, and most logical in terms of fixing the behavior, whould be to stop trying, as it seems to be done with margins, headers and footers.
If these issues with the web view were fixed, it could make do as a less cluttered writing interface that removed the biggest distractions, filling the window with the user's work. And it would work better as a way to publish documents in HTML for uploading to some CMS or whatever.
In the wishlist arena, a dedicated no-clutter writing interface might satisfy many writers. Much sofistication could be added, or removed; many features would be possible. But that will be a long time coming, if it ever comes.
In any case, thanks for your efforts. Really LibreOffice is unbelievable value at the price, and it must be frustrating for developers watching a growing queue of bugs that need fixing with no resources to allocate.