Created attachment 171648 [details] Screenshot of the problem (It's really difficult to give this bug a name) Abstract ========= If the header of a page is small enough (or "too small"), a part of the header text will become invisible (looks like white overlaid). See also: Screenshot and example file with the problem Reproduce ========== 1. Create a document. 2. Add header line. 3. Write random text. 4. Change the header height to be as high the line is. 5. Expected: Text is fully visible. Actual: Text is partly invisible. Attachments =========== - Screenshot of the problem - Example file
Created attachment 171649 [details] Example file of the problem
This is not a bug. Your file has header text area height set to 3 mm, while you use 12 pt font size, which roughly relates to X height 4.2 mm, and this latter size does not even include additional spacing. This results in your text area too small, naturally cutting the text, since you also made your heading to not resize dynamically. See also FAQ [1]. [1] https://wiki.documentfoundation.org/Faq/Writer/PageElementSizeRelations
I would then like to ask, if UX could take a quick look at this: Suggestion =========== Spacing / padding settings of header should be 0 by default, because: (1) Increasing it by hand on the page is easy and very intuitive (2) Reducing it is difficult. One has to know what to change ("spacing") and how to change it (page style -> header -> Spacing). (3) By default the handling looks un-intuitive, because the "adjusted size" (red arrow in the screenshot) is suggesting something different, than what actually happens (characters are hidden) Backwards-compatibility ----------------------- To stay "backwards-compatible", the initial header height could be set to a value of [former default header height] + [former default spacing]. Comparison ---------- - OnlyOffice does it as explained above (this is the closest to MS office, that I have)
(In reply to DarkTrick from comment #3) > Spacing / padding settings of header should be 0 by default, because: > > (1) Increasing it by hand on the page is easy and very intuitive Wrong. Vertical ruler is off by default. Additionally, you can't increase *spacing* using the ruler - only header height. And any manual adjustment there disables AutoFit Height setting, that is on by default, and allows people in general not bother about the height at all, while keeping the comfortable spacing. > (2) Reducing it is difficult. One has to know what to change ("spacing") and > how to change it (page style -> header -> Spacing). This only asks for a control on the vertical ruler to make it possible, not for changed defaults. > (3) By default the handling looks un-intuitive, because the "adjusted size" > (red arrow in the screenshot) is suggesting something different, than what > actually happens (characters are hidden) The non-0 spacing allows to have ... well, spacing between header text and text body. It is normal, and not having it would look unnatural. And actually the problem only appears when one tries to use the ruler to make direct changes, actually ruining all useful defaults and automation, thus no defaults would be good. Note that both OnlyOffice and MS Word (both based on the same document model) use completely different page model compared to Writer, so no direct comparison is useful. If someone wants a different default, it's easy to create a custom template, and set it the default. My 2c.
(In reply to DarkTrick from comment #3) > I would then like to ask, if UX could take a quick look at this: needsUXEVal needs ux-advice at CC
Agree with Mike here on all facets. And yes the ODF document model handling header/footer spacing in Text document is better served with our current autoformat defaults that provide appropriate spacing. Trivial to work with a custom template to set tighter spacing for use of smaller fonts or linework in header or footer.
> Note that both OnlyOffice and MS Word (both based on the same document model) use completely different page model compared to Writer, so no direct comparison is useful. > the ODF document model handling header/footer spacing in Text document is better served with our current autoformat defaults that provide appropriate spacing. I don't really understand why you are bringing the document model into the discussion. This ought to be a pure UI discussion. Why would the document model has anything to do with the UI?
(In reply to DarkTrick from comment #7) > Why would the document model has anything to do with the UI? Oh! Please be informed that document model affects behavior - and UI - very directly! In Word document model, there is *no* concept of spacing between header and text body at all. One may only use paragraph settings to fake that (with the need to adjust the settings in case one needs to add/remove paragraphs in the header). The page layout is very simple: there is a header area starting at a set distance from the top page edge; there is a text body area starting at another set distance from the top page edge, and that *may* optionally be shifted down by header content (unless one sets text body top margin to a negative). There is optional page border, that may be 0-31 pt either from edge, or from text (i.e., from the combined area of text body and header and footer). Border width does not add to margins/offsets. Maximum border width is 6 pt (~2 mm). That's all. Header text starts from the top of its area, and goes downside. There's no way to cut header at some height, or otherwise limit its height. There's no way to set border to be e.g. 20 mm from edge and 20 mm from text (just because 31 pt is slightly less than 11 mm). All those things are connected, and affect the UI there in Word. OTOH, there *is* a concept of specific height of header in Writer's document model; a concept of its spacing from text body; a concept of optional dynamic spacing; a concept of optional automatic height. There is an unlimited offset for borders. Border widths do add to text offsets. Max width of borders allowed from UI is 9 pt (~3 mm; in fact, it's only limited in UI, and could be greater if needed; if manually edited in document XML, it may be any value). But, unlike Word, there's no way to overlap normal text of header and text body. This leads to *different* interrelations between these components of the page, different behaviors, and hence different UI needed for that. Specifically, since there *is* the concept of the spacing, there *is* a need for UI for it (unlike in Word model) - and currently, while it exists in the form of dialog controls, it is missing from where *you* would look for it (given that you have enabled the vertical ruler). Given the fact that border width *does* affect the offsets, it also needs a special representation on the rulers (unlike in Word). So *indeed* we need a specific UI that might never appear in Word document model - e.g. to control header spacing on the ruler. Do you see how document model affects UI now? You can't just consider UI without knowing and taking into account the underlying model, and it leads to different solutions.
I summarize a chat from IRC: - There has been a couple of misunderstandings during the discussion here. The misunderstandings render the above discussions rather useless. - There is "probably definitely" a problem with the UI here: Maybe the rulers should visualize spacing, maybe spacing should be editable without a dialog - whatever it is it needs discussion somewhere else. - Regarding the initial report: Changing the spacing-defaults might not be the right way to go. I keep the report closed and removed the UI evaluation (Sorry Heiko for trouble :) ). Perhaps it's an idea to remember, that there was something improvable in this area.