Description: Header mode doesn't work properly Режим колонтитула работает неправильно Steps to Reproduce: Enable Header The fields have moved out Включить колонтитул Поля съехали Actual Results: When you turn on the header and footer, page margins move out При включении колонтитула съезжают поля страницы Expected Results: When you turn on the header and footer, the page margins remain unchanged. При включении колонтитула поля страницы остаются неизменны Reproducible: Always User Profile Reset: Yes Additional Info: I'm confused about why and why your page margins move out when you turn on the header. Although the footer should take only its field assigned to it in the page settings Я в замешательстве, от чего и зачем у вас съезжают поля страницы при включении колонтитула. Хотя колонтитул должен брать только своё поле отведённое ему в настройках страницы
Created attachment 186279 [details] LOkol-prim1
Created attachment 186280 [details] LOkol-prim2
Isn't this issue of NAB bug 33304 issue?
(In reply to V Stuart Foote from comment #3) > Isn't this issue of NAB bug 33304 issue? Yes, it really is, and I still don’t understand why it hasn’t been resolved, but the headers and footers were stuffed into the styles correctly. At least 50 requests for these headers and footers (for me) were received, and everything was urgent for everyone, and most of the document also moved out. And the header must be present because of the page number. Yes, and it’s very unpleasant to draw up all term papers, diploma papers with such flying fields. Да действительно она, и я не понимаю до сих пор почему она не решена, а вот колонтитулы в стили запихнули правильно. Получено порядка минимум 50 обращений на эти колонтитулы(у меня), и всем всё срочно и также съехала большая часть документа. И колонтитул обязан присутствовать из-за номера страницы. Да и самому неприятно оформлять все работы курсовые, дипломные с такими летающими полями.
@Mike, what do you think. Work it up here, or revisit bug 33304?
(In reply to V Stuart Foote from comment #5) I don't see why would we need to revisit it, or how should it be handled here. It's just an incorrect expectation from OP, that header/footer are part of margins: it is not how ODF page model is designed. In ODF, margins are space where *no* part of document is present. And that is fixed: no matter how you try, header/footer/page body won't eat it. In other applications, where margins are for headers/footers, it's just a fake, and when headers increase in size, they start eating page body. So there, there is no guarantee that page body is not affected, just a different point of surprise. There *can* be a convenience tool, that allows "placing" header/footer "on margins" by decreasing them, and making the header/footer take that space, in one action. It would be an enhancement request for such a convenience tool.
Created attachment 186295 [details] LOkol-prim3
(In reply to Mike Kaganski from comment #6) > (In reply to V Stuart Foote from comment #5) > > I don't see why would we need to revisit it, or how should it be handled > here. It's just an incorrect expectation from OP, that header/footer are > part of margins: it is not how ODF page model is designed. > > In ODF, margins are space where *no* part of document is present. And that > is fixed: no matter how you try, header/footer/page body won't eat it. > > In other applications, where margins are for headers/footers, it's just a > fake, and when headers increase in size, they start eating page body. So > there, there is no guarantee that page body is not affected, just a > different point of surprise. > > There *can* be a convenience tool, that allows "placing" header/footer "on > margins" by decreasing them, and making the header/footer take that space, > in one action. It would be an enhancement request for such a convenience > tool. See LOkol-prim3. This thing must be raised and forbid it to raise and lower the margins of the page. Also, you see the interval below it to the fields, if you set it to 0, then the page number will be directly above the text, which is not beautiful. The title I didn't understand. If these are the headings that have styles and are used in the table of contents - this is completely different. Смотрим LOkol-prim3. Вот эту штуку надо поднять и запретить ей подымать и опускать поля страницы. Также вы под ней видите интервал до полей, если его поставить 0 то номер страницы будет находиться прям над текстом, что не красиво. Заголовок чего я так и не понял. Если это те заголовки на которые есть стили и используются в оглавлениях - это совершенно иное.
Роман: в дополнение к Вашему багрепорт здесь, если Вам нужна помощь по правильному форматированию колонтитулов (верхний колонтитул в английском называется header, в отличие от заголовка, который heading), то Вы можете задать вопрос на https://forumooo.ru. A native-language community support in Russian is available at https://forumooo.ru.
(In reply to Mike Kaganski from comment #9) > Роман: в дополнение к Вашему багрепорт здесь, если Вам нужна помощь по > правильному форматированию колонтитулов (верхний колонтитул в английском > называется header, в отличие от заголовка, который heading), то Вы можете > задать вопрос на https://forumooo.ru. > > A native-language community support in Russian is available at > https://forumooo.ru. I need that when the headers and footers are turned on, the fields do not move out. And also in order to be able to manage that ruler in LOkol-prim3 within the header, the rights of the header must be set based on the provided fields in the page style. After all this does not move out, the correct formatting of the headers and footers will begin. The forum has no power over the moving line. The page margins are indicated so that they are not violated. I leave the Russian text so as not to try to remember what I wrote about. Мне нужно чтобы когда включали колонтитулы, поля не съезжали. И также чтобы можно было управлять той линейкой в LOkol-prim3 в рамках колонтитула, права колонтитула должны быть установлены исходя из предоставленных полей в стиле страницы. После того как это всё съезжать не будет начнётся правильное форматирование колонтитулов. Форум над съезжающей строкой не властен. Поля страницы для того и указываются чтобы они не нарушались. Русский текст оставляю чтобы не пытаться вспоминать о чём писал.
And what is the status of the field when the footer is included? И каков статус поля при включении колонтитула?
Created attachment 190530 [details] footer.odt
Created attachment 190531 [details] footer_off.png
Created attachment 190532 [details] footer_on.png
Added newer interactive pictures and file Добавлены более новые интерактивные картинки и файл
@Mike ?
(In reply to Roman from comment #16) > @Mike ? If your naked ping was meant to re-evaluate what I wrote in comment 6: I don't see how your new screenshots (with obviously wrong annotations in attachment 190532 [details]), or self-approving the report to NEW (which only must be done independently) changes the fact that this is a clear duplicate of a NOTABUG tdf#33304. *** This bug has been marked as a duplicate of bug 33304 ***
(In reply to Mike Kaganski from comment #17) > (In reply to Roman from comment #16) > > @Mike ? > > If your naked ping was meant to re-evaluate what I wrote in comment 6: I > don't see how your new screenshots (with obviously wrong annotations in > attachment 190532 [details]), or self-approving the report to NEW (which > only must be done independently) changes the fact that this is a clear > duplicate of a NOTABUG tdf#33304. > > *** This bug has been marked as a duplicate of bug 33304 *** Which uncle did you leave an empty space in footer_on.png? If you need a question: what should the page margins look like in the page style so that the indentation to the text is 2 cm on the left, 1 cm on the right, 2 cm on the top, 2 cm on the bottom, 1 cm. Какому дяде вы оставили пустое место в footer_on.png? Если нужен вопрос: то как должны выглядеть поля страницы в стиле страницы, чтобы отступ до текста был слева 2 см справа 1 см сверху 2 см снизу 1 см.
Created attachment 194813 [details] Я заполненный текст.odt When the footer is enabled, the text must remain on 1 page При включенном колонтитуле текст обязан остаться на 1 странице
> > Which uncle did you leave an empty space in footer_on.png? If you need a > question: what should the page margins look like in the page style so that > the indentation to the text is 2 cm on the left, 1 cm on the right, 2 cm on > the top, 2 cm on the bottom, 1 cm. > Какому дяде вы оставили пустое место в footer_on.png? Если нужен вопрос: то > как должны выглядеть поля страницы в стиле страницы, чтобы отступ до текста > был слева 2 см справа 1 см сверху 2 см снизу 1 см. 'to the text is 2 cm on the left, 1 cm on the right, 2 cm on > the top, 2 cm on the bottom, 2(было 1) cm.'
(In reply to Roman from comment #18) > Which uncle did you leave an empty space in footer_on.png? I could only understand this, because I'm Russian, and I can read your untranslated text below. Please don't imagine that your native language idioms are OK in an international Bugzilla. Please write in a neutral, technically clear language, without any funny-looking phrases like that. The whitespace that you refer to is kept because it is *margin* (i.e., what your translation likes to name "field" in all your comments). To repeat what was already mentioned both here and in the bug 33304: in Writer, the margins are *designed* to *not* contain any content. So ass you defined, that there must be a 2-cm space at the top, which must not contain any content (which is called margin), thus the program obeys your decision; and when you add a header, it puts it below that 2-cm no-content space. > what should the page margins look like in the page style so that > the indentation to the text is 2 cm on the left, 1 cm on the right, 2 cm on > the top, 2 cm on the bottom, 1 cm. If you need a "how do I use this program" answers: see comment 9.
(In reply to Mike Kaganski from comment #21) > So ass you defined Sorry for the typo: it was meant "So as you defined"
Created attachment 194817 [details] page field MO.png Fields of the document created in MO Поля документа созданного в MO
Created attachment 194818 [details] page field LO.png Fields of the MO document opened in LO Поля документа MO, открытого в LO
(In reply to Mike Kaganski from comment #22) > (In reply to Mike Kaganski from comment #21) > > So ass you defined > > Sorry for the typo: it was meant "So as you defined" 1.page field MO.png Поля страницы в редакторе MO после их установки никто и никогда не затрагивает. Да колонтитул может опускаться и захватывать установленные поля страницы, то есть иметь приоритет выше, но он поля страницы не меняет. 2.page field LO.png Открыв этот же документ созданный в MO в LO, мы видим что поля страницы согласно - стилю страницы нарушены и не имеют правильный след, структура видимости документа при этом не нарушена. Так вот почему мы должны думать и подстраивать о том сколько нам надо установить в размере эти поля страницы? Итоговое предложение внести правку в стиль страницы во вкладку страница о полях Колонтитула верхнего и нижнего.
(In reply to Roman from comment #25) Please write in English. This is an international Bugzilla. The ODF standard defines the structure of the page. What Word is build around is absolutely irrelevant. Bug 161646 is intended to allow people to do less manual calculations.
(In reply to Roman from comment #25) > (In reply to Mike Kaganski from comment #22) > > (In reply to Mike Kaganski from comment #21) > > > So ass you defined > > > > Sorry for the typo: it was meant "So as you defined" > > 1.page field MO.png > Поля страницы в редакторе MO после их установки никто и никогда не > затрагивает. > Да колонтитул может опускаться и захватывать установленные поля страницы, то > есть иметь приоритет выше, но он поля страницы не меняет. > 2.page field LO.png > Открыв этот же документ созданный в MO в LO, мы видим что поля страницы > согласно - стилю страницы нарушены и не имеют правильный след, структура > видимости документа при этом не нарушена. > > Так вот почему мы должны думать и подстраивать о том сколько нам надо > установить в размере эти поля страницы? > Итоговое предложение внести правку в стиль страницы во вкладку страница о > полях Колонтитула верхнего и нижнего. 1.page field MO.png The page fields in the MO editor are never touched after they are installed. Yes, the footer can go down and capture the set page fields, that is, it has a higher priority, but it does not change the page fields. 2.page field LO.png Opening the same document created in MO in LO, we see that the page margins according to the page style are broken and do not have the correct trace, the document visibility structure is not broken. So that's why we have to think and adjust about how much we need to set the size of these page fields? The final suggestion is to make an edit to the page style in the page tab about the header and footer fields.
(In reply to Mike Kaganski from comment #26) > (In reply to Roman from comment #25) > > Please write in English. This is an international Bugzilla. > The ODF standard defines the structure of the page. What Word is build > around is absolutely irrelevant. > > Bug 161646 is intended to allow people to do less manual calculations. Word matters just in performing the functions that it knows how to do. Because if the behavior of the action (problem) is the same as in LO, then it is pointless to apply to bugzilla. Bug 161646 Yes, it's really closer to the truth, but just set up the footer right away so that this checkbox is not required Word значения имеет как раз в выполнении функций которые он умеет. Поскольку если поведение действия(проблемы) является одинаковым как в LO, то подавать заявку в bugzilla бессмыслено. Bug 161646 Да действительно ближе к истине, но вот сразу просто настроить колонтитул чтобы не требовался этот чекбокс
(In reply to Roman from comment #28) > Word matters just in performing the functions that it knows how to do. > ... > just set up the footer right away so that this checkbox is not required Please read and try to understand. 1. LibreOffice Writer is not Word, and is not meant to be. It can create text documents, and in that sense, these two applications are similar; but some things in these two applications are fundamentally different, and what one application does in this margin/header/page-body case, has *no* meaning when you discuss what the other application does. Word is build around "there is a page margin and then page body; headers are in page margin area" idea. Writer is created around "there is page margin, then header, then page body" idea. In both applications, their ideas are standardized - in Word's case, it's OOXML International Standard; in Writer's case, it's ODF International Standard. End of story. 2. Hence, Writer will always show you, what *it* (Writer) thinks about margins, headers, and page body - not what people may be accustomed to just because they used Word before. We can add convenience tools. Continuing this discussion is useless. This is my last post here.