Description: How to reproduce: 1. Create a table 2. Select the second and all following rows 3. Rightclick Size --> Row hight 4. Untick Fit to size 5. Try entering a value (I tried 0,4 cm) Expected behavior: Row hight is changed to 0,4 cm Actual behavior: Row hight is changed to zero Steps to Reproduce: 1. Create a table 2. Select the second and all following rows 3. Rightclick Size --> Row hight 4. Untick Fit to size 5. Try entering a value (I tried 0,4 cm) Actual Results: Row hight is changed to zero Expected Results: Row hight is changed to 0,4 cm Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: I tried this on: Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Flatpak Locale: el-GR (en_US.UTF-8); Calc: group threaded Version 6.0.6.2 (Ubuntu ppa) does work as expected. glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.5 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.0.5 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions:
Created attachment 144495 [details] Video showing the bug
I can't reproduce it in Versión: 6.1.0.3 Id. de compilación: efb621ed25068d70781dc026f7e9c5187a4decd1 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
I would be glad to do it. However, as I do not wan't to delete the wrong profile. Do you happen to know, where the profiles are stored in the flatpak version?
You can also check in safe mode wihtout deleting the profile. Go to Help - Restart in Safe mode - Continue in Safe mode
Thank you, sorry for not trying this earlier. It has been a long time since resetting the user profile was needed. I do not have the problem in safe mode.
I still can reproduce. setting the Locale to Greek seems to be the culprit, though this is extremely strange. When I change locale to Greek --> bug Changing locale to US English --> not reproducible
In the video attached, I see the value in Height changes to 0,00 right before the dialog is closed. What happens if you use 0.40 ( with a dot ) instead ?
Nice catch. It seems to work. Though it still is a bug, as a dot should not be a decimal separator when Greek is selected as locale.
That's something you can configure in Tools - Options - Language Settings - Language - Decimal Separator Key...
Thank you I know. It is set to same as locale (,) and nontheless it does not work when I enter a value separated by comma(,) instead of dot(.).
(In reply to Nikos from comment #10) > Thank you I know. It is set to same as locale (,) and nontheless it does not > work when I enter a value separated by comma(,) instead of dot(.). Are you sure about the locale, though? I see you have "Locale: el-GR (en_US.UTF-8);" In my install I have "Locale: fi-FI (fi_FI.UTF-8);" and not any en_US.
On: Version: 6.1.1.2 Build ID: 1:6.1.1~rc2-0ubuntu0.18.04.1~lo3 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: el-GR (en_US.UTF-8); Calc: group threaded and on Version: 6.1.1.2 Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Flatpak Locale: el-GR (en_US.UTF-8); Calc: group threaded I can no longer reproduce. meaning values with , are interpreted correctly. I always had this locale settings. I no longer have the 6.1.0.3 version so I change status to fixed though it was probably not a conscious fix. Thank you all for the time.