[Libreoffice-ux-advise] [Bug 105628] Creating a ToC with page numbering by chapter (see comment 4)
https://bugs.documentfoundation.org/show_bug.cgi?id=105628 --- Comment #22 from Buovjaga --- (In reply to Lee from comment #21) > That email address I used in comment 20 failed. I'm not sure how to get a > hold of the documentation team. They can now be reached here: https://community.documentfoundation.org/c/documentation/12 Can you mention where you saw the mention of that mailing list? The change to the forum happened relatively recently and there might be some references that need to be updated. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 105628] Creating a ToC with page numbering by chapter (see comment 4)
https://bugs.documentfoundation.org/show_bug.cgi?id=105628 --- Comment #21 from Lee <92ma...@gmail.com> --- That email address I used in comment 20 failed. I'm not sure how to get a hold of the documentation team. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 105628] Creating a ToC with page numbering by chapter (see comment 4)
https://bugs.documentfoundation.org/show_bug.cgi?id=105628 --- Comment #20 from Lee <92ma...@gmail.com> --- Rather than some comments in the WIKI, perhaps the need for setting "evaluate up to level" should be in the User's Guide discussion of the e# element for customizing the TOC? I just sent that suggestion to the documentation area (LibreOffice Documentation ). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153561] Rename "Chapter -> Heading" and "E# -> H#" in Entries tab of Insert Table of Contents, Index, Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153561 --- Comment #4 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #3) > Don't see why we have to change the E# into H#. Heading # Would seem more confusing to me to click on "Heading No." and have E# show up in the Structure, than H# > it seems the E# has been chosen randomly. Probably to make link to E, with E# being the Entry number. In effect: "Heading number" and "Heading content" (but not suggesting that user PoV must correspond to underlying implementation logic). > Side note: funny, And more supporting evidence... -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153770] Proposal to modify "Create Index or Table of Contents" and Type-dependent "Create From" sections in Type tab of ToC/Index
https://bugs.documentfoundation.org/show_bug.cgi?id=153770 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||122497 CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=122497 [Bug 122497] [META] Table of Contents and Indexes dialog bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc inputwin for formula bar using system font, too small for CJK input
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 --- Comment #11 from ady --- (In reply to V Stuart Foote from comment #10) > (In reply to ady from comment #9) > The Win10/Win11 Settings -> Display -> 'Make text bigger' control in the > os/DE provides exactly the adjustment needed for this issue. As I already mentioned, I already have adjustments to that OS's control, among others, and I still have the need to use the OS's zoom feature when I need to read the formula bar. So, please, I am asking you to be more flexible in the terminology. It _can_ help, but it is not the ultimate solution; it might not be enough. That OS's setting affects other areas of the OS's UI, and other programs too. Claiming that users can freely keep making that setting higher and higher (or lower and lower for this particular ticket) is not realistic; yes, some users could, but there are other reasons not to modify it (more than it has been). The formula bar in Calc is not the only factor to be considered when modifying that setting. This is the reason for the recurring requests in several tickets, either for accessibility reasons, for convenience, or for reduction of UI glitches. > > Similar UI controls in macOS and the various Linux os/DEs. > > Not every adjustment must be in the LibreOffice UI, but there is room tweak > the UI to use "other than os/DE system UI font" and also to extablish a > different fontsize for the inputwin.hxx/.cxx of the 'Formula Bar' widget. > > Again this is => WFM, and the other BZ issues are already open for the > "tweaks". The WFM definition would need, IMHO, more input/feedback from the OP (iaganicshe). According to the report, the CTL font that is being shown in the formula bar is not adequate ATM in/for that system. You seem to suggest, IIUC, that the System/OS font should be modified for this, and that the current defaults in LO are ideal for every_and_all configurations/systems (i.e. "just change the system's configurations"). I assume some users won't like/agree with that idea, just for Calc's formula bar, or they might have a different default language (not CTL) for the system/OS. It might be helpful to have the OP's feedback. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153722] Review needed of style groups "Chapter Styles" and "Text Styles"
https://bugs.documentfoundation.org/show_bug.cgi?id=153722 --- Comment #3 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #2) > "Outline Styles" sounds reasonable considering the latest activities. "Outline" is ambiguous. I only use "outline level". > Alternatively "Document Structure" for all headings plus the current > "chapter style" "Document Structure" is good. The current grouping in Text Styles looks like an implementation error. Once the Headings are removed from Text Styles, the "logic" of what remains is clear enough. In sum, the request looks like: 1. Rename "Chapter Styles" to "Document Structure" 2. Move "Heading" and "Heading [1-10]" PS from "Text Styles" to "Document Structure" Maybe an EasyHack? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc inputwin for formula bar using system font, too small for CJK input
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 --- Comment #10 from V Stuart Foote --- (In reply to ady from comment #9) > I already have that setting modified in the OS. As a user, I set it in some > "balance" point, where I can read clearly _every_ aspect of the OS > interface. If I have to set it even bigger, just for the formula bar, it > would make some other places in my OS "too big" and it won't fit in the > place where it allows me to see the complete text (i.e. part of it will be > hidden by other artifacts). > Again, OP looks to have os/DE system at 100% -- too small. The Win10/Win11 Settings -> Display -> 'Make text bigger' control in the os/DE provides exactly the adjustment needed for this issue. Similar UI controls in macOS and the various Linux os/DEs. Not every adjustment must be in the LibreOffice UI, but there is room tweak the UI to use "other than os/DE system UI font" and also to extablish a different fontsize for the inputwin.hxx/.cxx of the 'Formula Bar' widget. Again this is => WFM, and the other BZ issues are already open for the "tweaks". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc inputwin for formula bar using system font, too small for CJK input
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 --- Comment #9 from ady --- (In reply to Adolfo Jayme Barrientos from comment #7) > I’d > rather have it follow whatever font and size it’s used in the currently > selected cell That's a terrible idea. A user might have a bigger font in one cell just as a Title or Caption, and a variety of font sizes for other cells, such as those less important, those that include totals... Every user might have different reasons to customize the cells in different ways. But that is not the same as the usage of the formula bar. I can't imagine having the formula bar changing for each cell; that would be chaotic, and eventually nobody would change any cell's font at all? No, they won't use LO Calc. (In reply to V Stuart Foote from comment #8) > Meaning that in Win10/Win11 from Windows Settings -> Display -> 'Make text > bigger' and drag the size slider greater or smaller. I already have that setting modified in the OS. As a user, I set it in some "balance" point, where I can read clearly _every_ aspect of the OS interface. If I have to set it even bigger, just for the formula bar, it would make some other places in my OS "too big" and it won't fit in the place where it allows me to see the complete text (i.e. part of it will be hidden by other artifacts). Other widgets in LO might be more static, either in place or in content to be read. I don't need to read the title of a dialog window every single time, and it doesn't change every time either. Same for icons and alike. The content of the formula bar changes for every cell, sometimes with very large formulas. For most Calc users that come here to either report problems or request the possibility of customization of the formula bar, the matter is not about changing some OS setting (zoom, dpi, screen resolution, font size). We already do all this, and the settings for the OS are not all about the formula bar in Calc; there are other factors to consider. If there is some objective impediment to have the formula bar customization regarding font type and size, then please say so. You are of course welcome to suggest other possibilities such as OS customization. But please don't take that possibility as the ultimate best and only solution available, because it is not. I know because I already use such possibilities, and I still have problems with the formula bar (which is why I use the OS zoom every time I need to read a long formula, where using F2 is not always the best alternative, for several reasons). And after saying that, clearly the OP is presenting an additional point. Changing OS settings will affect everything, not just the formula bar when it contains CTL glyphs. Making _everything_ bigger just because such situation? Then you would have other users claiming that there is too much empty space, or fonts too big. Oh, how they would dare! With so many reports asking for some kind of modification in the formula bar, in one direction or another, or to solve some quirk or glitch, I don't see how the request can be still discarded as some meaningless "nice to have" feature. This is not just "nice to have". This is not "I just like some different color, just for fun". This is a functional, practical, UX, efficiency-related and accessibility request. And to that, add the CTL problem presented in this bug report. > Of course what would be helpful is ability to assign both a font (other than > os/DE system) and a font size to the "input bar", see also bug 88141 and bug > 95406 > > Or more broadly reintroduction of support for global LibreOffice UI scaling > as for bug 101646 I don't see as many reports about problems or RFE regarding the _whole_ UI scale as there are regarding the formula bar specifically. I could be wrong. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153366] New Main LibreOffice Icons Are a Complete Failure!
https://bugs.documentfoundation.org/show_bug.cgi?id=153366 --- Comment #6 from BrendaEM --- The icons are broken if most users cannot immediately identify what they are trying to convey. In the new icon set, about 1/2 of the space is wasted and blank. Indeed, many icons are checked for various resolutions, and while nothing is "perfect," these icons don't work when they are small because they waste too much space for a given resolution. Did you put the new icons against the old ones in the poll? Color should not be the only identifier for an icon, as 1:12 people are color-blind. Ref: https://www.colourblindawareness.org/colour-blindness/ I don't know if people will really be baffled... Do they look that different from the previous icons? When viewed on a black background, the lower right of the icon is indistinguishable from the background. They icon should look like what it's meant to convey. If it's a word processor, and people still write documents, then boring as may seem, the background should look like paper with text on it. The old writer icon worked much better. The math icon has a decent looking small block of characters that look like formulas, but why should they only occupy a portion of the icon. The look of the icon should not be more important than information or understand-ability. [For instance, Futura is one of my favorite fonts. I love the look of it, but it cannot be used for highway signs--because it's not as readable as Highway Gothic.] You were quick to discern that the Windows Calculator icon was only a standard calculator icon--because you could identify it. If it had a small bird on the lower half, I don't think you would be so quick. : ) Much of commercial graphics is not art; it's formulaic. Paragraph: use serif fonts. Legend: use san-serif fonts. There isn't enough room on an icon to lay down a cathartic work. People need to be able to look at it, and immediately know what it means. "The frustration of seeing new icons is really temporary but you forget it later on..." Well, it's later-on, and I still think that they do not work. to mind now. Some suggestions: Use most of the icon space for symbols and information. Pick one effect: clipped corner or shading. Make paper look like paper. Use solid symbols, not hollow ones. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153366] New Main LibreOffice Icons Are a Complete Failure!
https://bugs.documentfoundation.org/show_bug.cgi?id=153366 --- Comment #5 from BrendaEM --- The icons are broken if most users cannot immediately identify what they are trying to convey. In the new icon set, about 1/2 of the space is wasted and blank. Indeed, many icons are checked for various resolutions, and while nothing is "perfect," these icons don't work when they are small because they waste too much space for a given resolution. Did you put the new icons against the old ones in the poll? Color should not be the only identifier for an icon, as 1:12 people are color-blind. Ref: https://www.colourblindawareness.org/colour-blindness/ I don't know if people will really be baffled... Do they look that different from the previous icons? When viewed on a black background, the lower right of the icon is indistinguishable from the background. They icon should look like what it's meant to convey. If it's a word processor, and people still write documents, then boring as may seem, the background should look like paper with text on it. The old writer icon worked much better. The math icon has a decent looking small block of characters that look like formulas, but why should they only occupy a portion of the icon. The look of the icon should not be more important than information or understand-ability. [For instance, Futura is one of my favorite fonts. I love the look of it, but it cannot be used for highway signs--because it's not as readable as Highway Gothic.] You were quick to discern that the Windows Calculator icon was only a standard calculator icon--because you could identify it. If it had a small bird on the lower half, I don't think you would be so quick. : ) Much of commercial graphics is not art; it's formulaic. Paragraph: use serif fonts. Legend: use san-serif fonts. There isn't enough room on an icon to lay down a cathartic work. People need to be able to look at it, and immediately know what it means. "The frustration of seeing new icons is really temporary but you forget it later on..." Well, it's later-on, and I still think that they do not work. to mind now. Some suggestions: Use most of the icon space for symbols and information. Pick one effect: clipped corner or shading. Make paper look like paper. Use solid symbols, not hollow ones. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 127066] UI: Font size in input line (formular bar) larger than in other UI elements
https://bugs.documentfoundation.org/show_bug.cgi?id=127066 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3727 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc inputwin for formula bar using system font, too small for CJK input
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||7066, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=10 ||1646 CC||vsfo...@libreoffice.org Summary|Calc 7.5 tiny formula bar |Calc inputwin for formula |font for japanese |bar using system font, too ||small for CJK input --- Comment #8 from V Stuart Foote --- The inputwin.hxx/.cxx was intentionally aligned to UI scale as for but 127066 Meaning the sc inputwin.hxx/.cxx widget currently responds to system font settings, meaning it is trivial to scale the font for os/DE and get large font rendering of system font. Meaning that in Win10/Win11 from Windows Settings -> Display -> 'Make text bigger' and drag the size slider greater or smaller. And this is a => WFM Likewise the sw inputwin.hxx/.cxx for table formulas on Writer. Of course what would be helpful is ability to assign both a font (other than os/DE system) and a font size to the "input bar", see also bug 88141 and bug 95406 Or more broadly reintroduction of support for global LibreOffice UI scaling as for bug 101646 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc 7.5 tiny formula bar font for japanese
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 --- Comment #7 from Adolfo Jayme Barrientos --- (In reply to ady from comment #6) > Just a side note... IDK what "communicate with anything else" means. It means, if you find that font size unreadable, since it’s the same font size used in other UI widgets, then those other places are → potentially ← unreadable too (not considering aspects like visual memory devices and muscle memory that aid in a user interface’s usability). I’m aware that many system/UI fonts are subpar for scripts different from Latin, Greek and Cyrillic, especially on outdated Windows systems. Nevertheless, I just don’t see how it’s beneficial to go through the effort of developing a customization option just for this singular widget. I’d rather have it follow whatever font and size it’s used in the currently selected cell, which would solve the perceived problem with no need of an option that has to be set separately from other UI options. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153694] Localized Bold/Italic/Underline icons
https://bugs.documentfoundation.org/show_bug.cgi?id=153694 --- Comment #8 from Adrian --- Thank you Rizal for your input. Although an option/toggle would be extremely welcome, I fully understand it's extra development effort. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153600] Style organizer's "Next style"'s function not clear to user
https://bugs.documentfoundation.org/show_bug.cgi?id=153600 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |fit...@ubuntu.com, |.freedesktop.org|vsfo...@libreoffice.org --- Comment #7 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #4) > "Inherit from [SomeParent]" is an imperative-form... while "Next Style > [SomeStyle]" is a merely a noun-phrase, whose completion into an imperative > sentence, or perhaps an adjective-phrase, regarding the style being edited > requires a complex transformation. Sometimes using the ideal form of a phrase makes understanding even harder, and this is such a case to me. I cannot follow your argument (and none at the meeting could) that "Next Style" requires a complex transformation. So up to the native or more experienced English speakers to decide. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146623] Enhance Function Wizard Structure Tab for Better Formula Debugging
https://bugs.documentfoundation.org/show_bug.cgi?id=146623 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #8 from Heiko Tietze --- I think we can handle the UX topics on bug 92416. (In reply to Damian Hofmann from bug 92416 comment 6) > What I do not see in the mockup yet is the ability to drill down / debug > further, into referenced cells. Sure, could be done as suggested here. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146623] Enhance Function Wizard Structure Tab for Better Formula Debugging
https://bugs.documentfoundation.org/show_bug.cgi?id=146623 Heiko Tietze changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=92 ||416 --- Comment #7 from Heiko Tietze --- You are right, maybe it's better to keep both. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153334] Support/default to a non-white page background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 --- Comment #16 from Heiko Tietze --- Before such automatic switch could be introduced, the whole application color (AC) concept needs to become updated. Point is that the "LibreOffice Dark" AC is just one random addition to the inbuilt automatic colors. You can remove the set and create something completely different with the same name. One solution is a second automatic value, aka hard-coded color for dark. And a switch to change from light to dark. Easy to realize, however the current AC concept has this feature to become enhanced (as it is done with the "LibreOffice Dark" set). And in this case we do not have two colors for one option. We could remove the capability for change AC. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153334] Support/default to a non-white page background in Dark Mode
https://bugs.documentfoundation.org/show_bug.cgi?id=153334 Heiko Tietze changed: What|Removed |Added CC||l...@disr.it --- Comment #15 from Heiko Tietze --- *** Bug 152184 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152184] Dark Mode: Application Colors > Color Scheme should automatically follow System Settings > Appearance
https://bugs.documentfoundation.org/show_bug.cgi?id=152184 Heiko Tietze changed: What|Removed |Added Resolution|WONTFIX |DUPLICATE --- Comment #14 from Heiko Tietze --- Since the OP in bug 153334 didn't accept the duplicate state let's bring the same requests together the other way. *** This bug has been marked as a duplicate of bug 153334 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153686] No "Automatic" color for table borders
https://bugs.documentfoundation.org/show_bug.cgi?id=153686 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |caol...@redhat.com, |.freedesktop.org|heiko.tietze@documentfounda ||tion.org, ||mikekagan...@hotmail.com Ever confirmed|0 |1 Severity|normal |enhancement Keywords|needsUXEval |needsDevAdvice Summary|Default color for table |No "Automatic" color for |borders in dark mode should |table borders |be white| Status|UNCONFIRMED |NEW --- Comment #2 from Heiko Tietze --- Point is that the border color misses an Automatic color and adding it either without style or using some table style applies a black color. Now I wonder how easy it is to add Automatic to the color options. Mike, Caolan: got a code pointer at hand? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc 7.5 tiny formula bar font for japanese
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 --- Comment #6 from ady --- (In reply to Adolfo Jayme Barrientos from comment #5) > without the need of yet another > customization feature that doesn’t communicate with anything else, IMHO Just a side note... IDK what "communicate with anything else" means. FWIW, I don't have to deal with CTL fonts on a daily basis myself, but since the UI scaling was gone, I have difficulties reading the formula bar content clearly. Since then, I am always using the OS's zoom features when I have to read the content of the formula bar, while I change it again for the rest of the UI (i.e. back and forth). Having the font type and font size of the content of the formula bar configurable / adjustable would greatly increase my ease-of-use and productivity with Calc. There are so many reports with either direct requesting the possibility of formula bar customization, or, worse, reporting some problematic glitch in the formula bar... Anyway, back to this specific bug report. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153527] LibreOffice 7.5 Calc: unable to apply formatting to all cells in spreadsheet
https://bugs.documentfoundation.org/show_bug.cgi?id=153527 --- Comment #12 from Heiko Tietze --- Let's focus on 'apply formatting to all selected cells', and I agree that empty but selected cells should become formatted as well. If this has been done intentionally we better allow to interrupt lengthy operations than blocking / hindering it (see bug 150239). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150239] Show progress while performing lengthy operations and allow to interrupt
https://bugs.documentfoundation.org/show_bug.cgi?id=150239 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Summary|Selecting whole column to |Show progress while |copy data, by accident, |performing lengthy |freeze - how to hard limit |operations and allow to |numbers of rows when|interrupt |running calc? | -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc 7.5 tiny formula bar font for japanese
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 --- Comment #5 from Adolfo Jayme Barrientos --- Us fixing our font rendering would address the issues highlighted in attachment 185470 and 185471 without the need of yet another customization feature that doesn’t communicate with anything else, IMHO -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153694] Localized Bold/Italic/Underline icons
https://bugs.documentfoundation.org/show_bug.cgi?id=153694 --- Comment #7 from Rizal Muttaqin --- Localization is one of the strong aspects that LibreOffice tries to offer. As per my comment written in, LibreOffice supports 119 languages while MS Office only 86 languages (https://support.microsoft.com/en-us/office/what-languages-is-office-available-in-26d30382-9fba-45dd-bf55-02ab03e2a7ec). Whereas in Wikipedia, LibreOffice supports 115 languages while MS Office is listed as supporting 102 languages. I guess here that there is a tendency to reduce localization support in MS Office products. Seeing this kind of positive trend, I think it's very good if all aspects of technology also support it. This includes icons. As mentioned in previous comments that some of these localized formatting icons depend on what UI language is used. That is, the most appropriate solution is to change the UI locale. After all, I'm guessing the reason is because of familiarity, right? Or maybe instead of changing the icon, an additional option/toggle when changing the UI interface e.g. "Localize icon" can help although this solution requires coding so the effort required will be greater. So my take from icon designer point of view is WONTFIX. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153727] Calc 7.5 tiny formula bar font for japanese
https://bugs.documentfoundation.org/show_bug.cgi?id=153727 Heiko Tietze changed: What|Removed |Added Blocks||108660 See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||141 --- Comment #4 from Heiko Tietze --- I don't fully understand what is expected (width or height, first of all). But the sheer number of requests supports the claim for an option. See for example bug 88141, bug 95406, bug 127655 (I suggest to duplicate all into one). Question is whether we should allow full customization (font name, size, weight, color...) or just the size (and adjust the formula bar height accordingly). Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108660 [Bug 108660] [META] Formula bar (input line) bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148764] Icon themes need to include metadata and different variants in one package
https://bugs.documentfoundation.org/show_bug.cgi?id=148764 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists | |.freedesktop.org| Keywords|needsUXEval | --- Comment #10 from Heiko Tietze --- Haven't seen any -1, so let me put the fly in the ointment. Some requirements are mixed here: 1) Lower the packaging burden for icon designers (file structure) 2) Don't use file names as variable in the UI 3) Improve code readability (links.txt) 4) Make variants easier accessible/shiftable (day/night, low/hires) 5) Clean up the UI (confusing list of icon themes in options) Doubt 1) is achieved if the data is not stored in folders but nodes, 2) could be solved easily with some "name.txt" file in the package, 3) somehow the complexity will remain, 4) could be realized per code as today, 5) +1. Following the freedesktop spec (comment 8) adds even more structure. And the alternative is an own icon format similar to Apples icns pack. Not bad per se but requires special tools. Still +1 from my side (no need for more UX input, I guess) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153721] Rename "Move Chapter Up/Down" to "Move Heading+Text Up/Down" in Navigator
https://bugs.documentfoundation.org/show_bug.cgi?id=153721 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|UNCONFIRMED |NEW Keywords|needsUXEval | Ever confirmed|0 |1 --- Comment #3 from Heiko Tietze --- Sounds good. Wonder if the shorter "Move Outline Up/Down" is precise enough and still easy to understand. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153561] Rename "Chapter -> Heading" and "E# -> H#" in Entries tab of Insert Table of Contents, Index, Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153561 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3712 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153712] "Chapter Info" should be named "Heading Info" (or "Heading") and "chapter entry" and its buddy dropdown box labels should be changed
https://bugs.documentfoundation.org/show_bug.cgi?id=153712 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Ever confirmed|0 |1 See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3561 Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #1 from Heiko Tietze --- 1. My take would be "Heading Info" 2. to be discussed, see also bug 153561; in this case it's more reasonable 3. How about "Heading type:" or just "Reference:" 4. "Heading number" introduces another term; and is _number_ correct for ABC... (according the chapter numbering dialog it is, so +1) 5. My first idea was "Numbers only", "Text only", "Number and Text" but maybe we can align with the cross-reference options -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153637] Rename "Use level from source chapter" to "Use outline level from document headings" in Type tab of Insert Table of Contents, Index, or Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153637 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Ever confirmed|0 |1 --- Comment #6 from Heiko Tietze --- By picking "Tables", for example, you insert a ToC with all table captions (excluding the actual caption text) and "Use level from source chapter" indents the entry according to its parent heading level or not. (In reply to sdc.blanco from comment #5) > "Index by outline level of immediately prior heading" Not the length worries me (would be okay without the not needed "immediately" and there is indeed plenty of space) but how naive users would read it. Ideally we start with a verb followed by a noun. Some ideas: [ ] Indent according the source heading level [ ] Apply the style following the source heading [ ] Use level from source heading (smallest modification and easy to read) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153673] "Chapter" label needs improvement in cross-references dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153673 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||2555 CC||mikekagan...@hotmail.com, ||rb.hensc...@t-online.de --- Comment #3 from Heiko Tietze --- Regina, Mike: any insights? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153673] "Chapter" label needs improvement in cross-references dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153673 --- Comment #2 from Heiko Tietze --- Created attachment 185484 --> https://bugs.documentfoundation.org/attachment.cgi?id=185484=edit Screenshot MSO (In reply to sdc.blanco from comment #0) > 2. Before proposing to find another label, let me ask if the "Chapter" > option is needed in this dialog. Heading > Chapter omits the separator like "1.1" vs "1.1:". But I'd naively like you expect that all three Number options return different results. MSO does not list Chapter for any type. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153694] Localized Bold/Italic/Underline icons
https://bugs.documentfoundation.org/show_bug.cgi?id=153694 Heiko Tietze changed: What|Removed |Added Blocks||106228 CC||riz...@libreoffice.org --- Comment #6 from Heiko Tietze --- IMO it's easier to accept the localized version than to learn the untranslated label. My take is WF but up to the icon designer(s). See also bug 120135 and bug 128689 as examples for more localization rather then less and the (even better) idea to use symbols that don't need localization. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=106228 [Bug 106228] [META] Icon theme issues -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153637] Rename "Use level from source chapter" to "Use outline level from document headings" in Type tab of Insert Table of Contents, Index, or Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153637 sdc.bla...@youmail.dk changed: What|Removed |Added Depends on||153751 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=153751 [Bug 153751] Consistent naming of chapter, heading, outline, and level -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153673] "Chapter" label needs improvement in cross-references dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153673 sdc.bla...@youmail.dk changed: What|Removed |Added Depends on||153751 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=153751 [Bug 153751] Consistent naming of chapter, heading, outline, and level -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153694] Localized Bold/Italic/Underline icons
https://bugs.documentfoundation.org/show_bug.cgi?id=153694 --- Comment #5 from Adrian --- I am aware of 4 icons: - Bold (G->B) - Italic (K->I) - Underline (P->U) - Double Underline (P->U) There are mostlikely more languages that this applies to. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153561] Rename "Chapter -> Heading" and "E# -> H#" in Entries tab of Insert Table of Contents, Index, Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153561 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Heiko Tietze --- Chapter No to Heading No is clearly on the todo list. But I don't see why we have to change the E# into H#. It adds a lot of confusion, although it seems the E# has been chosen randomly. And, these identifiers are not localized. Side note: funny, how it was explained for AOO: "The E# button represents the “chapter number”, which means the heading number, not just for chapters but also for other levels of headings." https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/Writer_Guide/Entries_page -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153549] Rename Tools > "Chapter Numbering" to "Heading Numbering"
https://bugs.documentfoundation.org/show_bug.cgi?id=153549 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #11 from Heiko Tietze --- (In reply to sdc.blanco from comment #6) > Could not figure out how to get Style Inspector to show "Para Chapter > Numbering Level" so cannot evaluate whether a change is needed in that > label. RID_PARA_CHAPTER_NUMBERING_LEVEL is ParaChapterNumberingLevel points to UNO_NAME_PARA_CHAPTER_NUMBERING_LEVEL maps to FN_UNO_PARA_CHAPTER_NUMBERING_LEVEL but I cannot find how it comes into play eventually. Maybe per macro? Anyway, relabeling seems cheap. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153485] Tooltip for H icon in Navigator should be "Outline Level"
https://bugs.documentfoundation.org/show_bug.cgi?id=153485 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||riz...@libreoffice.org --- Comment #8 from Heiko Tietze --- Adding Rizal for the icon modification (it depends on the icon theme) -- You are receiving this mail because: You are on the CC list for the bug.
