Bug 87425 - FORMATTING: Image captions no longer make image relative size, so images don't scale with frame
Summary: FORMATTING: Image captions no longer make image relative size, so images don'...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: 4.3.0.4 release
Hardware: Other All
: medium major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: bibisected
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2014-12-17 22:32 UTC by tmacalp
Modified: 2014-12-28 08:41 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Attachments

Description tmacalp 2014-12-17 22:32:22 UTC 
Description:
Before LibreOffice 4.3, when one applied a caption to an image, the image's size was turned to width 100% relative to the caption frame and height auto-sized.  This made the captioned image actually scale when resizing the caption frame.  This is broken in LO 4.3+, and resizing the caption frame does nothing to adjust the size of the contained image.

Steps to reproduce:
1. Insert any image
2. Right click image -> caption
3. OK
4. Resize caption frame

Expected:
Since we applied a caption frame, the picture should now relatively scale its width to 100% of the frame and autosize the height.  This will allow the picture to expand and contract with the frame.

Actual:
The image size is left to an absolute size and does not scale with the frame.

Notes:
This is extremely annoying, especially for dealing with lots of captioned pictures.  It completely defeats the purpose of having a caption function, since captions are really just frames with relatively sized pictures in them.  You now have to either manually scale both image and frame to be the same, or edit image properties to enable relative scaling.

I am experiencing this bug in LO 4.3.4.1 using 64bit RHEL 6 and LO 4.4.0 beta2 under 32bit Fedora17.  This option still worked in LibreOffice 4.2.6.

I've bibisected:

f780f9a999d8300a2a72658063d6e823000fbae4 is the first bad commit
commit f780f9a999d8300a2a72658063d6e823000fbae4
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sun May 11 00:36:04 2014 +0000

    source-hash-4356aef48a8fcbd9dd019c0ca2d6a189d7332d0c
    
    commit 4356aef48a8fcbd9dd019c0ca2d6a189d7332d0c
    Author:     Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
    AuthorDate: Thu Jan 9 13:22:16 2014 +0100
    Commit:     Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
    CommitDate: Thu Jan 9 13:22:16 2014 +0100
    
        fdo#70596 - fix version dependency for linux package - 2nd try
    
        in commit 65a7e714292dbf4c5a2a4f5760f3b546d603c40c I was under the wrong
        assumption that the revision is added by epm and will be always 1.
    
        Instead the revision is passed to the epm calls in the commandline
        arguments. So the upper version limit must use the "patchlevel" as the
        revision. (version a.b.c.d => d is also release number)
    
        Change-Id: I5002aef88e454561ba610b2d2774b84712da44dc

:100644 100644 02a3d23704cc479bd32d457eb432982f9ce283f4 18dd206298b76f34a3fa5839ccc016feda4ba8e3 M      ccache.log
:100644 100644 3fed867c3434f93c8a6aeaf5ff0dbdcba47090d4 9b2a17751bf33f2f0afc91bd4b35993d8bf0f15f M      commitmsg
:100644 100644 816d1ec83caf9a104b473fe7f8dc9cd186b5d720 b7b94f66a8f3a3303de174610e489f4d7ecaef75 M      make.log
:040000 040000 428a4fdc97569110da3422b36c1b67d5c0a1e037 3800bd01f059b108470d387b69a22df779d889db M      opt


$ git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4
git bisect start 'latest' 'last42onmaster'
# bad: [4fcd68ce4979f85fda4568f4b419a4b41d07345f] source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e
git bisect bad 4fcd68ce4979f85fda4568f4b419a4b41d07345f
# bad: [0d4c20a601a3cfff27d6685d0e81463086bd9d74] source-hash-f1b1e73227471192682d303a58618ca8bd65a74d
git bisect bad 0d4c20a601a3cfff27d6685d0e81463086bd9d74
# skip: [18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf] source-hash-fe506f34f2dccb6562935fe4dfbc1fe6d609dec8
git bisect skip 18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf
# good: [9fe7b44f1975d64e3009c31341187c53c8e3a2b8] source-hash-7f5494f3c4bf14209a119c6b21c02e10075503ae
git bisect good 9fe7b44f1975d64e3009c31341187c53c8e3a2b8
# bad: [f1e56b0f09e0a75b8970a8b9892298f0ca210200] source-hash-eeeefd6fd87b3cff18ba9078869bdfcd0e351d6f
git bisect bad f1e56b0f09e0a75b8970a8b9892298f0ca210200
# bad: [f780f9a999d8300a2a72658063d6e823000fbae4] source-hash-4356aef48a8fcbd9dd019c0ca2d6a189d7332d0c
git bisect bad f780f9a999d8300a2a72658063d6e823000fbae4
# good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
# good: [3df91c208de9113ce991e71bb67f175b01f804c8] source-hash-396b3594feb735e1a9cd1564f28340d514f9d925
git bisect good 3df91c208de9113ce991e71bb67f175b01f804c8
# first bad commit: [f780f9a999d8300a2a72658063d6e823000fbae4] source-hash-4356aef48a8fcbd9dd019c0ca2d6a189d7332d0c
Comment 1 tmacalp 2014-12-17 22:35:13 UTC 
I'm adding keyword regression and bibisected whiteboard.  I also upped the severity to "major," since it is an obvious regression.
Comment 2 crxssi 2014-12-18 03:13:10 UTC 
Confirmed in LibreOffice 4.3.4 in RHEL 6.  Regression behavior and quite irritating.
Comment 3 Matthew Francis 2014-12-23 18:15:25 UTC 
This commit appears to be the one that changed the behaviour. It looks like there may be two equal and opposite requirements battling each other here.


commit 235c790fdb04c27487de4510a0d51323f5442e70
Author: Tsutomu Uchino <hanya@apache.org>
Date:   Wed Jan 8 12:38:09 2014 +0000

    Resolves: #i51453# avoid relative sizing for the picture and...
    
    formula wrapped by inserted frame when caption is added
    
    (cherry picked from commit 0681d4e0cd7425349600672964e48a5dbbb3c7db)
    
    Change-Id: Ie526391b8676c259a77060dbe04c3e7c8ad499c0
Comment 4 tmacalp 2014-12-23 19:25:09 UTC 
From the Apache OO bug report:
> I propose to set it to 0. This affects to: 
> - math formula: not resized with outer frame
> - picture: Relative is off by default. But pictures with caption can be 
> resized and relative check box can be changed by the user. In my opinion, 
> relative check box should be not checked by default even for pictures. 
> The content of the caption frame is the main content of the document and 
> no one want to resize it depends on the caption layout.

https://issues.apache.org/ooo/show_bug.cgi?id=51453

I can understand the possible need for this fix for formulas, but the fix was over-reaching when it comes to images.  Images should default to being resized relatively based on the caption frame.  Other comments in that report also indicate that images should still be handled relatively.

This behavior makes word processing/desktop publishing considerably more difficult, tedious, and confusing.  I think this new behavior does more overall harm than good when it comes to typical workflows.
Comment 5 Matthew Francis 2014-12-28 08:41:18 UTC 
Adding a Cc: to caolanm@redhat.com as the committer for the AOO merge mentioned above (235c790fdb04c27487de4510a0d51323f5442e70)

Could you possibly take a look at this? Thanks

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.