[Libreoffice-ux-advise] [Bug 158034] Feature request: Editing, Formatting, UI. Option to add linebreaks when merging cells into one.
https://bugs.documentfoundation.org/show_bug.cgi?id=158034 --- Comment #3 from m.a.riosv --- My guess, merging vertically a line break, horizontally a tab. But I tested that tabs are not displayed in cells. ="hola"(9)&"adios" -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157991] Print scaling not applied when using single column, column wider than page width, with text-wrapping
https://bugs.documentfoundation.org/show_bug.cgi?id=157991 --- Comment #7 from crx...@hotmail.com --- (In reply to Heiko Tietze from comment #6) > (In reply to crxssi from comment #5) > > (In reply to m.a.riosv from comment #4) > > > Seems as the cell size is larger than the page width, it is treated as > > > such. > > > > I am not sure what you mean. The whole point of "Fit page" is to force it > > to automatically fit on the page(s) as specified. > > Doesn't it work as best as possible? Is the expectation to decrease the font > size until the column fits on the page (and to raise it respectively on > narrow content)? Yes, that is exactly what I would expect and how it should work. If there are two or more columns, that is exactly what it does- it lowers the font size until it fits on the page horizontally and/or vertically (depending on which option you choose). Why would it not work that way when there is one column? Why should that be handled differently? If you ask Calc to fit to page and it doesn't, it isn't "fit to page". It is "fit to page as long as you have more than one column or your single column is manually set to some unknown-to-the-user width that doesn't exceed the page width" :) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157972] Don't shorten "Relative size" to "Rel. Size" in Bullets & Numbering dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=157972 Buovjaga 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.
[Libreoffice-ux-advise] [Bug 157991] Print scaling not applied when using single column, column wider than page width, with text-wrapping
https://bugs.documentfoundation.org/show_bug.cgi?id=157991 Heiko Tietze changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #6 from Heiko Tietze --- (In reply to crxssi from comment #5) > (In reply to m.a.riosv from comment #4) > > Seems as the cell size is larger than the page width, it is treated as such. > > I am not sure what you mean. The whole point of "Fit page" is to force it > to automatically fit on the page(s) as specified. Doesn't it work as best as possible? Is the expectation to decrease the font size until the column fits on the page (and to raise it respectively on narrow content)? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150036] [Feature Request] Line connecting legend and chart (improving chart readability)
https://bugs.documentfoundation.org/show_bug.cgi?id=150036 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150036] [Feature Request] Line connecting legend and chart (improving chart readability)
https://bugs.documentfoundation.org/show_bug.cgi?id=150036 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158017] Impress Freshes Template using wrong font color in some slides
https://bugs.documentfoundation.org/show_bug.cgi?id=158017 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org Status|UNCONFIRMED |NEEDINFO --- Comment #7 from Heiko Tietze --- Is the font color in these boxes Automatic (which should be effectively white then) or black (which would be wrong)? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158034] Feature request: Editing, Formatting, UI. Option to add linebreaks when merging cells into one.
https://bugs.documentfoundation.org/show_bug.cgi?id=158034 Heiko Tietze changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #2 from Heiko Tietze --- What exactly is a line break? Two characters CR/LF, I guess. And for horizontally merged cells you probably go with a tab character. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155519] Shape's Text Box Should Be resizeable with handles
https://bugs.documentfoundation.org/show_bug.cgi?id=155519 --- Comment #9 from Regina Henschel --- (In reply to Heiko Tietze from comment #8) > (In reply to Regina Henschel from comment #7) > > Text on connectors is different from text on flowchart shapes. > So you argue to resolve as wontfix (and to improve the connector stuff > elsewhere)? I think, it is a valid enhancement request, to be able to change the values of "Line Spacing" be dragging something. This could be added in the UI of any shape which has "Text attributes" and might be also useful for the "Padding" in frames. Only moving or resizing the text area as whole should not be done. Therefore I would be more precise in the subject line, that this is about the "Line Spacing". I want to warn, that such new feature will not solve special problems with texts on connector shapes. But we need no new bug report for these; bug 123934 and bug 75301 cover already problems with text for connector shapes. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157882] The arrowhead control in the sidebar line section is difficult to notice
https://bugs.documentfoundation.org/show_bug.cgi?id=157882 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mentoring@documentfoundatio ||n.org Status|UNCONFIRMED |NEW Keywords|needsUXEval |difficultyBeginner, ||easyHack, skillCpp, topicUI Ever confirmed|0 |1 --- Comment #5 from Heiko Tietze --- We discussed the topic in the design meeting. First step could be to remove the cap/corner style controls and move the arrow head into an extra line with a label. In a follow-up patch we should split the arrow head control into beginning/end controls. Code pointer: svx/uiconfig/ui/sidebarline.ui (remove cornerlabel, edgestyle, caplabel, linecapstyle, add a label for arrow head and move the control there) svx/source/sidebar/line/LinePropertyPanelBase.cxx (remove all mxFTEdgeStyle, mxLBEdgeStyle, and ChangeEdgeStyleHdl and the same for the cap style; don't forget the header file) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 150414] Cell / font formatting lost when data linked from external data
https://bugs.documentfoundation.org/show_bug.cgi?id=150414 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists | |.freedesktop.org| --- Comment #15 from Heiko Tietze --- We discussed the topic in the design meeting. The topic is very difficult to understand and probably needs more investigation. More general ideas: external sources are values and should not affect the internal formatting. On the other hand, if the source has formatting it should be used, ideally optionally. The question remains what "no formatting" means both internally and externally, in other words we don't know if a plain cell has explicitly no format and must or must not be overwritten. Ultimately it sounds correct to follow Stephane's suggestion in comment 10 and harmonize the functions. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157331] in automatic filter, add the number of the first row where the value appears
https://bugs.documentfoundation.org/show_bug.cgi?id=157331 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #9 from Heiko Tietze --- We discussed the topic in the design meeting and suggest to ask in a forum/ask-libreoffice for better solutions - and request an enhancement if none is found. While the computational effort sounds to be low, and real estate on dialog seems to be possible though somewhat cluttered we should not implement such enhancement if not more users are interested. Please reopen in this case. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152800] Changes to border format in cell style should persists even if no border is set, so it can be used as a default for new borders (comment 2)
https://bugs.documentfoundation.org/show_bug.cgi?id=152800 Heiko Tietze changed: What|Removed |Added Keywords||needsUXEval Status|NEW |NEEDINFO --- Comment #3 from Heiko Tietze --- The template aspect has been discussed in bug 143249, and to "Remember last used line width (and other settings) for cell borders" in bug 144141. Shall we make this a duplicate? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155519] Shape's Text Box Should Be resizeable with handles
https://bugs.documentfoundation.org/show_bug.cgi?id=155519 --- Comment #8 from Heiko Tietze --- (In reply to Regina Henschel from comment #7) > Text on connectors is different from text on flowchart shapes. So you argue to resolve as wontfix (and to improve the connector stuff elsewhere)? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155519] Shape's Text Box Should Be resizeable with handles
https://bugs.documentfoundation.org/show_bug.cgi?id=155519 --- Comment #7 from Regina Henschel --- Text on connectors is different from text on flowchart shapes. The text area of the connector is always the bounding box of the connector. Move the connected shape around to see the problems. Text for connectors would need a feature, that you can bind a text box to the start or end of the connector. Text on connectors is not exported to pptx, because pptx does not know text on connectors. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 --- Comment #12 from Heiko Tietze --- (In reply to Jeff Fortin Tam from comment #11) > I don't understand how you can essentially conclude that my proposal is > taking anything essential away from anyone... You proposed to change the overflow procedure and to first hide the styles preview. Actually, translating into algorithm, to start with the largest section. (In reply to V Stuart Foote from comment #3) > The NB has a simple priority test based on available LO frame width... We do have a priority for the sections, but the styles preview was always attributed to be important. In the end it boils down to whether the interaction with styles or quickly inserting tables is more important (we provide alternative access for both functions). If your screen is very small, you can customize and disable the styles preview. And of course, if you disagree with the decision, feel free to reopen. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155519] Shape's Text Box Should Be resizeable with handles
https://bugs.documentfoundation.org/show_bug.cgi?id=155519 --- Comment #6 from Heiko Tietze --- (In reply to Regina Henschel from comment #3) > ODF allows to move or resize the text-areas rectangle, but we would leave > the preset geometry of the shapes then. Using the preset geometry is > essential for a good round-trip with ppt and pptx formats. (In reply to ddmi...@gmail.com from comment #4) > ...text box on a connector between two vertically arranged flow chart > elements. > ...the resulting text box appears centered over the connector. I can follow the use case. It could solve or rather be a workaround for bug 45028 and bug 75301 (text becomes strike-trough and placing the label at connector points). Would the position be fix once the text box has moved out of the object, meaning resizing and moving the parent has no effect on the label, or is it kind of an offset and the label moves with the parent? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157945] UI: Resizing of a selection of columns/rows should correspond to the mouse position
https://bugs.documentfoundation.org/show_bug.cgi?id=157945 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #3 from Heiko Tietze --- It's a convenience feature that resizing one column is applied to all selected (any, not just the right-most). Assuming we implement the suggested variant, eg. enabled per modifier key, how would the procedure deal with some other column/row than the last? For example, you select A:E and resize on C. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146417] Create a suggestion for document link if same word linked
https://bugs.documentfoundation.org/show_bug.cgi?id=146417 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #2 from Heiko Tietze --- Alex, is the workaround acceptable for you? If not, please elaborate a bit why you need hyperlinks from one specific word at many occasions to one specific chapter. Reminds me on a table of contents, which would have a "Apply to all occurrences", or the alphabetical index generated from a concordance file. -- You are receiving this mail because: You are on the CC list for the bug.
