Bug 120031 - REGRESSION: LibO 6.1 format->character dialog overrides font size to two making chars unreadable
Summary: REGRESSION: LibO 6.1 format->character dialog overrides font size to two maki...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.2.0 target:6.1.3
Keywords: bibisected, bisected, regression
: 119462 (view as bug list)
Depends on:
Blocks: Character
  Show dependency treegraph
 
Reported: 2018-09-21 12:32 UTC by sergio.callegari
Modified: 2018-10-16 22:23 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2018-09-21 12:32:34 UTC
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
Comment 1 Regina Henschel 2018-09-21 13:39:11 UTC
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
Comment 2 Oliver Brinzing 2018-09-21 16:18:03 UTC
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:
Comment 3 Xisco Faulí 2018-09-22 00:06:56 UTC
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?
Comment 4 Caolán McNamara 2018-10-04 13:35:14 UTC
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
Comment 5 Caolán McNamara 2018-10-04 13:39:06 UTC
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/
Comment 6 Caolán McNamara 2018-10-04 13:41:50 UTC
*** Bug 119462 has been marked as a duplicate of this bug. ***
Comment 7 Commit Notification 2018-10-12 10:11:00 UTC
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.
Comment 8 Xisco Faulí 2018-10-15 10:04:50 UTC
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!!
Comment 9 Commit Notification 2018-10-15 10:18:32 UTC
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.