Bug 57956 - FORMATTING: Regression: text width scaling broken in impress and draw
Summary: FORMATTING: Regression: text width scaling broken in impress and draw
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All All
: highest critical
Assignee: Jan Holesovsky
Whiteboard: bibisected40 target:3.6.7
Keywords: regression
: 58072 62813 (view as bug list)
Depends on:
Reported: 2012-12-06 19:36 UTC by Callegar
Modified: 2020-02-21 09:18 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:
Regression By:

Minimal testcase. (12.31 KB, application/vnd.oasis.opendocument.presentation)
2013-02-25 14:06 UTC, Jan Holesovsky

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2012-12-06 19:36:50 UTC
Problem description: 

Making drawings or presentation, it is often convenient to be able to adjust (scale) the character width (e.g. to make a word or a sentence look better inside a box, etc.  Openoffice and Libreoffice have a function for this under the character formatting menu.

Unfortunately, in recent LibO this does not work anymore (in the preview the text is scaled, but in the final display it is not). 

Steps to reproduce:
1. Open LibO draw or presentation
2. Create a text box, write something into it
3. Select the text
4. Select Format -> Character -> Position
5. Set a scaling different from 100% for the character width
    (here you see the preview text getting larger for scales above 100% and tight for scales less than 100%)
6. Press OK... and see that nothing actually changes!

Current behavior:

Text width gets scaled only in the preview, when you press OK to apply the formatting to the text in a text box, the text stays the same regardless of the text width scaling factor

Expected behavior:

The formatted text should increase or decrease its horizontal scale depending on the scaling factor being selected.


1) This is certainly a regression
2) This breaks the formatting of previously prepared documents and particularly of presentations (due to the fact that I am using text scaling in a template, almost all my presentations and lectures are broken and cannot be played properly).
3) AOO is OK on this.
Comment 1 Rob Snelders 2012-12-06 23:11:24 UTC
Confirmed with LO on Ubuntu 12.04 x86_64
Comment 2 kitaets 2012-12-14 07:40:16 UTC
Sadly confirm on (ID: 2ef5aff) @ Ubuntu 32-bit
What's up, doc???
Comment 3 kitaets 2012-12-28 10:21:30 UTC
Works Ok in (ID: 360m1(Build:2)) @ Ubuntu 32-bit
Bug in (ID: 2ef5aff) @ Ubuntu 32-bit
Comment 4 Jorendc 2012-12-28 23:47:49 UTC
Running bisect on this one:

git bisect start
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00
# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
git bisect bad 5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262
# good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f
git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea
# good: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f
git bisect good 7e20e241c1d8819d8d5edb7894baeddde33f9d3a
# good: [62b2ae5ee4cc77ad0b399c5a716ef526023d13ab] source-hash-e9960f36675a025c0536dec30ae56c50f4adecb1
git bisect good 62b2ae5ee4cc77ad0b399c5a716ef526023d13ab
# good: [e7627bbadeb1ab2ff16757dd240d55c0023f8257] source-hash-5b195fbcf7a441aeb193f6abd08b877e580938e0
git bisect good e7627bbadeb1ab2ff16757dd240d55c0023f8257
# good: [48ad81cc86b8858bfaa923854139e56fce18d28a] source-hash-98a77cef93663a0ae41dcc2c2858b418aeaaa40e
git bisect good 48ad81cc86b8858bfaa923854139e56fce18d28a
Comment 5 Bertrand 2012-12-29 07:51:14 UTC
Looks like this bug :
Comment 6 kitaets 2012-12-29 10:11:39 UTC
*** Bug 58072 has been marked as a duplicate of this bug. ***
Comment 7 Callegar 2013-01-15 10:08:14 UTC
Confirmed in 4.0RC1
Comment 8 Dave Richards 2013-01-15 17:59:28 UTC
Confirming the severity of this issue.  We had to roll back some users because this feature was a part of their work flow.
Comment 10 Callegar 2013-01-25 10:29:43 UTC
Still broken both in 4.0RC2 and 3.6RC2.

An additional glitch in 4.0RC2.

The corresponding field for controlling this parameter, named 'scalewidth' and tunable as a % value, in 4.0RC2 appears under a heading that says 'Rotation' rather than 'Scaling' as it should.
Comment 11 stephan+lo 2013-01-29 14:24:27 UTC
I can confirm that is it also broken in Writer:
Version .0.2 (Build ID: Gentoo official package)
Comment 12 Callegar 2013-02-02 12:35:33 UTC
Looks like this went through in 3.6.5 final and 4.0 RC 3.
Comment 13 Jan Holesovsky 2013-02-21 07:39:13 UTC
Joren: Thank you again for bi-bisecting!

I've bisected this, and it turns out that I've caused this:
 fa694a21b806ed7837c1337ec49a4b299c478393 is the first bad commit
commit fa694a21b806ed7837c1337ec49a4b299c478393
Author: Jan Holesovsky <kendy@suse.cz>
Date:   Fri Oct 12 17:41:49 2012 +0200

    fdo#55931 Fix renderding of subscript/superscript with Autofit Text.
    We are using font metrics to compute the stretch ratio for autofit; but that
    collides with nPropr property of SvxFont - it is then counted twice, ie. in
    the case of nPropr == 25, we actually behave as if it was much less; and
    worse, only in the horizontal direction.
    Change-Id: Idba62f1e3f40802651b93f1344e376048866b1b6

:040000 040000 cc99d0a8cdfa165747d486fc39154a03717e9c5b 0fc9636bb0a0ddcd9cecbaa5133e1983969f5f73 M	editeng

Can look first on Monday, unfortunately not earlier.
Comment 14 Jan Holesovsky 2013-02-25 14:06:51 UTC
Created attachment 75507 [details]
Minimal testcase.
Comment 15 Jan Holesovsky 2013-02-25 14:16:14 UTC
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "master":


fdo#55931, fdo#57956: Fix both autofit and stretched width.

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:
Affected users are encouraged to test the fix and report feedback.
Comment 16 Jan Holesovsky 2013-02-25 14:19:56 UTC
I believe this is fixed now.  The patch is pending a review for 4.0.
Comment 17 blubb 2013-03-23 13:32:40 UTC
I have been able to reproduce the bug in
But it has been fixed in and in the daily build of today. 
Have set it to verified.
Comment 18 Björn Michaelsen 2013-04-15 14:30:24 UTC
@Kendy: Hmm, since this is appearing on 3.6.4 but the commit causing it was done after 3.6.0, is this a micro release regression, can we backport the fix?
Comment 19 Jacques Guilleron 2013-05-10 07:24:06 UTC
*** Bug 62813 has been marked as a duplicate of this bug. ***
Comment 20 Björn Michaelsen 2013-07-22 12:08:06 UTC
Fixed in 3.6.7, setting target: