Bug 162870 - Character spacing doesn't function with used-defined format code OR formulas
Summary: Character spacing doesn't function with used-defined format code OR formulas
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.2.5.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice, needsUXEval
Depends on:
Blocks:
 
Reported: 2024-09-08 18:25 UTC by eobet
Modified: 2024-09-10 13:32 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot with 10 as character space (54.23 KB, image/png)
2024-09-08 22:43 UTC, m_a_riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description eobet 2024-09-08 18:25:51 UTC
Description:
Character spacing is extremely limited.

It stops working the moment you change the contents of a cell.
It stops working with a user-defined format code.
It stops working with formulas.

Steps to Reproduce:
1. Change cell format to \00
2. Enter a single digit
3. Select that character and change character spacing to 10.

1. Enter a formula in a cell
2. Select the characters and change character spacing to 10.

Actual Results:
Character spacing has no effect.

Expected Results:
Character spacing should have an effect regardless of what they are, and even if they change!


Reproducible: Always


User Profile Reset: No

Additional Info:
The entire "Character" menu seems extremely limited in functionality and prone to just disappear, so perhaps it should be moved somewhere more stable, like cell format or text format.
Comment 1 m_a_riosv 2024-09-08 22:43:23 UTC
Created attachment 196320 [details]
Screenshot with 10 as character space

Version: 24.2.6.2 (X86_64) / LibreOffice Community
Build ID: ef66aa7e36a1bb8e65bfbc63aba53045a14d0871
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL threaded
Comment 2 ady 2024-09-09 03:24:02 UTC
IIUC, the report is that in Calc, when entering into cell's edit mode, then "Format Character" applies to strings of text but not to numbers nor to formulas.

Moreover, if you try to apply Format Character properties to a numeric value in the formula bar input window box, then the numeric value will be converted to a text value.

I'm not sure that the Format Character properties could potentially be applied to numeric values in Calc at all, much less to formulas.

Is that even supported by the ODF standard at all? Can this kind of Character formatting be achieved in any spreadsheet tool, with whichever file format?

I believe – but I could be wrong – that having a cell containing numeric values implies treating the cell as a whole unit, which means that you cannot apply properties to _parts_ within the cell (even when those are _all_ the parts of the content of a cell). That would also be relevant for calculated cells (i.e. cells containing formulas, even when the result of the formula is a text/string).

I would suggest searching for a Font type that is naturally less "condensed" or less "narrow" as an alternative (that would also be supported in other spreadsheet tools).
Comment 3 V Stuart Foote 2024-09-09 12:07:32 UTC
IMHO => WF no real advantage to expanding formatting beyond cell text (text strings and numeric).
Comment 4 Heiko Tietze 2024-09-09 14:00:27 UTC
AFAIK, the cells in edit mode are handled by the edit engine, which is completely different to Calc. So we have a couple of options on the cell style but not the position. The only way to reach this tab is via the context menu in edit mode. And to make it even more weird, there is no context mode for text like ="123". And it is also not possible, resp. has no effect, to copy the formatting. 

Essentially I argue to hide the position tab in case the character dialog is called from Calc. Would also solve bug 147015.
Comment 5 ady 2024-09-09 21:35:42 UTC
(In reply to Heiko Tietze from comment #4)

> Essentially I argue to hide the position tab in case the character dialog is
> called from Calc.

I don't understand the desire to block _every_ possibility just because it is not allowed for some cases.

Format Character is allowed for text values, or for numeric values (that will be automatically treated as text when the Character formatting is applied).

Please stop breaking backwards compatibility. If formulas and numbers are not allowed, then set this as WF. Allow all that is possible, instead of blocking everything and everyone just because some cases are not possible.
Comment 6 Eike Rathke 2024-09-10 10:00:52 UTC
Inline text formatting applies to _cell content_, not display strings produced for number formatting or formula results. Changing cell content by over-typing (not editing) discards the individual inline character formatting applied to the previous content.

Hiding the position tab makes no sense. It is functional for text content.
Comment 7 Heiko Tietze 2024-09-10 12:39:14 UTC
(In reply to Eike Rathke from comment #6)
> Hiding the position tab makes no sense. It is functional for text content.
Got fooled since ="123" has no context menu (like any formula). Without the equal sign I can easily adjust the spacing.
Comment 8 ady 2024-09-10 13:32:15 UTC
(In reply to Heiko Tietze from comment #7)
> Got fooled since ="123" has no context menu (like any formula). Without the
> equal sign I can easily adjust the spacing.

Which I mentioned in my comments, more than once.

FWIW, A cell that contains a (fixed, constant) numeric value is not the same as a formula, and a cell showing what seems to be a number can actually be either the result of a formula, or a (fixed, constant) text value (depending on format, or using the initial apostrophe). A cell showing text could be the result of a formula (instead of a fixed, constant text value). A cell could be showing a mix of content (either fixed/constant, or the result of a formula) and code from the Custom Format Code field.