[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #8 from QA Administrators --- [Automated Action] NeedInfo-To-Unconfirmed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 QA Administrators changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161255] Heuristically enable RTL-CTL and/or CJK language support when installing
https://bugs.documentfoundation.org/show_bug.cgi?id=161255 Eyal Rozenberg 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 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #7 from David --- I will try to explain the use case we foresee for the proposed functionality. We are a medium size structural engineering office, many time we have to prepare complex structural reports based on results exported out of FE software in form of spreadsheets. For the automation of the creation of documents, we have spreadsheets we use as templates with the verification formulas of regulations like for example Eurocodes. Now we have one cell for the main check with an outcome like "Ok" "NOK" and conditional format, followed with an explanation and documental references on next an previous cells, text format is terrible for a formal pdf exportation. Think of a text similar to: "as expresed on clause EN 1993 4.2.1 for class 1 cross-section, buckling check fails due to excesive slenderness see equation 4.2.1b" This would be a very basic example that would be expressed into something like: =if(CrossSectionClass=1,"as expresed on clause 4.2.1 EN 1990 for class 1 cross-section, buckling check "(checkingHere,"is ok","fails due to "&" see equation 4.2.1b")) This is the basic functionality. Medium functionality, if we want to go for the full package, would be a bit more complex font formating like: λ so we could write formulas on the conditions with mathematical required characters. And the "let's-make-a-magical-wish" functionality would include
[Bug 160983] RecalcOptimalRowHeightMode should be effective for CSV imports also
https://bugs.documentfoundation.org/show_bug.cgi?id=160983 --- Comment #15 from Justin L --- (In reply to ady from comment #12) > Some users won't like the first alternative, whereas others won't like the > second possibility (and both groups will complain). I am not sure that > simply changing the behavior would be considered as an improvement. OP is not asking for a change in the default behaviour. RecalcOptimalRowHeightMode is an advanced configuration option that affects whether rows that do not mandate a specific height should have that height calculated at import time. -yes (default - no change in behaviour) -no (useful for ODS which I believe knows the last-used-height at import) -ask P.S. I just checked ScDocShell::ConvertTo SC_TEXT_CSV_FILTER_NAME and it does NOT set bSetRowHeights to true. So doing what OP asks would not be as trivial as I thought it might be. Still a WONTFIX from me. Only useful for formats that already know an appropriate height. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161234] Issues with the new cell outline in Calc 24.8
https://bugs.documentfoundation.org/show_bug.cgi?id=161234 --- Comment #11 from ady --- (In reply to Heiko Tietze from comment #10) > 1px is 10% of the total cell height at 25% but 0.01 at 600%. To make the > frame clearly outstanding from the cell content you need to adjust the > distance according the zoom factor. Of course we can abstain from this look > and feel and just make it start outside the cell with zero distance. Let me put an example of the difference that I am trying to convey. If a user sets borders to a cell, those borders are chosen by the user and I see this as part of a main layer, not an auxiliary layer. Cell borders might be considered of lesser importance than cell contents, or formulas, but they are still part of user's choice, and they have a specified width (among other properties). OTOH, cell's limits are surrounded by gridlines, which are usually displayed – gridlines could be hidden by user's choice, but that's not the point here. The gridlines are an auxiliary artifact (therefore, they are never on top of cell borders added by the user), and users don't need to see their width in a proportional ratio in relation to the cell's size (width/height). As long as the gridlines mark the cell's limits without interfering with real work, they fulfill their role. Making the gridlines grow in the same proportion as the cells when zooming-in would be counterproductive. I see the active-cell surrounding line in a similar way as gridlines. As long as the active-cell line is clearly seen, without blocking other more-relevant items (cell content, cell border, comment indicator...), it does not need to have more/less (now outer) distance in relation to the cell's limit, whichever the zoom factor. The outer distance could be maintained. When zooming-in, I don't need to see the active-cell line more clearly than with another zoom, as I am focusing on some main item, not on auxiliary ones. This is just the way I see this matter, as a user. Experts could of course have a deeper and broader understanding of these things. BTW, zoom factors in Calc go as far as 400%, not more than that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160983] RecalcOptimalRowHeightMode should be effective for CSV imports also
https://bugs.documentfoundation.org/show_bug.cgi?id=160983 --- Comment #14 from Justin L --- You definitely want to have row height automatically calculated for a CSV import, since CSV cannot possibly specify a height for any row. Otherwise any multiline data (like row 54) would be "hidden" - looking like single line data (like row 53). CSV is always a transitional format. You load it once, then format it according to your liking and then export it into an appropriate format. Other than avoiding a performance penalty, I can't imagine any reason not to want to have the row height be calculated at load time. The proper response to being irritated about the speed is to optimize row height calculation. [That said, I did say in my XLSX commit "I can't think of a reason why this shouldn't apply to all formats". As a code pointer, see https://gerrit.libreoffice.org/c/core/+/164721 ] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #6 from Heiko Tietze --- David, please clarify your goal. Style text via function or have (limited) markup capabilities as done per autocorrection. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161234] Issues with the new cell outline in Calc 24.8
https://bugs.documentfoundation.org/show_bug.cgi?id=161234 --- Comment #10 from Heiko Tietze --- (In reply to ady from comment #7) > (In reply to Heiko Tietze from comment #6) > > I don't see an absolute value as a solution > If I may ask, why? 1px is 10% of the total cell height at 25% but 0.01 at 600%. To make the frame clearly outstanding from the cell content you need to adjust the distance according the zoom factor. Of course we can abstain from this look and feel and just make it start outside the cell with zero distance. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161234] Issues with the new cell outline in Calc 24.8
https://bugs.documentfoundation.org/show_bug.cgi?id=161234 --- Comment #9 from Rafael Lima --- (In reply to Heiko Tietze from comment #6) > I don't see an absolute value as a solution; a slightly smaller > multiplicator might be okay. Feel free to hack it. Thanks for the pointer... I'll try to come up with an alternative design and CC you on the patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160866] [feature reques] Is there any way of finding out the font version in LibreOffice?
https://bugs.documentfoundation.org/show_bug.cgi?id=160866 Dieter 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 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 Regina Henschel changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Regina Henschel --- (In reply to Heiko Tietze from comment #4) > (In reply to David from comment #2) > > I would stick to the basic format tags, like bold, italic, underline, > > etc,... > Enable Tools > AutoCorrect Options... > Options > Automatic *bold*, > /italic/... to get this simple markup. That solution does only work for text directly entered into the cell. When entering text directly into the cell, then all ways of direct character formatting is available. Request for character styles is in bug 108220. The problem is, that it is not possible to style a part of text result of a function. You can only style the entire result string using the STYLE() function or using conditional formatting. I can imagine a special text function that allows to style part of a text result. It need not be that it detects HTML markup, markdown would be possible as well. I personally would prefer not to use markup detection, but would prefer to first solve bug 108220 and then add a text function that applies a named character style to a portion of text. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160983] RecalcOptimalRowHeightMode should be effective for CSV imports also
https://bugs.documentfoundation.org/show_bug.cgi?id=160983 --- Comment #13 from ady --- (In reply to Heiko Tietze from comment #11) > Me don't, although it takes some milliseconds to process. Same here, but maybe the attachment is just a simplified case(?). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160983] RecalcOptimalRowHeightMode should be effective for CSV imports also
https://bugs.documentfoundation.org/show_bug.cgi?id=160983 --- Comment #12 from ady --- (In reply to Stéphane Guillou (stragu) from comment #10) (e.g. at row 54) Cell B54 includes line-breaking characters. They should not be modified by the import process. Either, Rows nor Columns get any modification (they would not adapt at all, leaving both axis with default values only, no matter the contents), or they get some kind of adapting to contents. Some users won't like the first alternative, whereas others won't like the second possibility (and both groups will complain). I am not sure that simply changing the behavior would be considered as an improvement. I would agree to let users modify the respective sizes manually after importing, but other users won’t like that, especially newbies. Providing choice (about one behavior or the other) for users might be seen as improvement, but that means adding some checkbox somewhere. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161251] Support showing combinations of (named) style + direct formatting in Stylist
https://bugs.documentfoundation.org/show_bug.cgi?id=161251 Eyal Rozenberg changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=89 | |974 | Depends on||89974 --- Comment #5 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #4) > So you want to show for example > > Default Style > > Text Body (designed as right aligned and English) > > Left* > > Hebrew* > > Justified* > > Hebrew* > > Hebrew* > > Bold* > > Left* > > Left* > > Bold* Not really. I don't want a multi-level hierarchy. Either 0-level or 1-level; and the item text is the full text I would see in the organizer tab of the Style dialog, e.g. "Blockquote + RGB(255,128,0) + Superscript automatic + Borders top (Black, Single, dash-dot-dot), Spacing 0.05 cm" Naturally, this will exceed the length we have available in the sidebar. But - that's fine, because: 1. Tooltip. 2. The user will be able to see which content they selected, so they can double-check it's the right item in the Stylist. > Strong -1 for diluting the strength of the Stylist with arbitrary attributes. You're not diluting it at all. This would be an _optional_ toggle, defaulting to off. So, unless you want to see this stuff, you'll see the same thing as you do today. > The Stylist is not meant for copy/paste, use the F dialog. The stylist is meant for locating and selecting content. But since this seems to bother you, let me mark a dependency on bug 89974. And the F dialog is irrelevant, nobody would use that to select anything. > > 4. Browse the document and have the content with that style highlighted. > We have the Styles Highlighting, also in combination with DF. Yes, but - the highlighting will not distinguish between the DF you want and other DF over that style. Plus, it only shows you indications at the side of the page, while you want to see selected text (for CS). > Why would you want to use a perfect control to list and manage styles to > change DF? 1. We can clear DF from that content 2. We can apply another style to that content. 3. If DF is allowed by manually selecting multiple pieces of text, it should be catered for also when the selection is automated. > > 6. I want to create a new named style based on that named-style-plus-DF > > combination, and apply it to all of that content, in a single action. > New > From Selection allows to create a new style with the current > formatting. But I don't have the selection, Heiko... I need this feature in order to make the selection and apply the new style to everything. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=89974 [Bug 89974] Context menu entry (in Styles and Formatting) to select all elements with the same style -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161234] Issues with the new cell outline in Calc 24.8
https://bugs.documentfoundation.org/show_bug.cgi?id=161234 --- Comment #8 from ady --- (In reply to Stéphane Guillou (stragu) from comment #5) > I was referring to the square not following the rectangle and eventually > getting disconnected at higher zoom levels. So it is also about the distance for you. Maybe there should be a distance between the cell's limit and the (now outer) active-cell line marker, but a different (smaller) distance between the latter and the fill handle (?). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161234] Issues with the new cell outline in Calc 24.8
https://bugs.documentfoundation.org/show_bug.cgi?id=161234 --- Comment #7 from ady --- (In reply to Heiko Tietze from comment #6) > I don't see an absolute value as a solution Please forgive my ignorance. If I may ask, why? What's the reasoning? I think of the active-cell line marker in a similar way as other auxiliary UI elements: * auxiliary lines such as active-cell border line mark, selected-cells background color, trace-dependent and trace-precedent lines and arrows, the fill handle, comment indicator... are all examples of a secondary auxiliary layer; * cell contents, cell results, graphs, and even cell borders applied by the user, are part of one main layer. So, again, please forgive my ignorance... I don't see the reason to make the auxiliary artifacts directly proportional to the zoom factor exactly the same as cells, graphs and other main items. I can understand the possible need to tweak the auxiliary layer when it is not displayed adequately under some conditions (color contrast, screen resolution, zoom factor, dark theme...), but growing/shrinking these auxiliary items proportionally to zoom factor would seem to me (and to my workflow) a negative point. OTOH, I'm just a common user that might not understand enough about UX. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 Heiko Tietze changed: What|Removed |Added Blocks||108253 Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Heiko Tietze --- (In reply to David from comment #2) > I would stick to the basic format tags, like bold, italic, underline, > etc,... Enable Tools > AutoCorrect Options... > Options > Automatic *bold*, /italic/... to get this simple markup. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108253 [Bug 108253] [META] Calc cell formula bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161251] Support showing combinations of (named) style + direct formatting in Stylist
https://bugs.documentfoundation.org/show_bug.cgi?id=161251 --- Comment #4 from Heiko Tietze --- So you want to show for example Default Style > Text Body (designed as right aligned and English) > Left* > Hebrew* > Justified* > Hebrew* > Hebrew* > Bold* > Left* > Left* > Bold* Strong -1 for diluting the strength of the Stylist with arbitrary attributes. (In reply to Eyal Rozenberg from comment #0) > 1. Copy or cut all of that content, at once, and paste it elsewhere. The Stylist is not meant for copy/paste, use the F dialog. > 4. Browse the document and have the content with that style highlighted. We have the Styles Highlighting, also in combination with DF. > 5. I want to change the direct formatting of this content. Why would you want to use a perfect control to list and manage styles to change DF? > 6. I want to create a new named style based on that named-style-plus-DF > combination, and apply it to all of that content, in a single action. New > From Selection allows to create a new style with the current formatting. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161234] Issues with the new cell outline in Calc 24.8
https://bugs.documentfoundation.org/show_bug.cgi?id=161234 Heiko Tietze changed: What|Removed |Added Version|24.8.0.0 alpha0+|3.3.0 release --- Comment #6 from Heiko Tietze --- I don't see an absolute value as a solution; a slightly smaller multiplicator might be okay. Feel free to hack it. ScGridWindow::UpdateCursorOverlay() in sc/source/ui/view/gridwin.cxx, see https://gerrit.libreoffice.org/c/core/+/166870. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161251] Support showing combinations of (named) style + direct formatting in Stylist
https://bugs.documentfoundation.org/show_bug.cgi?id=161251 Eyal Rozenberg changed: What|Removed |Added Summary|Support showing |Support showing |combinations of named style |combinations of (named) |+ direct formatting in |style + direct formatting |style list |in Stylist -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161251] Support showing combinations of named style + direct formatting in style list
https://bugs.documentfoundation.org/show_bug.cgi?id=161251 --- Comment #3 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #2) > I cannot follow. What is a "named style" and how does DF come into play? A style which has a name (as opposed to anonymous "autostyles"). This bug is about all kinds of entities which admit direct formatting and (named) styles: Paragraph, Character, List, Cell, Drawing Object etc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160983] RecalcOptimalRowHeightMode should be effective for CSV imports also
https://bugs.documentfoundation.org/show_bug.cgi?id=160983 --- Comment #11 from Heiko Tietze --- (In reply to Stéphane Guillou (stragu) from comment #10) > I see the "calculating" message and the high-height cells (e.g. at row 54) > when importing the sample file with only comma as a delimiter. Me don't, although it takes some milliseconds to process. Line 1197 aka log data point #2097 is more extreme, and I struggle with the use case of putting a novel into a single cell. The example encloses a long string with quotation marks and RecalcOptimalRowHeightMode does its job as expected. > I can see how it can be frustrating for users wanting to edit simple formats > like CSV/TSV, expecting LO to handle it as simply as possible. Sure, if CSV is kept simple. But the example is some kind of log file with an (X)ML format. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161251] Support showing combinations of named style + direct formatting in style list
https://bugs.documentfoundation.org/show_bug.cgi?id=161251 --- Comment #2 from Heiko Tietze --- I cannot follow. What is a "named style" and how does DF come into play? If it's about filtering please search the depending tickets for a duplicate. Some wording conventions: Styles Sidebar = Stylist Styles Toolbar = Styles Toolbar :-) Direct Formatting = DF Character Style = CS Paragraph Style = PS Page Style = PgS -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161251] Support showing combinations of named style + direct formatting in style list
https://bugs.documentfoundation.org/show_bug.cgi?id=161251 Eyal Rozenberg changed: What|Removed |Added Blocks||103427 --- Comment #1 from Eyal Rozenberg --- I should mention this is relevant in Impress and Calc as well, if not also elsewhere. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103427 [Bug 103427] [META] Styles and Formatting sidebar deck and floating window -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161251] Support showing combinations of named style + direct formatting in style list
https://bugs.documentfoundation.org/show_bug.cgi?id=161251 Eyal Rozenberg changed: What|Removed |Added Keywords||needsUXEval Severity|normal |enhancement See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=89 ||974, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||7769 CC||libreoffice-ux-advise@lists ||.freedesktop.org -- You are receiving this mail because: You are on the CC list for the bug.
