Download it now!
Bug 85762 - AutoSize for width on Frame works incorrectly when a one-word line is longer than previous lines
Summary: AutoSize for width on Frame works incorrectly when a one-word line is longer ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Frame
  Show dependency treegraph
 
Reported: 2014-11-02 16:25 UTC by Paddy Landau
Modified: 2019-01-30 09:51 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer document illustrating the example in the description (29.68 KB, application/vnd.oasis.opendocument.text)
2014-11-02 16:25 UTC, Paddy Landau
Details
PDF printed using 4.4.0.0 alpha2 from Nov 12 (16.68 KB, application/pdf)
2014-11-15 14:37 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paddy Landau 2014-11-02 16:25:18 UTC
Created attachment 108798 [details]
Writer document illustrating the example in the description

In some circumstances, AutoSize on a Frame fails to expand the width sufficiently.

Specifically, this happens when a line contains a single word that is longer than all previous lines.

Curiously, this does not happen to all of my Frames, but when it happens, it is reliably replicable.

Attached is a sample document.

TO DUPLICATE

1. Create a new Writer document, size A4.

2. Insert a Frame. Check AutoSize on both Width and Height.

3. In the text area of the Frame, set the text large (e.g. 88 pt) and type "Check it's worthwhile" (or any words where the first line is shorter than the last word). Alternatively, type "Check this is worthwhile" and delete letters from the first word.

This can be extended to having more than two lines, e.g. "Check that this wording is always worthwhile to use."

WHAT HAPPENS

When the a line with a single word is longer than any previous line, the frame width decreases, causing the second word to wrap.

This happens in A4 or Letter, and in Portrait or Landscape (with suitable text sizes and word lengths).

WHAT SHOULD HAPPEN

The frame should keep its width sufficient for the second line, allowing the second word to remain intact.

TESTED ON OPERATING SYSTEMS

o Ubuntu 14.04 64-bit
o Windows 7

TESTED ON LIBREOFFICE VERSIONS

4.3.3.1
4.4.0.0.alpha1
Comment 1 Paddy Landau 2014-11-02 16:29:34 UTC
Sorry, I mistyped the "what should happen" sentence. It should read:

The frame should keep its width sufficient for the one-word line, allowing that word to remain intact.
Comment 2 Buovjaga 2014-11-15 14:37:20 UTC
Created attachment 109521 [details]
PDF printed using 4.4.0.0 alpha2 from Nov 12

I opened your document and printed it to PDF. Does this exhibit the bug?

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
Comment 3 Paddy Landau 2014-11-15 15:22:56 UTC
Beluga, that is bizarre. I get the problem whereas you don't.

What difference could there be between your set-up and mine? Might we have different options set, perhaps?

I am currently testing on Version 4.4.0.0.alpha2, Build ID 24f0a5815f581dd9a7f09d30213a379edee6e9ac.

I have Version 4.3.4.1 installed. Would 4.4.0.0.alpha2 be sharing the options from 4.3.4.1? How can I test again with all options reset to the defaults (I'm using Ubuntu 14.04)?
Comment 4 Buovjaga 2014-11-15 15:58:43 UTC
Hey, you are right: on Ubuntu, the word "worthwhile" does get cut off from its last "e". Let's set to NEW and see what happens.
I would say severity = minor per this chart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29
Comment 5 Paddy Landau 2014-11-15 16:08:46 UTC
And yet I had this problem on Windows 7. Confusing!

Thanks for checking this.
Comment 6 Buovjaga 2015-01-09 14:46:31 UTC
Bug not observed in 3.3 or 3.5 -> likely regression.

Ubuntu 14.10 64-bit
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 7 Buovjaga 2015-01-09 14:49:41 UTC
Agh, I posted to the wrong bug! Last keyword/whiteboard changes reverted.

I *can* repro this with:

Ubuntu 14.10 64-bit
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 8 Paddy Landau 2015-02-26 13:35:00 UTC
I confirm that this bug is still present in 4.4.1.2.
Comment 9 tommy27 2016-04-16 07:27:16 UTC Comment hidden (obsolete)
Comment 10 Paddy Landau 2016-04-16 16:10:23 UTC
This bug is still present.
LibreOffice 5.1.2.2
Ubuntu 14.04 64-bit
Comment 11 QA Administrators 2017-05-22 13:23:54 UTC Comment hidden (obsolete)
Comment 12 Paddy Landau 2017-05-22 16:00:14 UTC
The bug is still present.
LibreOffice 5.3.3.2
Linux Ubuntu 16.04 64-bit
Comment 13 QA Administrators 2018-05-23 02:36:24 UTC Comment hidden (obsolete)
Comment 14 Paddy Landau 2018-05-23 12:58:53 UTC
I have retested this, and unfortunately the problem remains.

Help > About LibreOffice:

Version: 6.0.4.2
Build ID: 1:6.0.4~rc2-0ubuntu0.16.04.1
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB.UTF-8); Calc: group

Linux Ubuntu 16.04 64-bit

Thank you