Bug 94714 - Bitmaps and patterns are applied at a larger size
Summary: Bitmaps and patterns are applied at a larger size
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 136416 (view as bug list)
Depends on:
Blocks: Object-Fill-Pattern Object-Fill-Bitmap
  Show dependency treegraph
 
Reported: 2015-10-02 22:58 UTC by Yousuf Philips (jay) (retired)
Modified: 2022-09-10 03:51 UTC (History)
6 users (show)

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


Attachments
screenshot (174.48 KB, image/png)
2015-10-02 23:00 UTC, Yousuf Philips (jay) (retired)
Details
How it looks in LibreOffice 7.1 master (278.44 KB, image/png)
2020-09-08 15:51 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-10-02 22:58:40 UTC
Steps:
1) Open Writer
2) Insert a shape
3) In the toolbar set the fill to the Water bitmap
4) Compare how the image looks in the Context Menu > Area > Area preview and how it looks in the document

Regression as this doesnt happen in 4.4 daily.

Version: 5.1.0.0.alpha1+
Build ID: ef1bafb588eb20a5d35df14e79a1a948885c721a
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-29_23:55:44
Locale: en-US (en_US.UTF-8)
Comment 1 Yousuf Philips (jay) (retired) 2015-10-02 23:00:32 UTC
Created attachment 119218 [details]
screenshot
Comment 2 Buovjaga 2015-10-06 11:44:51 UTC
Confirmed.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 25de5cfa43b2b1cb7d7214470acc7719839e13fe
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-01_08:49:54
Locale: en-US (fi_FI)
Comment 3 raal 2015-10-22 09:32:08 UTC
This seems to have begun at the below commit.
Adding Cc: to caolanm@redhat.com ; Could you possibly take a look at this one? Thanks
 cea8da0e6309c2faf3625c463eb0ac35a41d81d6 is the first bad commit
commit cea8da0e6309c2faf3625c463eb0ac35a41d81d6
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Mon May 18 04:35:34 2015 -0500

    source c0948f29ebd61a232406c30c306d7d8b23a596a6

    source c0948f29ebd61a232406c30c306d7d8b23a596a6

	
	author	Caolán McNamara <caolanm@redhat.com>	2015-01-14 16:55:02 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2015-01-14 20:30:08 (GMT)
commit c0948f29ebd61a232406c30c306d7d8b23a596a6 (patch)
Use the same advanced Ellipse and Rectangle shapes in writer as draw

/bibisect-win32-5.0
$ git bisect log
# bad: [575cd25f0560684895018d8fcfb1818dd4dd1c9b] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65
# good: [f449493ae11ac76cc7396bddeaa624a60c565936] source 57d6b92b69a31260dea0d84fcd1fc5866ada7adb
git bisect start 'libreoffice-5-0-branch-point' 'oldest'
# bad: [da12357c491a0dce5acc0bd1f00c26f89d8f20e6] source c1b9402d49a7cd4bec383f28d397d9d89541f0e0
git bisect bad da12357c491a0dce5acc0bd1f00c26f89d8f20e6
# good: [74d1ce30418f1228c11e865e8b6094f15293a528] source 9763b55eb946cf425220d26dab91bf220890b180
git bisect good 74d1ce30418f1228c11e865e8b6094f15293a528
# bad: [879803b25a6209bb29e5204346682a3a26bbee23] source 602f5010bc41f71d29695a348d56b6d953865c2f
git bisect bad 879803b25a6209bb29e5204346682a3a26bbee23
# bad: [71a9ffc79c1ecd813f0ac6a27f139b3965164782] source eeccf1be6a5752b2288086d1f52c1b1e3e5c4137
git bisect bad 71a9ffc79c1ecd813f0ac6a27f139b3965164782
# bad: [73af514a13c44bb94e2c32bd608ae9bf115bba08] source 31e5afcd7abcb27aa2af991aebdb184fa0e15849
git bisect bad 73af514a13c44bb94e2c32bd608ae9bf115bba08
# good: [c8d32cf0f27cbbe1c708bd90b41c7abb47adffbd] source a04e32558738c912913fa368e0e2cf237e61485c
git bisect good c8d32cf0f27cbbe1c708bd90b41c7abb47adffbd
# good: [ff93f3b0cb3934a6d18aa825ac12b998b7a82cbd] source 840810d41e7f865752d1af09c9d99e955467ce6c
git bisect good ff93f3b0cb3934a6d18aa825ac12b998b7a82cbd
# good: [436ca573b5834afad4f1c749d2d7e7b9983ec0c5] source 35fa188305600fa950a07e4b6c4f6a77a42d32d6
git bisect good 436ca573b5834afad4f1c749d2d7e7b9983ec0c5
# good: [77b0e0164b26e44285a77b6e917822d1e597949d] source 9ab76447cd7e1c61bc284c810734227438aa13c7
git bisect good 77b0e0164b26e44285a77b6e917822d1e597949d
# bad: [acae0fb73b08fd579689955cce9f791ecfd50977] source 17adf466dfce243e3f5d75fc5959f3f3c2dc0cfa
git bisect bad acae0fb73b08fd579689955cce9f791ecfd50977
# bad: [cea8da0e6309c2faf3625c463eb0ac35a41d81d6] source c0948f29ebd61a232406c30c306d7d8b23a596a6
git bisect bad cea8da0e6309c2faf3625c463eb0ac35a41d81d6
# good: [923e6e0958f968cc1872be13ad97fb7f849ef03b] source 283170e7a37855b6902d3828e42f3265057d9c77
git bisect good 923e6e0958f968cc1872be13ad97fb7f849ef03b
# good: [21f6e86d9a96d76689288d3c5d1e3ed5c82372eb] source 06983ef3c00c5755ef3369c1149c10ba8d3f4d4b
git bisect good 21f6e86d9a96d76689288d3c5d1e3ed5c82372eb
# first bad commit: [cea8da0e6309c2faf3625c463eb0ac35a41d81d6] source c0948f29ebd61a232406c30c306d7d8b23a596a6
Comment 4 Caolán McNamara 2015-10-23 08:25:33 UTC
what bibisect repo are you using, because it seems very unlikely that the above commit has an effect on the reported issue. Perhaps its a repo that compiles only ever x commits and its a different commit within the sampled range thats at fault
Comment 5 Yousuf Philips (jay) (retired) 2015-10-23 15:31:14 UTC
Lets try to get a more detailed bibisect.
Comment 6 raal 2015-10-23 16:38:13 UTC
(In reply to Caolán McNamara from comment #4)
> what bibisect repo are you using, because it seems very unlikely that the
> above commit has an effect on the reported issue. 
>Perhaps its a repo that
> compiles only ever x commits and its a different commit within the sampled
> range thats at fault

git://gerrit.libreoffice.org/bibisect-win32-5.0
Comment 7 Robinson Tryon (qubit) 2015-12-14 05:32:31 UTC Comment hidden (obsolete)
Comment 8 Joel Madero 2015-12-19 23:23:55 UTC
If you uncheck "original" in the dialog the bitmap looks fine.

Context Menu -> Area -> Size (right side) -> "Original" (checkbox)

I tested 3.3 and I *think* I see the same behavior. I also tested using 44max, 45max, and bibisect35, each time, same result.

I'm tempted to change this to notBibisectable as it seems to be really time consuming for a pretty minor "issue?" (just uncheck the box....)

@Jay - I leave it in your hands. Just a heads up that I just spent 30 minutes trying to bibisect it and failed.
Comment 9 Yousuf Philips (jay) (retired) 2015-12-21 09:39:48 UTC
(In reply to Joel Madero from comment #8)
> @Jay - I leave it in your hands. Just a heads up that I just spent 30
> minutes trying to bibisect it and failed.

@Joel: Having the 'original' checked is supposed to return what we are now seeing with original not checked, so LO is incorrectly applying 'original' when 'original' isnt checked. Thanks for the bibisect.
Comment 10 Heiko Tietze 2016-05-24 08:08:59 UTC
(In reply to Yousuf (Jay) Philips from comment #9)
> @Joel: Having the 'original' checked is supposed to return what we are now
> seeing with original not checked, so LO is incorrectly applying 'original'
> when 'original' isnt checked. Thanks for the bibisect.

True, but isn't checkbox on/off another bug, which will be fixed once the bitmap fill options are reworked? Close as fixed, IMHO.
Comment 11 Yousuf Philips (jay) (retired) 2016-05-24 17:38:49 UTC
(In reply to Heiko Tietze from comment #10)
> True, but isn't checkbox on/off another bug, which will be fixed once the
> bitmap fill options are reworked? Close as fixed, IMHO.

The regression is in how the checkbox is being handled so that is what the bug is about. Yes with the new version of the fill dialog, this likely will be fixed, but that doesnt fix the regression in the current available versions.
Comment 12 Xisco Faulí 2016-09-22 15:23:29 UTC
(In reply to Yousuf Philips (jay) from comment #11)
> (In reply to Heiko Tietze from comment #10)
> > True, but isn't checkbox on/off another bug, which will be fixed once the
> > bitmap fill options are reworked? Close as fixed, IMHO.
> 
> The regression is in how the checkbox is being handled so that is what the
> bug is about. Yes with the new version of the fill dialog, this likely will
> be fixed, but that doesnt fix the regression in the current available
> versions.

Which is the current version? Is it still reproducible in 5.2? if not, can we just close it?
Comment 13 Yousuf Philips (jay) (retired) 2016-09-22 16:19:52 UTC
(In reply to Xisco Faulí from comment #12)
> Which is the current version? Is it still reproducible in 5.2? if not, can
> we just close it?

Yes it still affects 5.2 and 5.3 master.
Comment 14 Xisco Faulí 2017-09-29 08:50:48 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2020-01-06 03:26:45 UTC Comment hidden (obsolete)
Comment 16 Telesto 2020-09-02 21:45:31 UTC
*** Bug 136416 has been marked as a duplicate of this bug. ***
Comment 17 Telesto 2020-09-02 21:47:25 UTC
@Caolan
Rather unexpected.. an open UI bug. You're mostly pretty fast with this type of issue. Height and width numbers are off too (see dupe)
Comment 18 Xisco Faulí 2020-09-08 15:40:02 UTC
(In reply to Yousuf Philips (jay) (retired) from comment #11)
> (In reply to Heiko Tietze from comment #10)
> > True, but isn't checkbox on/off another bug, which will be fixed once the
> > bitmap fill options are reworked? Close as fixed, IMHO.
> 
> The regression is in how the checkbox is being handled so that is what the
> bug is about. Yes with the new version of the fill dialog, this likely will
> be fixed, but that doesnt fix the regression in the current available
> versions.

The checkbox no longer exists in 

Version: 7.1.0.0.alpha0+
Build ID: 5f7cbf60b71e78d4a980ec46953c4524ec0fd80c
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Closing as RESOLVED WONTFIX
Comment 19 Xisco Faulí 2020-09-08 15:51:42 UTC
(In reply to Xisco Faulí from comment #18)
> (In reply to Yousuf Philips (jay) (retired) from comment #11)
> > (In reply to Heiko Tietze from comment #10)
> > > True, but isn't checkbox on/off another bug, which will be fixed once the
> > > bitmap fill options are reworked? Close as fixed, IMHO.
> > 
> > The regression is in how the checkbox is being handled so that is what the
> > bug is about. Yes with the new version of the fill dialog, this likely will
> > be fixed, but that doesnt fix the regression in the current available
> > versions.
> 
> The checkbox no longer exists in 
> 
> Version: 7.1.0.0.alpha0+
> Build ID: 5f7cbf60b71e78d4a980ec46953c4524ec0fd80c
> CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
> Locale: en-US (en_US.UTF-8); UI: en-US
> Calc: threaded
> 
> Closing as RESOLVED WONTFIX

ok, so now the checkbox is called Scale, so if it's enabled, the bitmap scales and it's the same in the preview than in the shape. I don't see any issue in master.
Could others please confirm ?
Comment 20 Xisco Faulí 2020-09-08 15:51:59 UTC
Created attachment 165282 [details]
How it looks in LibreOffice 7.1 master
Comment 21 Buovjaga 2020-09-09 13:03:59 UTC
(In reply to Xisco Faulí from comment #19)
> ok, so now the checkbox is called Scale, so if it's enabled, the bitmap
> scales and it's the same in the preview than in the shape. I don't see any
> issue in master.
> Could others please confirm ?

Well, there is still the scale difference between what you see in the document and what you see in the dialog preview as is clearly shown in your screenshot. The Scale control was added in this commit:
https://git.libreoffice.org/core/commit/0e867bc4cba66c14d543e111ea8ab89dc2444ee0
The file cui/uiconfig/ui/bitmaptabpage.ui has it

Also, if you activate Scale, the preview is shown squished in the y axis and doesn't thus match how it will changed when applied to the document.

I'm starting to doubt the whole history of this report, though. Contrary to what is said in the comments, I can't find a point, where unchecking Original would make the preview match the document rendering.

I also confirm what is said in comment 8, this is not a regression.
Comment 22 QA Administrators 2022-09-10 03:51:04 UTC
Dear Yousuf Philips (jay) (retired),

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug