[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #14 from Heiko Tietze --- We discussed the topic in the design meeting. Given the implementation is quite difficult, the workflow likely cumbersome, and the use case somewhat niche, we suggest to realize the task per macro. There are plenty of guides available, for instance https://documentation.libreoffice.org/en/english-documentation/macro/. We also have a supporting group on Telegram or per mailing list. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #13 from Eike Rathke --- No, it could not. For one, expression calculation happens independent of rendering; second, expression calculation _never_ renders anything; third, such function would only get in the way when other implementations were trying to read the document and encountered the unsupported function, effectively invalidating interoperability. An unsupported cell attribute can simply be ignored. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #12 from David --- One approach could be function, kind of htmlrender() -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #11 from Eike Rathke --- This should by no means go into the formula expression engine, a spreadsheet function would be a wrong approach to render things. Instead, a cell attribute could indicate that the cell content or formula result is to be rendered taking HTML (or whatever) elements into account. Bear in mind that would add _yet another_ formatting layer somewhere in between or on top of conditional formatting hard cell attribution cell styles and possibly upcoming table styles that would go between cell styles and hard cell attribution. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #10 from David --- Hi, autocorrection in formulas would be better than nothing of course. I would say none of my coworkers know the autocorrection */- syntax but all of them know html tags. Also this option would not include colors/background, so it would improve conditional format... just a bit. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #9 from Heiko Tietze --- Would it be sufficient to evaluate the autocorrection in formulas? Like =IF(A1=1;"lorem *ipsum* dolor";"lorem ipsum _dolor_"). I'm thinking of these [M]/[T] options in Writer, see https://help.libreoffice.org/24.2/en-US/text/shared/01/06040100.html Besides, you probably know the function HYPERLINK(). And TEXT() has a format option, though only for numbers. -- You are receiving this mail because: You are the assignee 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 the assignee for the bug.
[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 the assignee 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 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 the assignee 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 the assignee 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 the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 QA Administrators changed: What|Removed |Added Ever confirmed|1 |0 Status|NEEDINFO|UNCONFIRMED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #3 from QA Administrators --- [Automated Action] NeedInfo-To-Unconfirmed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #2 from David --- My proposal is that the final render of the cell content could be based on a partial subset of html, focusing on format tags, this way on the final rendering phase if it contains tags they are used for format. It is quite similar to the way Qt widgets work. For a calc cell some examples: - plain text -> no format at all - after formula evaluation the result is plain text -> no format at all - cell text has html tags -> apply them to the final render - after formula evaluation the final text has html tags -> apply them to the final render I would stick to the basic format tags, like bold, italic, underline, etc, it does not make sense to implemente a table into a cell. I think this feature could improve a lot conditional format and become an advantage compared to competitors spreadsheet software. BR -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 V Stuart Foote changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO CC||vsfo...@libreoffice.org Ever confirmed|0 |1 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #1 from Regina Henschel --- The request is not clear to me. Do you want to create the cell text by a formula? If yes, do you request an enhancement to the formula language to include formatting on parts of the text? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 Buovjaga changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval -- You are receiving this mail because: You are the assignee for the bug.
