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!
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
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.
Confirmed with LO 220.127.116.11-Master on Ubuntu 12.04 x86_64
Sadly confirm on 18.104.22.168 (ID: 2ef5aff) @ Ubuntu 32-bit
What's up, doc???
Works Ok in 22.214.171.124 (ID: 360m1(Build:2)) @ Ubuntu 32-bit
Bug in 126.96.36.199 (ID: 2ef5aff) @ Ubuntu 32-bit
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
Looks like this bug :
*** Bug 58072 has been marked as a duplicate of this bug. ***
Confirmed in 4.0RC1
Confirming the severity of this issue. We had to roll back some users because this feature was a part of their work flow.
I'm not 100% sure, but I think this is a related commit to this topic that might introduce the bug: http://cgit.freedesktop.org/libreoffice/core/commit/?id=50a20f94869c2033d495da7d57f9948988cd5ad9
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.
I can confirm that is it also broken in Writer:
Version 188.8.131.52 .0.2 (Build ID: Gentoo official package)
Looks like this went through in 3.6.5 final and 4.0 RC 3.
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
Author: Jan Holesovsky <firstname.lastname@example.org>
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.
:040000 040000 cc99d0a8cdfa165747d486fc39154a03717e9c5b 0fc9636bb0a0ddcd9cecbaa5133e1983969f5f73 M editeng
Can look first on Monday, unfortunately not earlier.
Created attachment 75507 [details]
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.
I believe this is fixed now. The patch is pending a review for 4.0.
I have been able to reproduce the bug in 184.108.40.206.
But it has been fixed in 220.127.116.11 and in the daily build of today.
Have set it to verified.
@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?
*** Bug 62813 has been marked as a duplicate of this bug. ***
Fixed in 3.6.7, setting target: