[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 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #17 from Heiko Tietze --- We could a) stick to the OS/DE: this means NAB b) add an option to tools > options > calc > view: this inflates the options dialog further c) have some kind of interaction on the control, could be a drop down with a couple of font sizes or some ctrl+wheel response specifically on the control: with the drawback that this either holds only a limited number or is hard to figure out for average users d) follow the selected cell's font (maybe all attributes not just the size): does not work for multi-selection with varying content and in case of no selection; has also the drawback of a "jumping" UI e) follow the zoom factor on the sheet: not necessarily what users expect and, like all other options messing-up with the UI, makes the UI imbalanced (thinking of the size of associated icons left-hand and the range selector); plus in multi-line mode with an enlarged font it could become too large f) show the content somewhere else, eg. the functions pane in the sidebar or as balloon tip when hovering over the cell: the formula bar is not intended as "text viewer" for very long text in cells So what is the exact use case that cannot be solved with the formula bar? Reading bug 88141 it seems the user enters long text in cells, which is cut off because of content in neighboring cells and cannot become wrapped for some reason, and uses the formula bar to just read the content. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153350] Allow user to change bibliography citation number structure
https://bugs.documentfoundation.org/show_bug.cgi?id=153350 Dieter changed: What|Removed |Added Blocks||101258 CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=101258 [Bug 101258] [META] Bibliography 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 #16 from V Stuart Foote --- Created attachment 185523 --> https://bugs.documentfoundation.org/attachment.cgi?id=185523=edit 10pt Meiryo and Win10 os/DE display control "Make text bigger" at 125% So reasonable UI values can be set using os/DE controls. Win10 in Dark mode with Meiryo and Meiryo UI installed. font size in cells at 10pt; UI elements: column headings, other UI text scaled 125%, and the inputwin of the Formula bar. So, while it would be nice RFE to allow this element to be scaled independent of os/DE it is "functional" os/DE provided feature. NTL the enhancement would be helpful as defaults for the os/DE should not *have* to be tweaked. -- 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 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #15 from Regina Henschel --- Created attachment 185517 --> https://bugs.documentfoundation.org/attachment.cgi?id=185517=edit screenshot Calc I think the request for a larger font in the formula bar is reasonable. I use Windows with 120% screen scaling. My screenshot shows, that even with the better rendering of black font on white background, the glyphs in the formula bar are not clear enough. -- 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=95 ||406 --- Comment #14 from V Stuart Foote --- bug 88141 is for ability to adjust the size of the font in only the inputwin of the Formula bar, independent of the entire UI or os/DE bug 95406 is for ability to change the font used on the input win. bug 101646 is for LO controlled scaling of the the entire UI -- distinct from the UI scaling os/DE provides. If I were to dupe rather than => NAB, I would say UX issue here is a dupe of bug 88141 -- just need ability to bump up the font size in the Formula bar. -- 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 #13 from V Stuart Foote --- (In reply to iaganicshe from comment #12) > I have default Windows font for japanese which is Meiryo. > Changing default font for specific language is not that easy. > I don't like "Making text bigger across the system" solution, it makes using > other apps inconvenient. For example vertical work space in Firefox is > reduced significantly. "don't like" ≠ not able > I don't think it's a rendering problem. 9pt cells with 100% scaling look > almost the same, and they are also unreadable. For cells I set font to 11pt > and scaling to 120% to work comfortably. agree, not a rendering issue > But formula bar cannot be scaled. Its font size is the same as other UI > elements. Just for hieroglyphs that size is too small, as they contain more > pixels. Understood, and that is the nature of fonts with "coverage" of mixed usage. Meiryo is Microsoft developed for jp-JP use. When its character height is reduced too far the Kanji looks deformed. Open the UI font scale just a bit to get better rendering for applications like LibreOffice that do not provide direct UI scaling like the "enhancements" of the See Also BZ issues listed above. Only those enhancements would address this issue directly, otherwise the os/DE must be scaled, here as provided by Microsoft. -- 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 #12 from iaganic...@gmail.com --- I have default Windows font for japanese which is Meiryo. Changing default font for specific language is not that easy. I don't like "Making text bigger across the system" solution, it makes using other apps inconvenient. For example vertical work space in Firefox is reduced significantly. I don't think it's a rendering problem. 9pt cells with 100% scaling look almost the same, and they are also unreadable. For cells I set font to 11pt and scaling to 120% to work comfortably. But formula bar cannot be scaled. Its font size is the same as other UI elements. Just for hieroglyphs that size is too small, as they contain more pixels. -- 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 --- Comment #4 from sdc.bla...@youmail.dk --- (In reply to RGB from comment #3) Thanks for this useful comment. Have known about the function, but your comment has resulted in my first experiments. > Notice that in recent versions partial TOCs will be build from the current > heading level Just to be sure that I have interpreted "build from the current heading level" correctly. The partial index is created from the immediately prior heading in relation to where the cursor is placed, and only indexes headings have a higher outline level than the immediately prior heading, stopping at (and not including) a subsequent heading that has the same outline level as the "prior heading". (at least that is what my experiments show) > using the chapter option while on a level 3 heading just to be sure: "on a heading" means that the cursor is placed AFTER the heading (not in/on the paragraph with a heading PS). > (the index will show only level 4 and lower) depending on what is set in "Evaluate up to level" > that mean that the "Chapter" label (that only refers to a level 1 heading) is > not valid anymore, it should be "Current heading level" or something like > that. Good point! Perhaps "Heading" is enough. Also this makes me realise that "Evaluate up to level" would benefit from being called "Show up to level" (in line with bug 105628 for "Chapter No." in the Entries tab) -- 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 RGB changed: What|Removed |Added CC||rgb.m...@gmail.com --- Comment #3 from RGB --- (In reply to sdc.blanco from comment #0) > > Scope (of ToC or Index) > > ( ) Entire Document > ( ) Chapter > Notice that in recent versions partial TOCs will be build from the current heading level (for example, if using the chapter option while on a level 3 heading, the index will show only level 4 and lower) and that mean that the "Chapter" label (that only refers to a level 1 heading) is not valid anymore, it should be "Current heading level" or something like that. -- 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 --- Comment #2 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #1) > Don't get this Fair enough. Easier to explain now that "Scope" is not involved. In Type tab, select Type according to first column below. Second column shows what is proposed as the Section title that should replace the current "Create From" Select TypeCurrent "Create From" title should show --- Table of Contents Create Table of Context From Table of Figures Create Table (of Figures) From Index of TablesCreate Index (of Tables) From User-Defined Create Index From Table of Objects Create Table (of Objects) From Additional comments: 1. The parts in parentheses could possibly be dropped. 2. possibly "Index of Tables" -> "Table Index" (probably "Table of Tables" did not work) 3. For Type "Table of Contents", the option Evaluate up to level [] also appears in the "Scope" section. I believe this option can be meaningfully placed underneath the 3 options (Headings, Additional Styles, Index Marks) for the "Create Table of Contents From" section. Where the option would be indented (like the "Use level from source" option in the Used-defined type) 4. This change should give a much cleaner interface. Instead of current interface that is somewhat generic, proposal makes the section titles appropriate and specific to its Type context, and draws attention to the section that decides what to include in the index. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150164] PDF exporter's "Export outlines as named destinations" does not export outlines, but bookmarks
https://bugs.documentfoundation.org/show_bug.cgi?id=150164 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #14 from Heiko Tietze --- (In reply to sdc.blanco from comment #11) > Is the intended behavior of this option: > (a) to only export LO bookmarks, or > (b) should "names of objects" be interpreted as referring to the "Name" > property of images, tables, frames, and OLE objects, which could plausibly > be exported as named destinations. Internally the option is defined at [1] with the description "Specifies that the target documents with .od[tpgs] extension, will have that extension changed to .pdf when the link is exported to PDF. The source document remains untouched." Looking into the implementation [2] it seems to replace the od* extension into pdf. [1] officecfg/registry/schema/org/openoffice/Office/Common.xcs [2] https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/pdfwriter_impl.cxx?r=182e85ae#3655 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153694] Do not localize Bold/Italic/Underline icons
https://bugs.documentfoundation.org/show_bug.cgi?id=153694 --- Comment #10 from Adrian --- I will look into that, thanks! -- 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 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org -- 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 #23 from Heiko Tietze --- (In reply to sdc.blanco from comment #17) > > it remains for someone with an understanding of the architecture to > > determine > > if this is the intended solution. > @Heiko? And more generally -- is the intended behavior accurately described > by the word "Show" up to level" I'm even more noobish than anyone else here ;-). Never stumbled over "Evaluate up to level" but it seems to be equivalent to Show (a H3 is shown if level-up-to is set to 3 but not H4). However, the E# entry also has this option and I cannot wrap my mind around this multidimensional ToC definition. Guess writing a few lines of code to generate the ToC is quicker than trial and error with the existing dialog. We could also treat the "level" as unit like "Show up to [ ] levels" (not so good since it would be a l10n challenge). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 58070] Switching paragraph styles removes explicit text direction choice
https://bugs.documentfoundation.org/show_bug.cgi?id=58070 Heiko Tietze changed: What|Removed |Added Status|NEEDINFO|RESOLVED Keywords|needsUXEval | Resolution|--- |NOTABUG CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #13 from Heiko Tietze --- Why do you expect attributes to be consistent when switching from one style to another? If your default paragraph uses a (directly applied) italic font style it will be removed when switching to any other style. We could turn this question around and ask what you expect when switching from one style to another. Meaning whether all or just the different attributes should be overwritten. Let's say the text is Text Body with the special attribute italic (whether set directly or via style modification doesn't matter). Switching to Heading 1 could mean you expect the font size larger and the bold weight to be applied - in addition to the italic weight. This does not solve the use case to explicitly switch off an attribute, eg. H1 in bold but H2 not. The issue is clearly NAB. -- 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 ||7774 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153694] Do not localize Bold/Italic/Underline icons
https://bugs.documentfoundation.org/show_bug.cgi?id=153694 Heiko Tietze changed: What|Removed |Added Summary|Localized |Do not localize |Bold/Italic/Underline icons |Bold/Italic/Underline icons Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #9 from Heiko Tietze --- The workaround is to "hack" the icon set and delete all localized forms (the program should use the fall-back in this case). Find the icons as zip's under /usr/lib/libreoffice/share/config/ or install another icon theme via extension and check the user space. Search for folders under cmd with locale-id like ar,de,es,fr,hu... Sharing this un-localized icon theme as extension would be a solution for a group of users then. -- 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 #8 from Adolfo Jayme Barrientos --- I agree that the symbol-to-container aspect ratio and the colors can be improved. In fact I am about to push a better color for Math help pages after Mike Kaganski noted it was too similar to Impress'. Mea culpa! Those observations are actionable, self-contained issues that can be addressed in separate, similarly self-contained bugs, minus the knee-jerk reactions. We all act in good faith in contributing to LO. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 151430] Groupedbar Compact UI : missing "columns..." entry of the "format" menu of the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=151430 --- Comment #4 from Heiko Tietze --- Not all functions can be placed on the primary UI; a bit more in case of the Tabbed variant but still not each and every option from the dialogs. It makes sense, however, if changing columns is needed frequently. We should also consider the context menu on the document canvas offering access to the page style dialog. -- 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 #7 from Heiko Tietze --- (In reply to BrendaEM from comment #5) > 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. Sounds like a plan. And if you have experience in icon creation you are very much welcome to create a better set or to join the design team and educate us. -- 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
Heiko Tietze changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|needsUXEval |difficultyMedium, easyHack,
||skillDesign, topicDesign
CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda
|.freedesktop.org|tion.org,
||mentoring@documentfoundatio
||n.org
--- Comment #4 from Heiko Tietze ---
(In reply to sdc.blanco from comment #3)
> 1. Rename "Chapter Styles" to "Document Structure"
sw/inc/app.hrc: { NC_("RID_PARAGRAPHSTYLEFAMILY", "Chapter Styles")... (just
the text in brackets)
> 2. Move "Heading" and "Heading [1-10]" PS from "Text Styles" to "Document
> Structure"
sw/source/core/doc/DocumentStylePoolManager.cxx (would try to move headings
from STR_POOLCOLL_TEXT_ARY into STR_POOLCOLL_DOC_ARY)
--
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 --- Comment #1 from Heiko Tietze --- (In reply to sdc.blanco from comment #0) > Scope (of ToC or Index) > ( ) Entire Document > ( ) Chapter LGTM > Create ToC From > >Evaluate up to level [] (underneath the 3 checkboxes) > > Create Table (of Figures) From > > Create Index (of Tables) From > > Create Index From (User-defined) > > Create Table (of Objects) From Don't get this, at least it does not match the current situation. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153248] Insert Caption and Caption Options dialogs have a mix of settings affecting the whole category or only current caption
https://bugs.documentfoundation.org/show_bug.cgi?id=153248 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3243 -- You are receiving this mail because: You are on the CC list for the bug.
