Steps: 1) Open 'Polished_steel.sur' file in Gwyddion [1] 2) Open 'Calculate roughness parameters' (as in the attached picture) 3) Select the profile line on the surface 4) In 'Roughness' tool, click button: 'Copy results to clipboard' 5) Paste to LO Calc Results: Not able to format number values. Expected: Each pasted value can be formatted. Regression since 25.8.4.2. Observed in: Version: 25.8.5.1 (X86_64) Build ID: cde5f182e321816108385dd3739c4295be919062 CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-US (pl_PL); UI: en-US Calc: CL threaded [1] https://gwyddion.net/download.php
Created attachment 205338 [details] Polished_steel.sur Surface topography of steel polished on a cloth with diamond paste (3D model).
Created attachment 205339 [details] How to gather the data in Gwyddion
Created attachment 205340 [details] Bug reproduction screencast
Please check if there is a difference in the Cell format for Column B on the 25.8.5.1 instance as compared to the 25.8.3.2 sheet instance. What you show in the 25.8.5.1 clip looks to be treating the imported numbers as text (its left aligned) rather than as numbers? And was that into formatting of the existing sheet column/cells as already formatted, or was it an issue with the import (by paste and Text import filter), or a something that has changed at 25.8.5? Does a "Paste Special" as unformatted text behave?
Created attachment 205355 [details] 'Detect scientific notation' does not change format to scientific on import Actually it's not a regression, but lack of functionality. Steps: 1) Copy values in scientific notation (1.23e-4) 2) Paste Special -> Use text import dialog 3) *Do not* select 'Detect scientific notation' Result: Cells where the pasted value is text <number>e<number> or <number>e-<number> will be formatted as text. Then: 4) Paste the same data but *do select* 'Detect scientific notation'. Result: Format of text-fomratted cells is not changed to number or scientific, so we can't format to another types without deleting ' (apostrophe) at start of the cell value. Suggestion: Make 'Text Import' set the format according to import options. Version does not matter. But observed with: Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 8; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-US (pl_PL); UI: en-US Calc: CL threaded
Created attachment 205356 [details] 'Text Import' should set format of cells according to import options
adf --> dfj
Can not confirm. For new pastes into new cells: Without the 'Detect Scientific Notation' the generic 'Detect Special numbers' will retain the SN, but does treat as a number. While using the 'Detect Special Numbers' AND the 'Detect Scientific Notation' the number pasted converts to a decimal number. And *only* if both filters on the text import dialog are unchecked, will the SN be unrecognized as a number--and pasted as Text in the SN format. This seems to function as needed/intended.
testing on Windows with a recent master against 26.8.0, or a 25.8.4.2 release build =-testing-= Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 680(Build:0) CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to Piotr Osada from comment #5) > Result: > Format of text-fomratted cells is not changed to number or scientific, so we > can't format to another types without deleting ' (apostrophe) at start of > the cell value. If the destination cells are already formatted as text, you claim that the Import Text dialog options should have priority over the format the cells already have. But other user might claim exactly the opposite: hey, I have carefully formatted my cells in one way and the Import dialog has changed that, simply because of some minor detail. Although I have not tested the procedure reported in comment 5, I don't really see a problem in practice. You are in control of which cells (or columns) in your spreadsheet will be the destination of the imported data, so you can have the cells formatted as General/Standard and then successfully import your data according to relevant options in the Import Text dialog. Am I missing something?
(In reply to ady from comment #10) > ...other user might claim exactly the opposite: hey, I have > carefully formatted my cells in one way and the Import dialog has changed > that, simply because of some minor detail. I hadn't considered that kind of situation. And I see that it is also an important case. (1) When pasting values in scientific notation (e.g. 2.59595e-09) with 'Detect scientific notation' enabled, the values are correctly recognized as numbers, but the cell format is set to Number instead of Scientific. As a result, small values display as 0.00 — losing all meaningful digits. (2) When pasting into cells already formatted as Text (e.g. from a previous paste without 'Detect scientific notation', where undo is no longer available), the option does not override the existing Text format. The values remain text with a leading apostrophe prefix. Both cases could be addressed within the Text Import dialog itself: (1) 'Detect scientific notation' should apply Scientific format, not Number. Pasting 2.59595e-09 with 'Detect scientific notation' enabled: Current: ║ 0.0000000026 ║ ← Number format, meaningful digits are hidden Expected: ║ 2.59595E-09 ║ ← Scientific format (2) 'Detect scientific notation' should override Text format of destination cells when enabled — since the user has explicitly opted into number detection. Pasting into a cell already formatted as Text: Current: ║ 2.59595e-09 ║ ← still text, apostrophe prefix retained Expected: ║ 2.59595E-09 ║ ← Scientific format, number This would not conflict with the use case you described (preserving carefully formatted cells), because enabling 'Detect scientific notation' is an explicit user action — it signals intent to treat the data as numbers.
(In reply to Piotr Osada from comment #11) > This would not conflict with the use case you described (preserving > carefully formatted cells), because enabling 'Detect scientific notation' is > an explicit user action — it signals intent to treat the data as numbers. If only every single user would pay attention to every single option, we would see less reports :). As for prioritizing the options selected on the Import Text dialog over already-formatted cells, we have seen requests (towards any kind of direction you could imagine). Most frequently, these requests (and complaints) are related to dates, but not only. In too many cases, it is a matter of understanding different formats and using Calc functions correctly (e.g. the function requests for the argument to be Text, not a Date, or vice-versa, or...). We have seen suggestions about how some automatic detection should work, only to find out that other users don't like the changes, breaking their workflow that have been working for years. Some of these reports are still opened, after changing what a simple ctrl+v does (or used to do, but not anymore). Moreover, we have at least one case in which the first row is imported one way and the rest is imported differently. I tested pasting 3 rows of 1.23e-4 (and similar numbers) on cells that were not previously formatted (i.e. "General" or "Standard"). The result is as expected. I don't see problems such as loosing meaningful digits, or incorrect formatting. I should also point out that, under some circumstances, you could introduce a number with scientific notation and the resulting display might be different; that does not necessarily mean that you lost meaningful digits, as the way Calc _displays_ the value is not the same as the value that was saved. The opposite can also be true: a number could be displayed in scientific notation, and after widening the column you might be able to see it as a simple number (i.e. not in scientific notation). I have seen such things a lot. IMO, the user could simply have the cells/columns formatted as "General" ("Standard") and import the numbers according to the Import Text dialog, so the result is as expected (with the potential need to change the column width after importing the data). If _that_ fails, then that's another issue. As for eliminating the initial apostrophe when the data is imported as text and you want to change the result, one way to deal with it is: <https://wiki.documentfoundation.org/Faq/Calc/How_to_convert_number_text_to_numeric_data> Other Faq/Calc items can be relevant too.
(In reply to ady from comment #12) > (In reply to Piotr Osada from comment #11) > ...we would see less reports :). Thank you for your patient response and for the FAQ link. I've read it all. Point taken — one can't satisfy every user :-) So RESOLVED NOTABUG or WONTFIX?