[Bug 163304] Want a "clone dimensions" command & button
https://bugs.documentfoundation.org/show_bug.cgi?id=163304 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #2 from Regina Henschel --- Select the objects so that the shape which shall be the "master" for the dimension is selected as last one. Use the items "Equalize Height" and "Equalize Width" from the menu "Shape". I think we do not need a further clone size tool. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163304] Want a "clone dimensions" command & button
https://bugs.documentfoundation.org/show_bug.cgi?id=163304 Eyal Rozenberg changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=11 ||4912 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163304] Want a "clone dimensions" command & button
https://bugs.documentfoundation.org/show_bug.cgi?id=163304 --- Comment #1 from Eyal Rozenberg --- Especially useful working on Drawing Objects of course, double-especially in Impress and Draw. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163304] Want a "clone dimensions" command & button
https://bugs.documentfoundation.org/show_bug.cgi?id=163304 Eyal Rozenberg changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 37219] Add exported PDF files to the recent documents list in current desktop environment
https://bugs.documentfoundation.org/show_bug.cgi?id=37219 --- Comment #18 from Mike Kaganski --- *** Bug 66412 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 163274] Want mechanism for automated addition of glue-points around an existing one
https://bugs.documentfoundation.org/show_bug.cgi?id=163274 Eyal Rozenberg changed: What|Removed |Added Summary|Want mechanism for adding |Want mechanism for |more connection-points |automated addition of |around a given point|glue-points around an ||existing one --- Comment #2 from Eyal Rozenberg --- (In reply to Regina Henschel from comment #1) > You know, that you can set your own glue points? Yes, I know that. Let me clarify that I want automation: I don't want to have to leave what I'm doing right now, go to the gluepoints bar, start measuring distances carefully from both sides, making sure I'm right on the rim of the shapes etc. I want LO to do that for me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163274] Want mechanism for adding more connection-points around a given point
https://bugs.documentfoundation.org/show_bug.cgi?id=163274 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #1 from Regina Henschel --- You know, that you can set your own glue points? See section "Gluepoints" in chapter 8 of the DrawGuide and topics "Using Gluepoints" and "Gluepoints Bar" in the help. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163274] Want mechanism for adding more connection-points around a given point
https://bugs.documentfoundation.org/show_bug.cgi?id=163274 Eyal Rozenberg changed: What|Removed |Added Blocks||108741 CC||libreoffice-ux-advise@lists ||.freedesktop.org Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108741 [Bug 108741] [META] Shapes bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163262] Extend the Spotlight feature to highlight list styles, custom list styles
https://bugs.documentfoundation.org/show_bug.cgi?id=163262 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||rayk...@gmail.com, ||vsfo...@libreoffice.org --- Comment #2 from V Stuart Foote --- Reasonable, +1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163260] „Alignment“ dropdown should be converted to 3 buttons like in Impress, Position tab of Bullets-Numbering-Dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=163260 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org Keywords||needsUXEval Summary|„Alignment“ dropdown should |„Alignment“ dropdown should |be converted to 3 buttons |be converted to 3 buttons |like in Impress |like in Impress, Position ||tab of ||Bullets-Numbering-Dialog --- Comment #1 from V Stuart Foote --- +1, the current Alignment buttons in Impress are comfortable to use. Worth the extra bit of space they'll need moved from listbox. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163259] Add Numbering Type selection buttons on the top of the Customize tab of the Bullets-Numbering-Dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=163259
V Stuart Foote changed:
What|Removed |Added
See Also||https://bugs.documentfounda
||tion.org/show_bug.cgi?id=12
||0905
CC||jl...@mail.com,
||vsfo...@libreoffice.org
Summary|Add Numbering Type |Add Numbering Type
|selection buttons on the|selection buttons on the
|top of the Customize tab|top of the Customize tab of
||the
||Bullets-Numbering-Dialog
--- Comment #2 from V Stuart Foote ---
+1, moving the other non-numeric bullet types
('None','Bullet','Graphics','Linked graphics') off of the Numbering listbox in
the Customize tab would improve the UI.
Would think a radio button with label for each to place the dialog into that
mode makes sense.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 163261] Add a note about paragraph DF settings and a „Clear Formatting“ button to the new Bullets and Numbering dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=163261 Gabor Kelemen (allotropia) changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163259] Add Numbering Type selection buttons on the top of the Customize tab
https://bugs.documentfoundation.org/show_bug.cgi?id=163259 --- Comment #1 from Gabor Kelemen (allotropia) --- This is my own idea, not something discussed in bug 120905, so I'm asking for ux-advise approval. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163259] New: Add Numbering Type selection buttons on the top of the Customize tab
https://bugs.documentfoundation.org/show_bug.cgi?id=163259 Bug ID: 163259 Summary: Add Numbering Type selection buttons on the top of the Customize tab Product: LibreOffice Version: Inherited From OOo Hardware: All OS: All Status: UNCONFIRMED Keywords: needsUXEval Severity: enhancement Priority: medium Component: Writer Assignee: libreoffice-b...@lists.freedesktop.org Reporter: kelem...@ubuntu.com CC: libreoffice-ux-advise@lists.freedesktop.org Blocks: 103364 To make the Bullets and Numbering dialog more user friendly, it would be perhaps desirable to remove the main types „Bullet“ „Graphics“ „Linked graphics“ from the Number list, and add these options as buttons at the top of the dialog. „Numbering“ type can be added as a fourth button. This would make them more discoverable and it would feel less „strange“ when the other controls of the dialog are exchanged upon choosing a different type. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103364 [Bug 103364] [META] Bullets and numbering dialog bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163235] Text in textbox not vertically-centered when line spacing is not single
https://bugs.documentfoundation.org/show_bug.cgi?id=163235 --- Comment #5 from Eyal Rozenberg --- (In reply to Tomaz Vajngerl from comment #2) > I get access denied for this image - could be only me however. Not sure why. Try this page: http://www.cyrilchandelier.com/understanding-fonts-and-uifont anyway, it's just for illustrating the metrics. Also, I can't say for sure if the centering is on (ascent - baseline)/2 or (capheight - baseline)/2 (In reply to Regina Henschel from comment #4) Thanks for the semi-bibisection :-) I remember we had this bug about creating an MS Office Compatibility rubrique in other modules, like we have in Writer. We could put such a setting in there (but I of course would expect the bug-for-bug compatibility to be off by default). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163235] Text in textbox not vertically-centered when line spacing is not single
https://bugs.documentfoundation.org/show_bug.cgi?id=163235 --- Comment #4 from Regina Henschel --- After some more tests with versions I have on my disk: It is OK in Version: 6.1.0.0.alpha0+ (x64) Build ID: d73857e7d7f6a5bf38c6a2f396832faabaef65e2 CPU threads: 32; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2017-12-12_17:37:14 Locale: de-DE (de_DE); Calc: group threaded It becomes wrong, but different from current version in Version: 6.1.0.0.alpha0+ (x64) Build ID: cae52b77d48916d819e788675f40da5fe4f7c99c CPU threads: 32; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-21_00:33:18 Locale: de-DE (de_DE); Calc: CL and stays that way till Version: 6.1.0.0.alpha0+ (x64) Build ID: 715114595e0feec49c4d54cc5eb26f13dccb7968 CPU threads: 32; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-02-06_02:09:50 Locale: de-DE (de_DE); Calc: CL Then it got worse in Version: 6.1.0.0.alpha0+ Build ID: 32f42d093d4408666151d03f04823e2bb39e46cd CPU threads: 32; OS: Windows 10.0; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-13_23:25:09 Locale: de-DE (de_DE); Calc: CL And have become more worse in Version: 6.1.0.0.alpha0+ (x64) Build ID: d39a8e791618a40328c0f90bece3cc246dcf57f7 CPU threads: 32; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-06_00:59:07 Locale: de-DE (de_DE); Calc: CL And that is the current state. I hope it helps QA in bibisect. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163235] Text in textbox not vertically-centered when line spacing is not single
https://bugs.documentfoundation.org/show_bug.cgi?id=163235 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Regina Henschel --- I see the correct, expected behavior in version 5.2.6.2. I see the text not centered in version 6.1.3.2. and in current Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f7fbf6504fd6190187f6e4d092af880ba8c7bf6a CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded I have not tested versions in-between. As Powerpoint renders it the same wrong way, I guess, the wrong behavior was introduced for compatibility reasons. I don't know whether there exists a flag to get the old, correct rendering. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163235] Text in textbox not vertically-centered when line spacing is not single
https://bugs.documentfoundation.org/show_bug.cgi?id=163235 --- Comment #2 from Tomaz Vajngerl --- (In reply to Eyal Rozenberg from comment #0) > [1]: https://i.sstatic.net/LwZJF.png I get access denied for this image - could be only me however. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163235] Text in textbox not vertically-centered when line spacing is not single
https://bugs.documentfoundation.org/show_bug.cgi?id=163235 Eyal Rozenberg changed: What|Removed |Added Summary|Text line not |Text in textbox not |vertically-centered when|vertically-centered when |line spacing is not single |line spacing is not single -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163235] Text line not vertically-centered when line spacing is not single
https://bugs.documentfoundation.org/show_bug.cgi?id=163235 Eyal Rozenberg changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Blocks||103494 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103494 [Bug 103494] [META] Textbox bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163235] Text line not vertically-centered when line spacing is not single
https://bugs.documentfoundation.org/show_bug.cgi?id=163235 --- Comment #1 from Eyal Rozenberg --- Seen just for example, with: Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161866] AutoCorrect options: Default settings should respect relationship between "Apply Styles" and "Delete spaces..."
https://bugs.documentfoundation.org/show_bug.cgi?id=161866 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161866] AutoCorrect options: Default settings should respect relationship between "Apply Styles" and "Delete spaces..."
https://bugs.documentfoundation.org/show_bug.cgi?id=161866 Dieter changed: What|Removed |Added Blocks||103341 See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=95 ||433, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||9963, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||9986, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||8876 Summary|Writer AutoCorrect options |AutoCorrect options: |"Delete spaces..." require |Default settings should |"Apply styles" but no |respect relationship |indication this is required |between "Apply Styles" and ||"Delete spaces..." CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #2 from Dieter --- I agree, that it makes no sense to enable these two options by default, if "Apply styles is" off by default. But since "Apply Styles" "works only with “Default Paragraph Style”, “Body Text” or “Body Text, Indented” paragraph styles, and there must be one empty paragraph before the text, if the text is not at the top of a page" [1], "Delete Spaces" seems to be reduced to a very few cases. So I think, it should perhaps be off by default and should only be selectable, if "Apply Styles" is on. At least related to bug 139963 cc: Design-Team for further input and decision [1] https://help.libreoffice.org/25.2/en-GB/text/shared/01/06040100.html?System=WIN&DbPAR=WRITER&HID=cui/ui/applyautofmtpage/ApplyAutoFmtPage#bm_id3147527 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103341 [Bug 103341] [META] AutoCorrect and Word Completion bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163187] Enable clipboard Paste Special dialog (Ctrl+Shift+V) for input to the Find box (QFS)
https://bugs.documentfoundation.org/show_bug.cgi?id=163187 V Stuart Foote changed: What|Removed |Added Blocks||102847 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=102847 [Bug 102847] [META] Quick Find, Search and Replace -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163187] Enable clipboard Paste Special dialog (Ctrl+Shift+V) for input to the Find box (QFS)
https://bugs.documentfoundation.org/show_bug.cgi?id=163187 V Stuart Foote changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Status|RESOLVED|UNCONFIRMED Summary|Ctrl+Shift+V in the Find|Enable clipboard Paste |box triggers the Paste |Special dialog |Special pop-up |(Ctrl+Shift+V) for input to ||the Find box (QFS) Resolution|NOTABUG |--- Severity|normal |enhancement --- Comment #2 from V Stuart Foote --- Oh wait, I see what you're after. You want the Paste special available to the +F Find Bar (and I guess the +H Find and Replace dialog as well). Interestingly, it is available in the new SB Find deck. Seems a reasonable enhancement. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162904] Add font filename and version to character format dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=162904 --- Comment #5 from Regis Perdreau --- Hi, As other tickets ask, we suffer from a lack of information about what LibreOffice actually supports. Some fonts may be inconsistent or not presented as third-party tools do. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163171] Row height increased when you add text, not decreased when you remove it
https://bugs.documentfoundation.org/show_bug.cgi?id=163171 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |bibisectRequest 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.
[Bug 163171] Row height increased when you add text, not decreased when you remove it
https://bugs.documentfoundation.org/show_bug.cgi?id=163171 --- Comment #3 from ady --- (In reply to Eyal Rozenberg from comment #2) > (In reply to ady from comment #1) > > This used to be the behavior up until LO 7.1 (included). I realize I should clarify, JIC. The requested behavior in this report used to be the normal behavior until LO 7.1 (included). The behavior changed after that, probably somewhere LO 7.2 – it is already not shrinking on LO 7.2.7.2. IDK whether the change was/is intentional. As for other regressions, I meant regarding the Automatic Wrap Text property. See for example bugs 159351, 159834, 163099, 163150, all dupes of bug 159690 (and also some topic(s) in the Ask site). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163171] Row height increased when you add text, not decreased when you remove it
https://bugs.documentfoundation.org/show_bug.cgi?id=163171 Eyal Rozenberg changed: What|Removed |Added Version|7.1 all versions|7.2.7.2 release --- Comment #2 from Eyal Rozenberg --- (In reply to ady from comment #1) > This used to be the behavior up until LO 7.1 (included). I guess I have "anti-rosy glasses" for thinking about the past then... Anyway, yeah, there are a lot of row-height-related regressions - but I haven't found one about this specific issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163171] Row height increased when you add text, not decreased when you remove it
https://bugs.documentfoundation.org/show_bug.cgi?id=163171 --- Comment #1 from ady --- (In reply to Eyal Rozenberg from comment #0) > I remember this behavior from ages ago - probably back from OOo. This used to be the behavior up until LO 7.1 (included). I know that in LO 7.2.7.2 the behavior is already as it is in current versions (i.e. the height of the cell does not shrink back when deleting part of the text on a cell that has the Wrap Text property). Please be aware that there are other regressions reported regarding the "Automatic Wrap Text" property, with multiple dupes among those regression reports. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163171] Row height increased when you add text, not decreased when you remove it
https://bugs.documentfoundation.org/show_bug.cgi?id=163171 Eyal Rozenberg changed: What|Removed |Added Blocks||108252 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108252 [Bug 108252] [META] Cell-related bugs and enhancements (including formatting) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163171] Row height increased when you add text, not decreased when you remove it
https://bugs.documentfoundation.org/show_bug.cgi?id=163171 Eyal Rozenberg changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] UNO command to remove mouse-as-pen markings (all and per slide)
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Severity|normal |enhancement Ever confirmed|0 |1 Blocks||86899 Status|UNCONFIRMED |NEW Summary|Add a toggle to make "Mouse |UNO command to remove |pointer as pen" markings|mouse-as-pen markings (all |permanent or temporary |and per slide) Hardware|x86-64 (AMD64) |All --- Comment #20 from Heiko Tietze --- (In reply to Regina Henschel from comment #18) > A different approach could be to make mouse-as-pen drawings always available > after the slideshow ends and provide new additional commands "Erase > mouse-as-pen drawings from current slide" and "Erase mouse-as-pen drawings > from all slides". Sounds good to me too. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=86899 [Bug 86899] [META] Requests for the addition of UNO commands -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 93087] New layouts for LO Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=93087 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #10 from Heiko Tietze --- We briefly discussed the topic in the design meeting. The proposed enhancement is welcome. It needs a before/after example or an implemented prototype to make educated comments on the design. While customizing the layouts as requested in bug 78156 would be great, it doesn't dispense us from shipping good examples. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 151122] Users should be able to select a typeface for their language from among those supporting their language
https://bugs.documentfoundation.org/show_bug.cgi?id=151122 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists | |.freedesktop.org| Keywords|needsUXEval | --- Comment #37 from Heiko Tietze --- We discussed the topic in the design meeting. The use case is to understand what fonts cover the glyphs of a language. Eyal wrote a nice summary at https://listarchives.libreoffice.org/global/design/2024/msg00117.html. It needs clarification whether the font a) needs to be chosen before typing, in this case we have no information what about the user's intention and need different methods while b) applying a font to a selection could analyze the used glyphs in the background. We pondered over the idea with the "live preview", which is working in Writer too. A checkbox "[ ] Fonts covering the selection" in the character dialog could support the selection of an appropriate font but wont cover use case b). This filtering could also be done after typing and tag fonts that can be used, eg showing a checkmark next to the name. Some cornercases like multi-selection needs to be addressed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162967] Want access from borders toolbar menubutton to Format > Cells... Borders pane
https://bugs.documentfoundation.org/show_bug.cgi?id=162967 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needsUXEval |difficultyMedium, easyHack, ||skillCpp, topicUI CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||kira.t...@gmail.com Status|UNCONFIRMED |NEW --- Comment #5 from Heiko Tietze --- We discussed the topic in the design meeting and there was a broad consensus about this additional button in favor of convenience over simplicity. The implementation could follow the Underline widget. Code pointer: svx/uiconfig/ui/textunderlinecontrol.ui svx/source/sidebar/text/TextUnderlineControl.cxx svx/uiconfig/ui/floatingframeborder.ui svx/source/tbxctrls/tbcontrl.cxx Something for you, Kira? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 151122] Users should be able to select a typeface for their language from among those supporting their language
https://bugs.documentfoundation.org/show_bug.cgi?id=151122 --- Comment #36 from Mike Kaganski --- Filtering is IMO not entirely correct approach; but when the language is given (which must then always accompany places where the font list is given - e.g., language selection would appear in Special Characters dialog) - the list could be split into e.g. top part with "fonts covering the (relevant part of) Unicode range", and bottom part (possibly after a separator) with fonts that don't, preferably with a icon which would contain the language name (e.g., BUL) striken out, and a tooltip telling that it doesn't support the chosen language; or an infobar (including the dialogs, like the warnings we provide elsewhere) about the fact that the chosen font doesn't include the characters needed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162878] Reworked localized Impress templates look ugly in RU
https://bugs.documentfoundation.org/show_bug.cgi?id=162878 Commit Notification changed: What|Removed |Added Whiteboard|target:25.2.0 target:24.8.2 |target:25.2.0 target:24.8.2 ||target:24.8.3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162878] Reworked localized Impress templates look ugly in RU
https://bugs.documentfoundation.org/show_bug.cgi?id=162878 --- Comment #29 from Commit Notification --- Laurent Balland committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/b0f6fc26231a5bfc7869645a3001088aa2e726dd tdf#162878 Freshes template: autosize for title It will be available in 24.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 151122] Users should be able to select a typeface for their language from among those supporting their language
https://bugs.documentfoundation.org/show_bug.cgi?id=151122 Eyal Rozenberg changed: What|Removed |Added Summary|Need way to avoid selecting |Users should be able to |fonts which don't cover the |select a typeface for their |relevant language Unicode |language from among those |range |supporting their language --- Comment #35 from Eyal Rozenberg --- I'm rephrasing the title to focus on the typical user's perspective rather than the power user who is interested in Unicode range coverage. (And of course I should have opened this bug with a comment from that perspective...) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 93087] New layouts for LO Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=93087 --- Comment #9 from Eyal Rozenberg --- (In reply to Bastián Díaz from comment #0) > Mockups: Repeating a comment I made at the design meeting: Personally I can't know whether I like the new layouts or not without seeing "before" vs "after" images. The layout mockups are in themselves sufficient to make a decision: I need an actual slide laid out in the existing layout and the new layout, then I can tell when I think they're better. Also, it's theoretically possible I (or anybody else) would like some of the layouts, and disapprove of other layouts. Too bad more people have noticed this bug before! It shouldn't have taken 9 years to review this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163140] Add an option to fully embed fonts when exporting to PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=163140 --- Comment #6 from Mirto Busico --- Just my 2 cents. You can see the embedding status of fonts with the Open Source pdffont utility As an example my last writer file exported as PDF says pdffonts hosepla_book.pdf name type encoding emb sub uni object ID - --- --- --- - BA+LiberationSans-Bold TrueType WinAnsi yes yes yes 2126 0 CA+LiberationSansTrueType WinAnsi yes yes yes 2106 0 DA+LiberationSerif TrueType WinAnsi yes yes yes 2121 0 EA+LiberationSerif-Bold TrueType WinAnsi yes yes yes 2101 0 FA+LiberationSerif-ItalicTrueType WinAnsi yes yes yes 2111 0 GA+LiberationMonoTrueType WinAnsi yes yes yes 2131 0 HA+LiberationMono-Bold TrueType WinAnsi yes yes yes 2136 0 IA+DejaVuSansMonoTrueType WinAnsi yes yes yes 2116 0 JA+NotoColorEmojiType 3Custom yes yes yes 2139 0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #19 from Aidar --- (In reply to Regina Henschel from comment #18) > A different approach could be to make mouse-as-pen drawings always available > after the slideshow ends and provide new additional commands "Erase > mouse-as-pen drawings from current slide" and "Erase mouse-as-pen drawings > from all slides". Looks perfect to me. --- (In reply to Aidar from comment #17) > When I set “Presentation display” to any single display, tens of different > objects are created per “Mouse pointer as pen” line. Upon further experiments, it seems it is not multiple monitors per se that causes this, but rather “Presenter console” that can only be shown when there are multiple monitors in place. When “Presenter console” is “Disabled”, Impress behaves perfectly, with one new object (Polyline with 15 corners) per PEN line. When “Presenter console” is “Fullscreen” or “Windowed”, the problem reproduces, tens of different objects are created per PEN line. One would guess that since “Presenter console” has a small mirror image of what is happening on main “Presenter display”, including “Mouse pointer as pen” drawings in real time, perhaps, “Presenter console” wrestles away control/focus from “Presenter display”, thereby interrupting/interfering with LibreOffice Impress ability to focus on saving contiguous PEN line as a singe object. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #18 from Regina Henschel --- A different approach could be to make mouse-as-pen drawings always available after the slideshow ends and provide new additional commands "Erase mouse-as-pen drawings from current slide" and "Erase mouse-as-pen drawings from all slides". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #17 from Aidar --- @Buovjaga, thank you for reproducing & registering Bug 163124 – “Context menu for Mouse pointer as pen broken” with such an incredible speed! --- @Heiko, thank you for soliciting the use case, here you go: One reads the same presentation (same file) online to many different customers. During the speech and Q&A, one uses incredibly useful “Mouse pointer as pen” to draw attention to different parts of slides. When the presentation is over, based on customer’s feedback, one can rearrange/change things, rephrase statements, correct misprints, add new notes. Then click Save. Unfortunately, due to “Mouse pointer as pen” permanence, some slides in the presentation may end up riddled with unnecessary PEN scribbles (that make it unusable for the next customer), along with some useful abovementioned changes. How does one cleanse the presentation from the unnecessary PEN scribbles that were accidentally saved? Is the share of users that likewise treat PEN scribbles as something temporary sizable enough to treat this as a special case worth addressing? --- The proposed solution with toggle would address the issue, because “unsavable” temporary PEN scribbles would never end up saved in the presentation. If there was a (optional) button that would cleanse the presentation from “Mouse pointer as pen” scribbles (in one transaction, subject to standard Undo/Redo), even if those scribbles had already been saved, that would also address the problem. Though one would have to ensure that it is routinely clicked, so that each new customer gets “fresh” presentation. --- Perhaps, a great workaround for this use case would be ZoomIt utility by Mark Russinovich (https://learn.microsoft.com/en-us/sysinternals/downloads/zoomit). Since it is a separate onscreen drawing tool, its mouse drawings could never get saved in the presentation. One has a choice: - ZoomIt utility for temporary mouse drawings - “Mouse pointer as pen” for permanent drawings That would satisfy @Buovjaga’s concern about those who’d rather their PEN drawings saved. --- @Regina, thank you for the screencast that demonstrates perfect “Mouse pointer as pen” behavior. I compared the values in Slide Show Settings to mine and found the culprit! “Presentation display” is grayed out on your screencast, which likely means that you have one (big) monitor. I have three monitors: laptop screen and two external (with different resolutions, if that is relevant). When I set “Presentation display” to “All displays”, Impress behaves perfectly, with one new object (Polyline with 15 corners) per line, as in your screencast. When I set “Presentation display” to any single display, tens of different objects are created per “Mouse pointer as pen” line. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163140] Add an option to fully embed fonts when exporting to PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=163140 Heiko Tietze changed: What|Removed |Added CC||michael.st...@allotropia.de ||, vmik...@collabora.com --- Comment #5 from Heiko Tietze --- Duplicate of bug 50879 "form exported as pdf does not embed all required fonts" (patch submitted by Miklos in https://gerrit.libreoffice.org/c/core/+/99032) or bug 78216 "PDF export should not remap embedded font". At least related is bug 78216 "PDF export should not remap embedded font". And there is bug 85295 - PDF: handling of embedded fonts, glyphs, subsets with the statement from Michael Stahl "PDF does not embed fonts, it embeds those glyphs which are used." and many more tickets. File > Properties > Font offers "[x] Embed fonts in the document" and "[ ] Only embed fonts that are used in documents" - is this options respected on export to PDF? But at https://kdp.amazon.com/en_US/help/topic/G202145450 I read: "You can find out if the fonts are embedded by opening the file in Adobe Acrobat and checking under the File/Properties on the Fonts tab. Every font in the list needs to show "Embedded" or "Embedded Subset" for your file to work.", nothing about a restriction to complete fonts. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163140] Add an option to fully embed fonts when exporting to PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=163140 V Stuart Foote changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 --- Comment #4 from V Stuart Foote --- sorry s/liked/linked/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163140] Add an option to fully embed fonts when exporting to PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=163140 --- Comment #3 from V Stuart Foote --- (In reply to Heiko Tietze from comment #2) > Please elaborate on the need to export the entire font. What use case is not > covered with the current implementation? See the liked Ask question. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163140] Add an option to fully embed fonts when exporting to PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=163140 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #2 from Heiko Tietze --- Please elaborate on the need to export the entire font. What use case is not covered with the current implementation? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #16 from Regina Henschel --- The annotations are turned to shapes in method SlideshowImpl::endPresentation() by call of registerUserPaintPolygons. https://opengrok.libreoffice.org/xref/core/sd/source/ui/slideshow/slideshowimpl.cxx?r=032cf092#1602 There maPresSettings.mbMouseAsPen is evaluated and creating shapes is only done if this setting is true. If the slideshow settings had an additional flag "Keep annotations after presentation has finished", it could be evaluated there. The struct PresentationSettings itself is in https://opengrok.libreoffice.org/xref/core/sd/inc/drawdoc.hxx?r=032cf092#98 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163140] Add an option to fully embed fonts when exporting to PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=163140 V Stuart Foote changed: What|Removed |Added Blocks||103378 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||mikekagan...@hotmail.com, ||vsfo...@libreoffice.org Keywords||needsDevEval, needsUXEval --- Comment #1 from V Stuart Foote --- IIUC our font embedding (File -> Properties -> Font tab) subsets into ODF, but with poppler export to PDF it also renames the font to meet PDF needs. Would we need to add an 'Export' control(s) to the Font tab? Also there are font file format issues with .cff, .woff, .otf, .ttf and then each font carries its own permissions as to allowing subset or full-embedding as licensing. Seems a real can of worms to attempt full font embedding. An equally viable approach for users needing to publish to PDF might be authoring with "do not require embedding" fonts, the "base 14" Courier (Regular, Oblique, Bold, Bold Oblique), Helvetica (Regular, Oblique, Bold, Bold Oblique), Times (Roman, Italic, Bold, Bold Italic), Symbol, and ITC Zapf Dingbats Which is what we've already done with fields in our PDF forms export to assure our exported form fields are fully editable. Just not seeing the need to attempt this. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103378 [Bug 103378] [META] PDF export bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 Buovjaga changed: What|Removed |Added Ever confirmed|1 |0 Status|NEEDINFO|UNCONFIRMED --- Comment #15 from Buovjaga --- (In reply to Heiko Tietze from comment #14) > I struggle to understand the issue now. Is it the toggle to make the “Mouse > pointer as pen” permanent? This would be a solution for what use case > exactly? And if we talk about too many objects done with the pen where you > click each item and press delete, why not group it (could be done > automatically)? > > So let's please start again with the actual use case (with a short > description and no attachments *g*). Currently the markings *are* permanent. Aidar is asking for an option to make them temporary, which I think is a risk in case of accidental activation or forgetfulness on the part of users. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #14 from Heiko Tietze --- I struggle to understand the issue now. Is it the toggle to make the “Mouse pointer as pen” permanent? This would be a solution for what use case exactly? And if we talk about too many objects done with the pen where you click each item and press delete, why not group it (could be done automatically)? So let's please start again with the actual use case (with a short description and no attachments *g*). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #13 from Buovjaga --- (In reply to Aidar from comment #10) > Created attachment 196664 [details] > Context menu does not show up upon 1st right-click. Instead, Cut-Copy-Paste > shows up This is reported as bug 163124. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #12 from Regina Henschel --- Created attachment 196667 --> https://bugs.documentfoundation.org/attachment.cgi?id=196667&action=edit screencast Attached is a screen-cast. You can see, that for the line in the slideshow only one shape is generated. So I wonder what is different on your side. I have used Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #11 from Aidar --- Created attachment 196665 --> https://bugs.documentfoundation.org/attachment.cgi?id=196665&action=edit Proper context menu shows up upon 2nd right-click -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #10 from Aidar --- Created attachment 196664 --> https://bugs.documentfoundation.org/attachment.cgi?id=196664&action=edit Context menu does not show up upon 1st right-click. Instead, Cut-Copy-Paste shows up -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121
--- Comment #9 from Aidar ---
(In reply to Regina Henschel from comment #8)
>
> Enable Mouse pointer as PEN in the Slideshow settings _before_ you start the
> slide show. Do you still get such huge number of objects then?
@Regina, thank you so much for your kind offer and the relevant macros!
I will be using https://ask.libreoffice.org/c/english/5 for macros-related
inquiries then.
On the first glance, if there are no “Mouse as a PEN” markings in the new
presentation, the macros starts, oLayerManager.hasByName("DrawnInSlideshow")
condition evaluates to false, the macros ends.
On the other hand, if there are “Mouse as a PEN” markings,
oLayerManager.hasByName("DrawnInSlideshow") seems to be always true, regardless
of how many times the loop executes. Laptop CPU is at about 12,5% (which means
one of its cores is at 100% serving the loop), fan becomes noisy, macros has to
be stopped manually after few minutes.
It seems to be more efficient though to try to address the underlying cause,
leaving finding out why LibreOffice Impress 24.8.1.2 does not obey macros’
instructions to clear out all the sticky traces of “Mouse as a PEN” markings to
a later stage.
As for “Mouse pointer as PEN”, my understanding is that there are two places
where it can be enabled:
(1) Upper Menu “Slide Show” -> “Slide Show Settings” -> “Mouse pointer as PEN”
I always exclusively have been using the Upper Menu.
(2) Right-click on the running Slide Show (Context Menu).
I never use this one, because for some reason context menu does not show up
upon 1st right-click. Instead, greyed out Cut-Copy-Paste shows up, as shown on
attached screenshot. Sometimes, Fullscreen exits upon right-click to show
greyed out Cut-Copy-Paste. Proper context menu shows up upon 2nd right-click.
So, to answer your question, when I reproduce the problem, naturally, Enable
Mouse pointer as PEN in the Slideshow settings is always enabled _before_ I
start the slide show. That is the only way I use it, and it consistently yields
such a huge number of objects.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121
--- Comment #8 from Regina Henschel ---
(In reply to Aidar from comment #7)
> Created attachment 196659 [details]
> Blank presentation created locally in using LibreOffice Impress 24.8.1.2,
> added Mouse pointer as a PEN drawing during local Slide Show, resulted in
> 70+ objects
Enable Mouse pointer as PEN in the Slideshow settings _before_ you start the
slide show. Do you still get such huge number of objects then?
To remove all annotations after being back from show mode, you can try this
macro:
sub EraseAllMouseAsPenAnnotations
dim oDocument as object: oDocument = ThisComponent
dim oLayerManager as object: oLayerManager = oDocument.LayerManager
do while oLayerManager.hasByName("DrawnInSlideshow")
oLayerManager.remove(oLayerManager.getByname("DrawnInSlideshow"))
loop
end sub
Make a copy of the file, open the copy, run the macro and save the document. If
you need help on how to use the macro, please ask on
https://ask.libreoffice.org/c/english/5. When you use @Regina there, I'll be
notified and can give you a step-by-step description.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 Aidar changed: What|Removed |Added Attachment #196658|Presentation created at |Presentation created at description|Google Docs, downloaded as |Google Docs, downloaded as |ODP Document, then added|ODP Document, then added |Mouse pointer as a PEN |Mouse pointer as a PEN |drawing using LibreOffice |drawing using LibreOffice |Impress 24.8.1.2|Impress 24.8.1.2, resulted ||in 70+ objects -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #7 from Aidar --- Created attachment 196659 --> https://bugs.documentfoundation.org/attachment.cgi?id=196659&action=edit Blank presentation created locally in using LibreOffice Impress 24.8.1.2, added Mouse pointer as a PEN drawing during local Slide Show, resulted in 70+ objects -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #6 from Aidar --- Created attachment 196658 --> https://bugs.documentfoundation.org/attachment.cgi?id=196658&action=edit Presentation created at Google Docs, downloaded as ODP Document, then added Mouse pointer as a PEN drawing using LibreOffice Impress 24.8.1.2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #5 from Aidar --- (In reply to Regina Henschel from comment #4) > > Is it an old presentation or do you use an old LO version? With a new > presentation made in LO 24.2 or 24.8 you should not get so many distinct > objects, see bug 112687. A continues drawing should result in one object. > Only when you release mouse button a new drawing should start. I only used the latest LibreOffice Impress 24.8.1.2 while on this case. The presentation with 400 objects per short PEN line was originally downloaded from https://docs.google.com/presentation as “ODP document”. Having received your reply, I have just created two new presentations (attached): - “Google Docs to LibreOffice Impress 24.8.1.2.odp” - “LibreOffice Impress 24.8.1.2 new presentation entirely offline.odp” As names imply, the first has been created at https://docs.google.com/presentation, then downloaded as “ODP document”. The second was created offline using LibreOffice Impress 24.8.1.2. In both cases a short line was drawn by “Mouse pointer as pen” during Slide Show with LibreOffice Impress 24.8.1.2 locally on Windows 11 x64, then saved. Mouse button was released only once, at the end of the line. In both cases 70+ objects were created. So it is a new blank presentation created with the latest LibreOffice Impress 24.8.1.2 where the issue seems to be reproducing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #4 from Regina Henschel --- (In reply to Aidar from comment #3) > Created attachment 196657 [details] > Small contiguous Mouse pointer as PEN drawing is not a single artifact, but > contains 400 distinct objects Is it an old presentation or do you use an old LO version? With a new presentation made in LO 24.2 or 24.8 you should not get so many distinct objects, see bug 112687. A continues drawing should result in one object. Only when you release mouse button a new drawing should start. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #3 from Aidar --- Created attachment 196657 --> https://bugs.documentfoundation.org/attachment.cgi?id=196657&action=edit Small contiguous Mouse pointer as PEN drawing is not a single artifact, but contains 400 distinct objects -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 --- Comment #2 from Aidar --- @Bouvjaga, thank you for the super useful tip regarding the “Navigator”, it saved the day! Indeed, a toggle that “protects” presentations from permanent PEN markings, frees a user from this issue would be a perfect solution. Using the “Navigator” tool that you recommended, one discovers that small contiguous "Mouse pointer as pen" drawing is not a single artifact, but contains 400 distinct objects. Could be thousands in bigger PEN drawings (screenshot attached). Indeed, "Navigator" seems like the perfect way to surgically choose them all, to delete an unnecessary, accidentally saved PEN drawing from a complex presentation. >From UX perspective, for technically unsavvy users, perhaps, an easier, specialized way should exist specifically for PEN presentation drawings, maybe working on top of forthcoming Navigator’s ability to delete all elements of certain content type that you mentioned. A naturally ephemeral, imprecise, temporary PEN mouse drawing, it seems, should not be so sticky, one click away from being almost unremovable from the presentation, with sheer number of objects, unless a technical tool such as object Navigator is employed. Looking forward to the new Navigator feature that already exists in the LibreOffice Writer that would enable to “get rid of all PEN markers” without carefully going through all consecutive relevant objects in Navigator, selecting hundreds of them while watching the selection on WYSIWYG slide, to ensure no preexisting objects get deleted with temporary (accidentally saved) PEN markers. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163121] Add a toggle to make "Mouse pointer as pen" markings permanent or temporary
https://bugs.documentfoundation.org/show_bug.cgi?id=163121 Buovjaga changed: What|Removed |Added OS|Windows (All) |All Summary|“Mouse pointer as pen”: (1) |Add a toggle to make "Mouse |a toggle to make it |pointer as pen" markings |permanent <-> temporary,|permanent or temporary |(2) an easy way to remove | |accidentally saved PEN | |markings from complex | |multi-layered slide | CC||ilmari.lauhakangas@libreoff ||ice.org, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Blocks||104536 --- Comment #1 from Buovjaga --- (In reply to Aidar from comment #0) > The solution could have been simple: manually delete all unnecessary PEN > markings after the end of the presentation. No big deal. > > The problem is that in complex presentation, objects (backgrounds) are > layered on top of each other to achieve the perfect composition on a slide. > Unfortunately, LibreOffice Impress 24.8.1.2 does not seem to save PEN > marking as the foremost front layer. You can use the Navigator panel in the Sidebar to easily select any shape. Recently Writer's Navigator acquired the ability to delete all elements of a certain content type: d5143c058bfdc0f5674c3e0a88fae2f9cbe28a0a Impress and Draw don't have this yet. In any case, there should only be one issue per report, so let's make this about the toggle proposal. > 2) Would it make sense to add a toggle that makes “Mouse pointer as pen” in > “Slide Show Settings” either permanent (savable) or temporary? > > Some would like to save their PEN markings made during the presentations to > illustrate some point, then share the modified presentation with listeners. > In other cases PEN markings are always temporary, only ruin the slides when > accidentally saved, along with useful corrections to some other slides, > during post-presentation work. I feel this could be dangerous as it could cause accidental data loss. Let's loop UX into this. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=104536 [Bug 104536] [Meta] Improvements to the annotation (pen) feature -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 135501] Change the default UI (summaries in comment 67, comment 89, comment 133)
https://bugs.documentfoundation.org/show_bug.cgi?id=135501 Heiko Tietze changed: What|Removed |Added Depends on||163117 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=163117 [Bug 163117] Special label for commands on the Notebookbar -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162878] Reworked localized Impress templates look ugly in RU
https://bugs.documentfoundation.org/show_bug.cgi?id=162878 Laurent Balland changed: What|Removed |Added Keywords|needsUXEval | Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #28 from Laurent Balland --- I pushed Freshes in master, and open bug 163116 to fix this bug (pb with too long titles in placeholders) and separate the bug of remaining Lorem text. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162878] Reworked localized Impress templates look ugly in RU
https://bugs.documentfoundation.org/show_bug.cgi?id=162878 --- Comment #27 from Commit Notification --- Laurent Balland committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c2017f839162a5236afcd73636ecfa73349b9ea9 tdf#162878 Freshes template: autosize for title It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161972] Inserting new comment in Calc disables the "show all comments" setting
https://bugs.documentfoundation.org/show_bug.cgi?id=161972 --- Comment #9 from ady --- (In reply to Heiko Tietze from comment #8) > How about a tri-state toggle, and better naming of the command (bug 140615)? > > View > [x] All Comments > * all shown, create visible > View > [ ] All Comments > * all hidden, create hidden > View > [/] All Comments > * some hidden, create visible Let's recap. The current menu entry is working correctly; there is no bug there. The problem is that a user might not understand the effects of the shown toggle ON/OFF. The proposed tri-state toggle in comment 8 doesn't solve the potential slight temporal misunderstanding of the current behavior of the toggle status, and worse, it blocks (i.e. does not allow) the current status behavior, which is: [x] Whichever the prior status (shown/hidden) of any comment in the currently-shown worksheet, now show (un-hide) all the _current_ comments in it; [ ] Some comments might be hidden; ... and with both statuses, newly created comments are initially hidden (with its reasoning as explained in comment 3). In case someone is not seeing the detail, the proposed tri-state does not allow the current behavior. Instead of changing the meaning and effects of the menu entry, and even blocking the current behavior, the solution is to improve the documentation (Help Content) with one paragraph, explaining the meaning of the toggle (ON/OFF) with better wording. If a user wants every single (new) comment to be shown, then that user can create (i.e. insert) them and then act on the current menu entry, once. I still see no good reason to change the current behavior, and even worse, blocking it. If the source of this "problem" is lack of intuitive meaning/effects of the menu entry, the proposed tri-state does not improve its (intuitive) understanding at all, and better documentation would be needed anyway. Instead, just improve the documentation of the current behavior, without the need to over-complicated menu entries (which – worth saying it again – blocks the current behavior instead of only adding possibilities to the current one). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162984] LibreOffice uses fake small caps even when font supports true small caps
https://bugs.documentfoundation.org/show_bug.cgi?id=162984 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||jonat...@libreoffice.org --- Comment #10 from Heiko Tietze --- This is a topic for Jonathan. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162878] Reworked localized Impress templates look ugly in RU
https://bugs.documentfoundation.org/show_bug.cgi?id=162878 --- Comment #26 from Commit Notification --- Laurent Balland committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/842b73dc2ca0828bb0b3043b7823f4d7d172411d tdf#162878 GrowingLiberty template: autosize for title It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162984] LibreOffice uses fake small caps even when font supports true small caps
https://bugs.documentfoundation.org/show_bug.cgi?id=162984 V Stuart Foote changed: What|Removed |Added URL||https://ask.libreoffice.org ||/t/small-caps-how-to-do-it/ ||25777 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 106249] Should not routinely expose the draw:frame draw:text-box and overwrite OLE objects, e.g. F2 opening text-box of an OLE Formula in Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=106249 --- Comment #11 from Heiko Tietze --- Shortcuts are assigned exclusively to commands- unless assigned per module, which is questioned here. However, a new command uno:EditObject could run any action depending on the selected object. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162984] LibreOffice uses fake small caps even when font supports true small caps
https://bugs.documentfoundation.org/show_bug.cgi?id=162984 V Stuart Foote changed: What|Removed |Added Keywords||needsUXEval Status|NEW |UNCONFIRMED CC||libreoffice-ux-advise@lists ||.freedesktop.org Severity|minor |enhancement Ever confirmed|1 |0 --- Comment #9 from V Stuart Foote --- (In reply to Sascha from comment #8) > > Come on really? Could someone maybe identify a Monospaced font with OTF > > :smcp table support. I sure can't... > > Triplicate is a pretty popular one: > https://practicaltypography.com/triplicate.html Too rich for my blood... Should have qualified a SIL licensed FLOSS relevant Monospaced font with OTF :smcp support. Otherwise, if font supports :scmp user can/should just enable it via Character dialog's Features... button for the selection/paragraph they're working on. Or directly enter it in the font listbox (TB or SB). Enhancement of auto-detection that font supports :smcp feature and applying via Font Effects 'Small capitals' Case selection is feasible but not much of a priority. Pass it on for UX-advise for a decision on enhancement. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 106249] Should not routinely expose the draw:frame draw:text-box and overwrite OLE objects, e.g. F2 opening text-box of an OLE Formula in Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=106249 V Stuart Foote changed: What|Removed |Added Summary|Expose OLE draw:frame |Should not routinely expose |draw:text-box to|the draw:frame |selectively control |draw:text-box and overwrite |overwriting of OLE objects, |OLE objects, e.g. F2 |e.g. an OLE Formula in |opening text-box of an OLE |Impress opened with F2 |Formula in Impress --- Comment #10 from V Stuart Foote --- shortcut has no explicit meaning to edit or insert. Rather we assign the key per module, and simply assign a module specific UNO to each, no OLE dependency: Calc -- .uno:SetInputMode "Cell Edit Mode" (tt. Cell Edit Mode) Impress -- .uno:Text "Text Box" (tt. Insert Text Box (double click for multi-selection)) Draw -- .uno:Text "Text Box" (tt. Insert Text Box (double click for multi-selection)) Writer -- .uno:InsertFormula "Edit Formula" (tt. Insert or Edit Formula) Math -- no assignment Making some sort of LibreOffice generalized shortcut doesn't make a lot of sense, and the concerns of applying draw:text-box annotation over an OLE's draw:frame doesn't justify clobbering our legacy shortcut assignments across the modules. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 159286] Single click inside text field should select full field if it has the placeholder text
https://bugs.documentfoundation.org/show_bug.cgi?id=159286 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #7 from Heiko Tietze --- The dummy text "Click here to enter text" is entirely selected after inserting via Form > Content Control > Plain Text. But it's not selected once the text has been changed (although I couldn't figure out what exactly this means since adding a space keeps the behavior). If the form control contains text everything works like with ordinary paragraphs and one has to double/triple click for selection. Changing this might be beneficial in some scenarios while other require no selection. I wouldn't change the behavior but it also makes sense to follow MSO's example. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 106249] Expose OLE draw:frame draw:text-box to selectively control overwriting of OLE objects, e.g. an OLE Formula in Impress opened with F2
https://bugs.documentfoundation.org/show_bug.cgi?id=106249 --- Comment #9 from Heiko Tietze --- The technical implementation is obviously different from the user expectation. If F2 is seen as "Edit" (without the addition of a particular object), we should follow John's suggestion. On the other hand, to "edit a slide", ie. when no object is selected, should remain to "insert a text box". Slightly inconsistent. What I like at the proposal is to assign a function key with a very generic function. F2 could also open the paragraph properties in Writer (or Character in case of a selection). And we could introduce another shortcut to insert a text box. This would be a major change affecting many users. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 159286] Single click inside text field should select full field if it has the placeholder text
https://bugs.documentfoundation.org/show_bug.cgi?id=159286 Oliver Specht (CIB) changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |oliver.spe...@cib.de |desktop.org | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 159286] Single click inside text field should select full field if it has the placeholder text
https://bugs.documentfoundation.org/show_bug.cgi?id=159286 Oliver Specht (CIB) changed: What|Removed |Added Resolution|INSUFFICIENTDATA|--- Status|RESOLVED|NEW --- Comment #6 from Oliver Specht (CIB) --- The fields are FORMTEXT fields. Stored in ODF as They are used in forms where the text outside of the fields is protected. Therefore these fields cannot be removed but only the content can be changed. In Word they are by default filled with 4 En Space characters. In the default state Word selects the content on a click into the field. If the content is non default then the content is not selected on a single click. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161972] Inserting new comment in Calc disables the "show all comments" setting
https://bugs.documentfoundation.org/show_bug.cgi?id=161972 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||0615 --- Comment #8 from Heiko Tietze --- How about a tri-state toggle, and better naming of the command (bug 140615)? View > [x] All Comments * all shown, create visible View > [ ] All Comments * all hidden, create hidden View > [/] All Comments * some hidden, create visible Click on [/] All Comments could either uncheck the option or check, I see no preference for one. We should consider the two commands uno:ShowAnnotations (used in the main menu) and uno:ShowAllNotes/uno:HideAllNodes (introduced with bug 84837). Single comments can be changed with uno:NoteVisible or uno:ShowNote/uno:HideNote, making the maintenance and customization difficult. I would reduce it to two commands: uno:ShowAnnotations (with the modifications as discussed) and uno:ShowNote (to keep the label similar) that would also toggle the visibility on/off. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161972] Inserting new comment in Calc disables the "show all comments" setting
https://bugs.documentfoundation.org/show_bug.cgi?id=161972 --- Comment #7 from ady --- (In reply to Gabor Kelemen (allotropia) from comment #6) > That is exactly the problem. This current behavior (it's BOTH a status > indicator AND an action button) makes less sense than making it a toggle. The meaning of this "status", when ON, is: "all your current comments are currently displayed; there is no hidden comments at this moment". The meaning of this "status", when OFF, is: "(beware) there might be hidden comments". The ON status of this menu entry is not meant as "every new comment should be automatically displayed, not hidden". It is not a "setting", but an "action". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161972] Inserting new comment in Calc disables the "show all comments" setting
https://bugs.documentfoundation.org/show_bug.cgi?id=161972 Gabor Kelemen (allotropia) changed: What|Removed |Added Resolution|NOTABUG |--- Status|RESOLVED|REOPENED --- Comment #6 from Gabor Kelemen (allotropia) --- Let me reopen this. The customer request is kinda straightforward, the current process is confusing. Making it simpler is desired. (In reply to Heiko Tietze from comment #4) > The command is disabled while editing a comment. Meaning it becomes > available once you finished to add a new comment. Being disabled while editing a new comment is not a problem, but after editing it changes status if it was "Enabled" (but not if it was disabled). Further, editing an existing comment does not turn it off - which makes sense in itself, but inconsistent with editing a new comment. This is not good. > > What remains is the fact that View > Comments is not a toggle. I can follow > Ady's comment 3 in this regard. You too, Gabor? That is exactly the problem. This current behavior (it's BOTH a status indicator AND an action button) makes less sense than making it a toggle. In Calc, new comments are hidden after creation and initial editing by default. This contrasts the behavior of Excel: there the new comments are hidden or shown depending on the status of the Show All Comments button, which also changes the status of existing comments. Our customer was inspired by that. Other use cases, such as the one mentioned by ady, are worth investigating in detail: > For instance, you can have many comments set to Show already, and you might > want to > add several new comments but you want them to remain hidden. Unhiding all the > new > comments is easy with the current workflow, but having to hide each new > comment is > an extra unneeded work, even when selecting multiple cells. - Having a file with all existing comments hidden. Currently: New comments are added as hidden. Unhiding the new ones is a per-comment click, but hidden ones are kept hidden. After: (a) If View - Comments becomes a toggle which is turned off by default, the behavior is the SAME. (b) If it is turned on by default, new comments are added as visible and hidden ones are kept hidden. This would match Excel behavior. This is LESS clicks than before. (c) If the status is changed, all comments become visible / hidden. This is the SAME as before, plus new comments are created according to the new visible / hidden state. - Having a file with all existing comments visible. Let's say we want to add some hidden ones. Currently: New comments are added as hidden. No clicks needed. After: (a) If View - Comments becomes a toggle which is turned off by default, new comments are created as hidden. This is the SAME as before. (b) If it is turned on by default, new comments are added as visible. Hiding them is a per-comment click. (c) If the status is changed all comments become visible / hidden. This is the SAME as before, plus new comments are created according to the new visible / hidden state. Overall, it does not seem like there would be a huge downside. I think it would be more consistent and less confusing on the "is this a status indicator or a toggle command? -> Both" front. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 106249] Expose OLE draw:frame draw:text-box to selectively control overwriting of OLE objects, e.g. an OLE Formula in Impress opened with F2
https://bugs.documentfoundation.org/show_bug.cgi?id=106249 V Stuart Foote changed: What|Removed |Added Status|NEW |UNCONFIRMED Keywords||needsUXEval Ever confirmed|1 |0 CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #8 from V Stuart Foote --- Agree to enhancement as per comment 1, *not* to a refactoring of behavior vis-a-vis OLE objects in Impress, or changes to the Calc behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162878] Reworked localized Impress templates look ugly in RU
https://bugs.documentfoundation.org/show_bug.cgi?id=162878 --- Comment #25 from Commit Notification --- Laurent Balland committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5b907b2ccaa62a62ec343f62acea4a5e76bee164 tdf#162878 GrowingLiberty template: autosize for title It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162709] PIVOTTABLE UI: improve field value list accessibility
https://bugs.documentfoundation.org/show_bug.cgi?id=162709 Heiko Tietze changed: What|Removed |Added Resolution|--- |INSUFFICIENTDATA Status|NEEDINFO|RESOLVED --- Comment #3 from Heiko Tietze --- Resolving the ticket for now. Feel free to reopen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153188] suggestion: AutoSave on lose focus; see additional more sophisticated suggestion in comments
https://bugs.documentfoundation.org/show_bug.cgi?id=153188 Heiko Tietze changed: What|Removed |Added Resolution|--- |INSUFFICIENTDATA Status|NEEDINFO|RESOLVED --- Comment #8 from Heiko Tietze --- Resolving the ticket for now. Feel free to reopen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162005] in windows list (in panel) (LINUX) different icon for .ODT and .ODM document windows
https://bugs.documentfoundation.org/show_bug.cgi?id=162005 Heiko Tietze changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |NOTOURBUG --- Comment #3 from Heiko Tietze --- Resolving the ticket for now. Feel free to reopen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162354] Request Formatting cells in calc ( transfering / coppying formats ) from one to another
https://bugs.documentfoundation.org/show_bug.cgi?id=162354 Heiko Tietze changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEEDINFO|RESOLVED --- Comment #11 from Heiko Tietze --- Resolving the ticket for now. Feel free to reopen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 113247] UI Field "Copy sort results to" in dialog Sort, tab options, missing button/does not allow shrinking
https://bugs.documentfoundation.org/show_bug.cgi?id=113247 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #7 from Heiko Tietze --- We discussed the topic in the design meeting. Whether you enter a range or a cell address, the target is always filled with the source. The function will not limit the results like SORT(A1:A5) and cut-off at two items. Changing this behavior might be convenient in a few scenarios but would be unexpected and error-prone in most other. As for the UI we may change the dialog and add a reference (aka "shrink") button to the field that would accept only single cells. Labels should help to make the UI clear. Could be: "Start cell: [ ] from: " If this sequence takes too much space, we could go with just "At" or use labels more sparingly or place controls in two lines. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163036] Can't delete a chart right after insertion
https://bugs.documentfoundation.org/show_bug.cgi?id=163036 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #4 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #3) > So what if it's "edit mode". You split hairs. The question is not whether _you_ understand the difference between select and edit but average users. And in all the years I've not seen such question. On the other hand you request a fundamental change. Clearly NAB/WF. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 62954] UI : allow Alt + left / right to change width of panes as Navigator and Styles and formatting
https://bugs.documentfoundation.org/show_bug.cgi?id=62954 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |accessibility CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||m.wegh...@posteo.de Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #10 from Heiko Tietze --- We discussed the topic in the design meeting. The only place where a splitter is changed per keyboard is Calc for the Split Window with shift+ctrl+f6. Alt+left/right (and top/down) changes the cell width/height (if the focus is not at the sidebar). Me struggles to understand why users need to adjust the UI per keyboard (if the sidebar width is inappropriate we need to improve the implementation). Default shortcuts, in particular when hard-coded, should be implemented only if absolutely necessary. => WF Although the request has no obvious use case it makes sense to add accessibility to the discussion. As a more general remark: key sequence interaction a la emacs/vim etc. would be nice, maybe realized per extension. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 162872] Add "Source Sans Pro" to VCL.xcu fallback font list for "Aptos"
https://bugs.documentfoundation.org/show_bug.cgi?id=162872 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #10 from Heiko Tietze --- We discussed the topic in the design meeting. As long we do not have a good alternative it makes sense to use SSP as fallback. Assuming Aptos becomes more and more popular it might require bundling SSP again. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153991] Sidebar panel character deck/tab doesn't allow switching language groups
https://bugs.documentfoundation.org/show_bug.cgi?id=153991 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mikekagan...@hotmail.com Component|LibreOffice |UI Keywords|needsUXEval | Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #6 from Heiko Tietze --- We discussed the topic in the design meeting. While the indication was accepted and in principle this request too, it is unclear what switching the language group mean. Suppose a text belongs to Western that uses Liberation as font, what happens when you switch to CTL? Adopt the setting from the respective field and change the font to Alef and the language to Arabic, for example? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153992] Sidebar character deck doesn't indicate the current language/language group
https://bugs.documentfoundation.org/show_bug.cgi?id=153992 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Ever confirmed|0 |1 Component|LibreOffice |UI Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Severity|normal |enhancement --- Comment #3 from Heiko Tietze --- We discussed the topic in the design meeting and the proposal was accepted. Some comments: + most controls are in the toolbar as well, we probably need to implement it as a customizable UNO command + the control should be visible only if CTL/CJK are checked + it could be realized per dropdown before the font listbox although that takes some precious space -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163036] Can't delete a chart right after insertion
https://bugs.documentfoundation.org/show_bug.cgi?id=163036 --- Comment #3 from Eyal Rozenberg --- Created attachment 196547 --> https://bugs.documentfoundation.org/attachment.cgi?id=196547&action=edit Calc sheet after chart creation The chart looks selected. Only a power user who things in terms of OLE object and is used to how charts behave would think that there's a reason why deletion should not work. And frankly - why shouldn't it? So what if it's "edit mode". When everything is selected, even in "edit mode", and I press delete - I expect the chart to be deleted. Developer should make it happen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 163036] Can't delete a chart right after insertion
https://bugs.documentfoundation.org/show_bug.cgi?id=163036 --- Comment #2 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #1) > After creating a chart you are in edit mode with focus on the chart area. The simple, non-power user, would tell you: "I don't know and don't care about modes, that is not my problem. I created a chart, and it is selected: I see a selection rectangle with handles and everything, just like I get when I insert a drawing object, or image from a file or whatever. So, when I press Delete, it should be deleted." > You cannot delete this at any time. => NAB But that's the bug. Either the chart can be deleted right after insertion, or there is a compelling reason + clear and unambiguous visual indication that it cannot. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 153991] Sidebar panel character deck/tab doesn't allow switching language groups
https://bugs.documentfoundation.org/show_bug.cgi?id=153991 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #5 from V Stuart Foote --- The SB Properties deck holds a Character content panel. The SB Properties deck is an Omni panel assembling details across the document and UI defaults. But agree there is utility to expose current language/locale on the SB Properties deck. Would be for focused paragraph, or respond to a selection (will likely be needed for bug 148257). Currently, the Properties deck will respond to text spans receiving CJK/CTL Paragraph style handling by ICU lib detection. Where user configures their defaults (or current document) choices from Tools -> Options -> Language & Locale -> General. So any text spans in the document will pick up just those single Western/CJK/CTL font assignments in the Paragraph styles in the Styles deck and are also exposed on the Properties deck--when no Direct Formatting overrides. Alternatively explicit DF setting of language at the Paragraph object level reflects associated font in the Properties deck--but no language tagging beyond what is below on the Status bar. At a minimum, until bug 148257 allows more, exposing the same "trifecta" PS details used for the Status bar in the Properties deck seems reasonable start. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 62954] UI : allow Alt + left / right to change width of panes as Navigator and Styles and formatting
https://bugs.documentfoundation.org/show_bug.cgi?id=62954 --- Comment #9 from Heiko Tietze --- These alt+arrow shortcuts are clumsy and hard-coded. I prefer a clean implementation where users can un/assign shortcuts. My -1 was also inspired by bug 146906 / https://gerrit.libreoffice.org/c/core/+/173122 (pending acceptance from dev/a11y ML). -- You are receiving this mail because: You are on the CC list for the bug.
