[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #77 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #76) Page number mechanism in Writer is connected to e.g. ToC, and its numbers. Any "A user who chooses to [Insert | Page Number] does not want to insert the number of another page", which implies use of offset to modify (even for display) the number of *current* page, tries to introduce inconsistency. And of course, this leads to greater confusion. I strongly believe, that there must *not* be any mechanics that allow *that* outside of the normal page break mechanism. OTOH, any improvements in the page breaks properties in that regards are welcome. The current page field may be changed e.g. like this: remove the offset from the field completely; and introduce another field kind, "page reference", which would have the offset. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 131253] Frames are displayed around images even though Object boundaries is unchecked, as Text boundaries control it
https://bugs.documentfoundation.org/show_bug.cgi?id=131253 Justin L changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=16 ||0365 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 129905] Cannot turn off section boundaries with Options-Application Colors
https://bugs.documentfoundation.org/show_bug.cgi?id=129905 Justin L changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=16 ||0365 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #76 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #70) > Generally, "ApplyOffset(GetNumberOf(CurrentPage()), N )" implies a numeric > "page number", which is not a requirement. It isn't? Page numbers are numbers, and numbers are numeric, aren't they? If you're referring to the styling of the number, i.e. A B C or i ii iii vs 1 2 3, that's just formatting; the offset applies to the number itself, not its formatted form. > Any such arithmetics will not give you > a *number*, but a "page number" - thus, the only sensible thing is > "GetNumberOf(ApplyOffset(CurrentPage(), N))". I have argued above that it is not a sensible thing. A user who chooses to [Insert | Page Number] does not want to insert the number of another page. For doing that, they would [Insert | Cross Reference]. (By the way, if a user does [Insert | Field], the dialog clearly separates "Cross Reference" from where we get the page number. But then, within the "Document" tab, in the "Select" column, we have "Page Number", "Previous Page", "Next Page". This suggests that we do get cross-ref-type fields on this pane; but it also suggests that the way to refer to another page is through the "Select" box, not through the Offset field, and that "Page Number" itself will only be the current page's number, not the number of any other page) > And we are back to the wording. It should be fixed. If you want to fix the UI so that Page Numbers are not necessarily numbers, you have to rework: 1. Some items on the Insert menu 2. The [Insert | Field] dialog <- which makes that assumption in multiple ways, including by have a number sequence choice box 3. The Insert Page Numbers dialog ... and I wonder whether replacing Page Numbers with something else will be a positive development for our users. Although I still don't know what you intend to replace "Page Number" with, so maybe it won't be that bad? :-\ > Now we have a *different* field, namely, Insert Formula field, We do? I can't find it on the Insert menu, nor in the Insert Field dialog. Anyway, this could certainly be a basis for getting the "ApplyOffset(GetNumberOf(CurrentPage()), N )" effect. If we take that direction, then I believe the UI for [Insert | Page Number] would have to be rebased on this formula mechanism to begin with. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 131253] Frames are displayed around images even though Object boundaries is unchecked, as Text boundaries control it
https://bugs.documentfoundation.org/show_bug.cgi?id=131253 Justin L changed: What|Removed |Added CC||jl...@mail.com --- Comment #5 from Justin L --- Created attachment 193300 --> https://bugs.documentfoundation.org/attachment.cgi?id=193300&action=edit 131253_through.docx: wrap none/through images shouldn't display a text boundary line (In reply to Heiko Tietze from comment #3) > Whether object or not, the text ends here. And the point is, View > Text > Boundary disables the thin grey lines => NAB. The text does not "end here" if the frame is wrap through (or wrap none). Note that the page's text boundaries are also not (fully) boxed in (when "show formatting marks" is turned off), just a few angle brackets are shown. It is EXTREMELY disconcerting to the user to have a border around their image, and even more so since it does not work consistently (bug 134869). I propose that the frame's "text boundaries" should only show when formatting marks are turned on. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160350] Replies to comment are in reverse order
https://bugs.documentfoundation.org/show_bug.cgi?id=160350 BogdanB changed: What|Removed |Added CC||buzea.bog...@libreoffice.or ||g --- Comment #6 from BogdanB --- If we read comments like a chat, the order is D, C, B, A. If we read comments like a book, the order is A, B, C, D. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160350] Replies to comment are in reverse order
https://bugs.documentfoundation.org/show_bug.cgi?id=160350 --- Comment #5 from Timur --- G docs and MSO both work as I expect, replies order as inserted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160350] Replies to comment are in reverse order
https://bugs.documentfoundation.org/show_bug.cgi?id=160350 --- Comment #4 from Aron Budea --- Created attachment 193296 --> https://bugs.documentfoundation.org/attachment.cgi?id=193296&action=edit Current order This screenshot should help showing current behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160350] Replies to comment are in reverse order
https://bugs.documentfoundation.org/show_bug.cgi?id=160350 Aron Budea changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #3 from Aron Budea --- What Timur described is that when you add multiple replies to the same comment, the replies will always be added right below the original comment, not below the existing replies, this is how the order of replies will be in reverse in the end. I agree with the expectation that they should be in the order as they're added, but let's ask the UX team as well for input. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 131253] Frames are displayed around images even though Object boundaries is unchecked, as Text boundaries control it
https://bugs.documentfoundation.org/show_bug.cgi?id=131253 Justin L changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||4869 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 131253] Frames are displayed around images even though Object boundaries is unchecked, as Text boundaries control it
https://bugs.documentfoundation.org/show_bug.cgi?id=131253 Justin L changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=14 | |1081| CC||david.c@virgin.net --- Comment #4 from Justin L --- *** Bug 141081 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 131253] Frames are displayed around images even though Object boundaries is unchecked, as Text boundaries control it
https://bugs.documentfoundation.org/show_bug.cgi?id=131253 Justin L changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||1081 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 Mike Kaganski changed: What|Removed |Added CC||pedro.jvrc.co...@gmail.com --- Comment #75 from Mike Kaganski --- *** Bug 133466 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 Mike Kaganski changed: What|Removed |Added CC||jcs...@libreoffice.org --- Comment #74 from Mike Kaganski --- *** Bug 153811 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 Mike Kaganski changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=10 | |0997, | |https://bugs.documentfounda | |tion.org/show_bug.cgi?id=11 | |2058| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 Mike Kaganski changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=14 | |9479| CC||ad...@fringedynamic.co.za --- Comment #73 from Mike Kaganski --- *** Bug 149479 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 Mike Kaganski changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=15 | |4928| CC||sla...@cheapnet.it --- Comment #72 from Mike Kaganski --- *** Bug 154928 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 Mike Kaganski changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=11 | |4071| CC||wagner.scha...@gmail.com --- Comment #71 from Mike Kaganski --- *** Bug 114071 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #70 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #69) And we are back to the wording. It should be fixed. Generally, "ApplyOffset(GetNumberOf(CurrentPage()), N )" implies a numeric "page number", which is not a requirement. Any such arithmetics will not give you a *number*, but a "page number" - thus, the only sensible thing is "GetNumberOf(ApplyOffset(CurrentPage(), N))". Now we have a *different* field, namely, Insert Formula field, allowing to use arbitrary calculations. The problem with its use is absence of a pre-defined variable for current page (the PAGE means actually "total number of pages" [1]). An improvement could be introducing such a pre-defined variable (with a problem of naming, given how awful the current name of PAGE was chosen). Also, there is a Page Variable, allowing to do additional magic... [1] https://help.libreoffice.org/24.2/en-US/text/swriter/02/1402.html?&DbPAR=WRITER -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #69 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #68) (not continuing the discussion about how "real" page numbers are set.) > Note that the wish to show numbers outside of the existing > range is wrong *in principle*. There is bug 149480; please think about it. > The page field must not show any "random" number: it must show the number > *flexibly* assigned to a specified page. Only having that page physically, > can you know what page number is assigned to it - it could be an arbitrary > number, say, 1 again (because user specified that manually). Its type may be > arbitrary, say, Roman or Arabic. That logic applies is when the user wants to cross-reference a different page. What most users want when setting the offset field - and what motivates this bug report and its 12 (!) dupes - is to show the number of the _current_ page, but with an offset. In other words, users want (and are told by the UI that they will get): ApplyOffset(GetNumberOf(CurrentPage()), N ) while the behavior the spec allows us to offer using the page-adjust attribute is: GetNumberOf(ApplyOffset(CurrentPage(), N)) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 Mike Kaganski changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=11 ||4071, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||9479, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||4928 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160349] Add toolbar icons to change UI and scheme to switch Light/Dark
https://bugs.documentfoundation.org/show_bug.cgi?id=160349 Rafael Lima changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||rafael.palma.l...@gmail.com Keywords||needsUXEval --- Comment #1 from Rafael Lima --- This might be useful not only for testers, but for users as well. I'm not sure this command should be visible by default though. FTR this is not something that can be done via macro, because simply changing the value of the ApplicationAppearance entry won't automatically apply it. The actual code to apply the changes are in ColorConfig_Impl::Load, which is not accessible to macros. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #68 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #65) > (In reply to Mike Kaganski from comment #61) > > In LibreOffice, the page number is set through properties of a page break. > > Which is a problem, as it doesn't cover the first page; It does. The very first paragraph can have the page break with respective properties as well. > nor does it allow for defining a progression rule for page numbers; Why *page number is set through properties of a page break* is the problem here? It is completely orthogonal. The mechanism is lacking completely, but can be implemented there as well. > nor does it properly cover the case of implicit page transitions, No idea what does that mean. > paragraphs which begin on a new page, Same here - no idea what could this be in the frame of the topic. But maybe better to discuss elsewhere anyway. > But again, I believe that's a different discussion for a different and > perhaps deeper bug. This bug is about working with the page numbering > mechanism LO has right now. Agree. Now to the topic. Note that the wish to show numbers outside of the existing range is wrong *in principle*. There is bug 149480; please think about it. The page field must not show any "random" number: it must show the number *flexibly* assigned to a specified page. Only having that page physically, can you know what page number is assigned to it - it could be an arbitrary number, say, 1 again (because user specified that manually). Its type may be arbitrary, say, Roman or Arabic. So no, there is *no* meaningful number in an absent page, which a field could show. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #67 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #66) > Alternatively to a different naming we could hide the field. There are > plenty of other methods to address the previous/next page number. Are there other methods to get a page number with an offset? > I admit the motivation for this ODF attribute is unclear to me. But what we > should not do is to tinker around and break all existing documents and all > compatibility. Agreed, but it seems we could change the semantics of this field _without_ breaking existing documents. We would have a problem with backwards compatibility - but then, features from new versions of the spec also have that problem with older versions of LO. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160324] Column resize handle touch-target too small
https://bugs.documentfoundation.org/show_bug.cgi?id=160324 Heiko Tietze changed: What|Removed |Added Blocks||108364 Keywords||accessibility --- Comment #5 from Heiko Tietze --- Can we make the responsive area dependent to the zoom factor? Sure, we can if tweaking the area is possible at all. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108364 [Bug 108364] [META] Table/Row/Column/Cell management function bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #66 from Heiko Tietze --- Alternatively to a different naming we could hide the field. There are plenty of other methods to address the previous/next page number. I admit the motivation for this ODF attribute is unclear to me. But what we should not do is to tinker around and break all existing documents and all compatibility. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #65 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #61) > However, there should be no way to *set* the page number through the field. Agreed, I did not mean to suggest that there should be. > In LibreOffice, the page number is set through properties of a page break. Which is a problem, as it doesn't cover the first page; nor does it allow for defining a progression rule for page numbers; nor does it properly cover the case of implicit page transitions, paragraphs which begin on a new page, etc. But again, I believe that's a different discussion for a different and perhaps deeper bug. This bug is about working with the page numbering mechanism LO has right now. > Arguing that "this is what users want" may indicate a problem in UX; but > this is definitely *not* a definitive "this is how it must work" - > otherwise, this PoV forces "every program is bound to what another, most > widespread program does" - just because people naturally want to do the same > as they are accustomed to in another software; and the percentage of these > users would necessarily be dominant. This just prevents any innovation / > other ways of implementing features. I am arguing that users want to be able to show the current page number plus an offset; and that they should be allowed to do that. But thinking about the point of view of feature innovation, I would say that users may want two distinct and IMHO valid things: * A more flexible mechanism for setting page numbers, and * The field-arithmetic-expression idea I mentioned above, which is much more expressive, and in particular allows users to "play" with the page number value for display purposes regardless of what the "real" page number is. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694
--- Comment #64 from Eyal Rozenberg ---
(In reply to Heiko Tietze from comment #62)
> How about "Reference page" for the label and "Change to display the page
> numbers of following or preceding pages" as tooltip. I'd also make it a
> spinedit.
(In reply to Mike Kaganski from comment #61)
> There definitely is a bug in the wording (and maybe placement, etc.) of this
> "offset" thing. It definitely provokes the problem in understanding of its
> goal.
That would bring the UI in alignment with the ODF attribute. It would be an
improvement in the sense of not misleading users; but there are two problems
with this approach.
The first problem is the implicit choice of legitimization. We currently have a
feature the exact semantics of which disagrees with its UI. But the UI is for a
feature users need and want much more (but see my reply to Mike below), and the
spec is for a feature of questionable semantics and motivation. Your suggestion
legitimizes and commits to the latter rather than the former. It would be
better to keep the UI, change he LO implementation to meet users' need , and
report a specification bug to OASIS which they should fix with the next
version.
If we did that, users who used the field as specified to refer to existing
fields would still get the same effect, and it is only users who tried to do
something invalid - referring to non-existing fields - which would see any
change of behavior. And most users would get the offset feature they actually
wanted. So - everyone should be happy, or happier at least.
Alternatively, we could devise a more robust generalization of what the UI
offers now, anticipating what a future specification might provide. It might be
a field arithmetic mechanism, so that users could insert a field which is an
arithmetic expression combining other fields. That way they could insert
something like "= {PageNumber} * 2 + 7" - something they currently they can't
do.
The second problem with your suggestion is that a "refer to page by offset from
current page" should just not be placed in the Edit Field... dialog of a Page
Number field.
Like I wrote above, users would look to cross-reference other pages in the
Insert | Cross-Reference dialog; and the Edit Fields for that kind of a field
should be the same dialog we offer now for references to numbered paragraphs,
headings etc.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
https://bugs.documentfoundation.org/show_bug.cgi?id=35694 --- Comment #63 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #62) > How about "Reference page" for the label and "Change to display the page > numbers of following or preceding pages" as tooltip. I'd also make it a > spinedit. (In reply to Mike Kaganski from comment #61) > There definitely is a bug in the wording (and maybe placement, etc.) of this > "offset" thing. It definitely provokes the problem in understanding of its > goal. That would bring the UI in alignment with the ODF attribute. It would be an improvement in the sense of not misleading users; but there are two problems with this approach. The first problem is the implicit choice of legitimization. We currently have a feature the exact semantics of which disagrees with its UI. But the UI is for the feature users need and want much more, and the spec is for a feature of questionable semantics and motivation. Your suggestion legitimizes and commits to the latter rather than the former. It would be better to keep the UI, change he LO implementation to do what users expect, and report a specification bug to OASIS which they should fix with the next version. If we did that, users who used the field as specified to refer to existing fields would still get the same effect, and it is only users who tried to do something invalid - referring to non-existing fields - which would see any change of behavior. And most users would get the offset feature they actually wanted. S > > However, there should be no way to *set* the page number through the field. > In LibreOffice, the page number is set through properties of a page break. > That must stay, and there should be no hidden connections between fields and > page breaks. Convenience features like "insert break" dialogs are fine. > > Arguing that "this is what users want" may indicate a problem in UX; but > this is definitely *not* a definitive "this is how it must work" - > otherwise, this PoV forces "every program is bound to what another, most > widespread program does" - just because people naturally want to do the same > as they are accustomed to in another software; and the percentage of these > users would necessarily be dominant. This just prevents any innovation / > other ways of implementing features. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160324] Column resize handle touch-target too small
https://bugs.documentfoundation.org/show_bug.cgi?id=160324 Michael Weghorn changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #4 from Michael Weghorn --- (In reply to jon.macca...@gmail.com from comment #0) > Description: > The column resize handle touch target is only 1-2px wide, leaving little > margin for targeting when resizing the column. While recovering from a mild > wrist injury, resizing a column became a frustrating and needlessly long > exercise for me. By comparison, Google Sheets and Excel use wider > touch-targets (around 4-8px) and the difference in ease of use is night and > day. In my test with trying to move the mouse just a pixel at a time, the handle seems to be more than just 1-2px (rather around 4 pixels maybe?), but making it slightly wider sounds reasonable to me. CC'ing UX advise for further evaluation. -- You are receiving this mail because: You are on the CC list for the bug.
