Description: Suppose that you have a piece of text including words in different sizes (e.g. 12 pt and 14 pt) and that you want to change all that piece of text to another font, maintaining the different font sizes. Until LibO 6.0 you could highlight the piece of text and do Format->Character. There, you would get a blank slot for the font size (because the higlighted text included text in multiple font sizes). By selecting a new font name, you could change the font look, while maintaining the original font size. If you do this with LibO 6.1 as you change the font name and press OK, you see the text disappear. In fact, the text is not disappearing, but the dialog is applying a font size 2 (almost invisible) to the whole text. The issue is present in all applications (write draw calc and impress), but happens in a slightly different way in writer and calc, where the char sizes get equalized and shown by the property pane as being set to two, while the chars keep being drawn at a readable size (which is revealed by tring to change the value in the property pane). The issue started with 6.1. Previous LibO versions (5.4 and 6.0 tested) did not have this problem. Steps to Reproduce: 1. Open draw 2. Create a text box including the words "One Two", make "One" 10pt and Two 20pt 3. Select "One Two", Open Format->Character 4. Change the font name press OK Actual Results: See the text disappear and verify that it is actually there in font size 2 Expected Results: As in LibO up to 6.x, you should see the text in the new font, still with "One" at 10pt and "Two" at 20pt Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: DrawingDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
I see the described behavior in Version: 6.1.0.3 (x64) Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: de-DE (en_US); Calc: CL It was OK in Version: 6.0.6.2 (x64) Build-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (en_US); Calc: CL
confirming, writer is affected too Version: 6.1.1.2 (x64) Build-ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc:
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f00e891f3369f7b8c2532634d9ff4ab19da17c33 author Mike Kaganski <mike.kaganski@collabora.com> 2018-02-21 00:30:16 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> 2018-02-21 08:11:23 +0100 commit f00e891f3369f7b8c2532634d9ff4ab19da17c33 (patch) tree 752901b046836b0aab906cd7966a178636bf290e parent ba8a70365ef459c967cd8a71a6d48ca53dd341bd (diff) tdf#115892: properly get the box' saved value and later fixed by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9237a905fa5f2b67db73c15847eff203a258c2b4 author Caolán McNamara <caolanm@redhat.com> 2018-09-10 17:19:19 +0100 committer Caolán McNamara <caolanm@redhat.com> 2018-09-14 11:43:51 +0100 commit 9237a905fa5f2b67db73c15847eff203a258c2b4 (patch) tree bf213e7f3fd7322ee032af9fa648d04c99faaba1 parent 34f6b7f4529cc5a3b0e286fbd7318c2b7bf9b132 (diff) weld SvxCharNamePage @Caolán, any chance the fix for this issue could be backported to 6.1 branch?
I see, the GetIntSavedValue runs the saved text (which is empty) through the number formatter to get a number to see if it was changed from its original version. But the empty text is a zero, but the min allowed is 2, so it becomes a 2, i.e. forces it to the legal range
For the welded case we're comparing the textural string rather than the value it turns into so the problem doesn't arise. For the case in 6-1 its good enough to just special case in GetIntValue the empty string case to return 0 and all is well again. https://gerrit.libreoffice.org/#/c/61378/
*** Bug 119462 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5239c649ead0344f6a8fc1bcee44a2ec9fd6ae56&h=libreoffice-6-1 Resolves: tdf#120031 skip min/max for empty string in GetSavedIntValue It will be available in 6.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.1.4.0.0+ Build ID: f1e09253316d9db39b7adab6d31e759c09de3406 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Caolán, Thanks for fixing this!!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6ab0e309adabd8aeda00909b2ea9f0f1cb45144a&h=libreoffice-6-1-3 Resolves: tdf#120031 skip min/max for empty string in GetSavedIntValue It will be available in 6.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.