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)
Created attachment 119218 [details] screenshot
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)
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
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
Lets try to get a more detailed bibisect.
(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
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
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.
(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.
(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.
(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.
(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?
(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.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Dear Yousuf Philips (jay), 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 136416 has been marked as a duplicate of this bug. ***
@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)
(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
(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 ?
Created attachment 165282 [details] How it looks in LibreOffice 7.1 master
(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.
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
Created attachment 184789 [details] example ODT with 3 shapes filled with 3 tiled bitmaps Note that the preview does not change depending on the zoom level, so for a fair comparison, make sure the zoom level is at 100%. The attachment uses three example bitmaps that make it easy to compare preview and "reality". Reproduced in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 579d144290c1617fdb38d09b30900a6bbe390b8d CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (en_AU.UTF-8); UI: en-US Calc: threaded