Created attachment 94446 [details] Cropped image (negative crop value) not showing I have some files which contain several image. Some are cropped. In the enclosed attachment I have just pasted two of them. 1) not cropped 2) cropped and not visible If you trigger to 0 the negative crop value then the image will be shown. Ok, now go back to LO 4.1
*** Bug 75270 has been marked as a duplicate of this bug. ***
Created attachment 94448 [details] test file
On 20/02/2014 17:50, bugzilla-daemon@freedesktop.org wrote: > > *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=75269#c1> > on bug 75269 <https://bugs.freedesktop.org/show_bug.cgi?id=75269> from > sophie <mailto:gautier.sophie@gmail.com> * > ***Bug 75270 <show_bug.cgi?id=75270> has been marked as a duplicate of this bug. *** > ------------------------------------------------------------------------ > You are receiving this mail because: > > * You reported the bug. > hello, my bug text is "red". Is there somethings that I should do? thank you. Gianni
Hello, any news? It's there someone that has the same problem? thank you.
@gioni, you shouldn't mark your own bug report as NEW. Someone will do that after confirming same problem. Please provide step by step procedure to see the problem
hi, in the enclosed "test file" created with 4.1.6.2 are two image "triangle". If open with 4.2.5 you will see only the first. Right click on second, go to crop tab and put to 0 crop values. Now you will see the second too. bye
I can confirm this. LibreOffice 4.3.0.2 on Windows XP.
Same problem on 4.4.0.3 (windows 7). Really boring. I cannot upgrade to latest version because all my files have a lot of cropped images.. Please make a little efforts! Tell me if I can help. thank you Gianni
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs). As this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc), its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting the QA Team on IRC: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
(In reply to gioni from comment #6) > in the enclosed "test file" created with 4.1.6.2 are two image "triangle". > If open with 4.2.5 you will see only the first. > Right click on second, go to crop tab and put to 0 crop values. Now you will > see the second too. gioni: Sounds like a possible regression. Are you saying that the problems don't occur with 4.1.6.2 ? Jean: Can you repro this on GNU/Linux as well? (possible bibisect candidate)
(In reply to Robinson Tryon (qubit) from comment #10) > (In reply to gioni from comment #6) > > in the enclosed "test file" created with 4.1.6.2 are two image "triangle". > > If open with 4.2.5 you will see only the first. > > Right click on second, go to crop tab and put to 0 crop values. Now you will > > see the second too. > > gioni: Sounds like a possible regression. Are you saying that the problems > don't occur with 4.1.6.2 ? > > Jean: Can you repro this on GNU/Linux as well? (possible bibisect candidate) Thank you Robinson for your interest in this matter. Yes, I confirm last working release for me is 4.1.6.2. I have several docs with cropped image and because of this bug, continuously, I upgrade to new release and then.. downgrade. I just upgraded Ubuntu libreoffice release to 4.2.7.2 and the problem is still there. Let me say if I can help! ciao
(In reply to gioni from comment #11) > Thank you Robinson for your interest in this matter. :-) > Yes, I confirm last working release for me is 4.1.6.2. Ah, that's great to hear: Keywords -> regression > I have several docs > with cropped image and because of this bug, continuously, I upgrade to new > release and then.. downgrade. > I just upgraded Ubuntu libreoffice release to 4.2.7.2 and the problem is > still there. If it's reproducible on Ubuntu, then we can use bibisect. Whiteboard -> bibisectRequest > Let me say if I can help! Have you ever used git? We have a tool called 'bibisect' where we put binary copies of LibreOffice in a git repository and then can use the 'git bisect' tool to run a binary search to figure out which commit introduced the problem. Details here: https://wiki.documentfoundation.org/Bibisect Based on the range in which this bug is reproducible, I think you'll want to use the '43all' repository. For additional help using bibisect, feel free to ask questions in the #libreoffice-qa IRC channel or email me. Good luck!
Sorry Robinson but I don't have any Linux OS so can't test it.
Bibisect results from 43all: 8aabf2aee6514311020b855a95a6e44bab3a5b0d is the first bad commit commit 8aabf2aee6514311020b855a95a6e44bab3a5b0d Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Nov 27 09:32:23 2013 +0000 source-hash-0aa9ced531b8d85ad067c1d156a9708eea628d78 commit 0aa9ced531b8d85ad067c1d156a9708eea628d78 Author: Tor Lillqvist <tml@collabora.com> AuthorDate: Wed Nov 6 00:43:06 2013 +0200 Commit: Tor Lillqvist <tml@collabora.com> CommitDate: Wed Nov 6 00:44:28 2013 +0200 It seems a fair bet that this is a result of one of the below commits. Adding Cc: to caolanm@redhat.com; Any chance you could take a look at this? Thanks commit 2e5167528f7566dd9b000e50fc1610b7bf99132a Author: Armin Le Grand <alg@apache.org> AuthorDate: Thu Oct 31 14:43:21 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Nov 5 15:24:18 2013 +0000 Resolves: #i123500# unified Graphic processing to use GraphicPrimitive2D commit 36f21914b31a28f75ec2195c266424a18408f747 Author: Armin Le Grand <alg@apache.org> AuthorDate: Tue Oct 29 17:40:43 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Nov 5 12:37:15 2013 +0000 Resolves: i123564 corrected some aspects when working with bitmaps...
On pc Debian x86-64 with master sources updated yesterday (future 5.0.0), I could reproduce this. I noticed that not only if I put crop top and bottom value to 0, the second image appeared but also that if I put back crop top and bottom back to their initial value, the image still displayed.
in 4.4.4 and 5.0.0.2 the problem still persist
Miklos: rethinking about all this and since, as indicated in comment 15, putting at 0 and putting at initial values again, we can't reproduce this, I'd say WFM here. Indeed it seems the bug has been fixed but we can't fix an already wrong file generated by a previous LO version. What do you think?
For reference, I checked and it was indeed this commit at which the image first becomes invisible: commit 2e5167528f7566dd9b000e50fc1610b7bf99132a Author: Armin Le Grand <alg@apache.org> AuthorDate: Thu Oct 31 14:43:21 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Nov 5 15:24:18 2013 +0000 Resolves: #i123500# unified Graphic processing to use GraphicPrimitive2D
Dear all, I don't understand correctly your "technical language" about this bug which affects a lot of my docs. At this moment I cannot upgrade to newest release than 4.1.6.2. This question is just to ask if it's foreseen that the bug will be solved or it's best for me to find a different solution? Thank you everybody for your precious work. Gianni
Taking a look. This is strange, when I check the crop values used internally it shows that const SwCropGrf& rCrop = rSet.GetCropGrf(); in SwGrfNode::GetGraphicAttr gets crop values of nLeft 0 long nRight 0 long nTop 65468 long nBottom 0 long which makes clear why the graphic is not shown - it gets completely cropped away. Checking the content.xml of the test file shows that the 2nd graphic with style draw:style-name="fr1" indeed has set a fo:clip="rect(115.478cm, 0cm, 0cm, 0cm)", so this is imported correctly (also checked SvxGrfCrop::PutValue which is used at import time). Thus, the crop values used for paint are the ones from the file. The strange thing is that in the UI using 'format/image' in the context menu shows in its crop tab indeed other values - where do these come from and where are these in the odf file? They *should* be stored in fo:clip, but seems not to be. Looking deeper...
Tried to reproduce the problem stating with a new writer doc. Using positive values works (some and all), using negative for all works, using negative values for top and bottom (like in the example) works. Could not find a non-working case yet. Tried with new writer doc with the orig test graphic and orig negative valoes, works without problem, too. How was the test file created? Maybe it is just corrupted in some way. Looked in the original test file, could not find any place where the values '-0.349cm' or '-0' are used in any of the contained XMLs (that is used when creating new with orig graphic and values). So it is unclkear where those values come from. Checking this...
It happens in the dialog (SvxGrfCropPage) itself; the correct read value (large nTop) is set at initialization. Then the dialog executes SvxGrfCropPage::GraphicHasChanged where the crop values are adjusted when they seem unplausible (// if the margin is too big, it is set to 1/3 on both pages). Thus all is working as expected, sorry to tell you that for unknown reasons your files got corrupted. If you can reproduce how that corruption might have happened, I would be very happy. Please edit/adapt your files as needed by setting the needed values once. Opening the dialog, let it adapt the values to the shown ones and pressing OK does not change the crop values. This is debatable, but since the change was not user-initiated I think that is okay.
Btw: Not sure about the bibisect, checked the changes and before the same crop definitions were used, so very probable that the display was the same as now since these values are wrong in the ODF already. The identified change did no changes to im/export or modifications of the clip values, only using these in paint.
To be safe I have removed the patch in question temporarily. The graphic is painted indeed, but just because the crop validation in GraphicObject::ImplGetCropParams checks for nTotalHeight > 0. This is negative here, so returns false and this leads to paint the graphic without cropping at all. This was in principle an error - the decision that nothing stays visible was misused as decision to not crop. It should have lead to not painting the graphic.
(In reply to Armin Le Grand from comment #22) > Thus all is working as expected, sorry to tell you that for unknown reasons > your files got corrupted. If you can reproduce how that corruption might > have happened, I would be very happy. Please edit/adapt your files as needed > by setting the needed values once. > Needinfo from gioni - we'd need a reproducible description how to reach the messed-up state please.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
(In reply to Thorsten Behrens from comment #25) > (In reply to Armin Le Grand from comment #22) > > Thus all is working as expected, sorry to tell you that for unknown reasons > > your files got corrupted. If you can reproduce how that corruption might > > have happened, I would be very happy. Please edit/adapt your files as needed > > by setting the needed values once. > > > Needinfo from gioni - we'd need a reproducible description how to > reach the messed-up state please. Hello Thorsten, sorry for my delay! At first, happy new year. History of the messed-up: the first doc with cropped image was created with openoffice... maybe at least 10-12 years ago... In 2011 I begun to use libreoffice and all docs previously created with openoffce were opened correctly and until 4.1.6.2 all worked right! After this... the problem.
Created attachment 121728 [details] doc created with openoffice in 2007
Document was provided, setting to now (will check later).
Adding Cc: to Armin Le Grand
Armin, is comment 27 of any help? I'd assume if some really old OpenOffice version (or even a LibreOffice version) could create corrupted documents, not much can be done about it now, can it? Gioni, in the meantime, you can do the following with the documents in a current LibreOffice version. Right click on the placeholders for the images, save the images (it'll save the proper image files), delete them from the document, then insert them again, and they'll be inserted correctly. It's tedious, I know, but I hope it's of some help. Sorry for the inconvenience.
@Aron: Yes, it explains how it came to this. Still, that the graphic is now cropped, is a correct interpretation of the values in the safed file. The error was in the old versions. Still I can see that people do not want changed behaviour, but in this case it should be rare and I would opt for better keeping the fix and the correct cropping. It should be corrected for this one file by editing.
ok, so lets take it as an unfortunate isolated sideeffect of an overall desirable change, and wont fix then
(In reply to Aron Budea from comment #31) > Armin, is comment 27 of any help? I'd assume if some really old OpenOffice > version (or even a LibreOffice version) could create corrupted documents, > not much can be done about it now, can it? > > Gioni, in the meantime, you can do the following with the documents in a > current LibreOffice version. Right click on the placeholders for the images, > save the images (it'll save the proper image files), delete them from the > document, then insert them again, and they'll be inserted correctly. > It's tedious, I know, but I hope it's of some help. Sorry for the > inconvenience. Thank you Aron for suggestion. I apply this trick since a long time. But I have a lot of files (tecnichal sheet, forms) since 10 years ago and periodically I have to print one of them... It's really tedious. Believe me, some times I'm asking to myself "for what purpose I'm continuing to use Lb.?!? bye.
(In reply to Armin Le Grand (CIB) from comment #32) > @Aron: Yes, it explains how it came to this. Still, that the graphic is now > cropped, is a correct interpretation of the values in the safed file. The > error was in the old versions. Still I can see that people do not want > changed behaviour, but in this case it should be rare and I would opt for > better keeping the fix and the correct cropping. It should be corrected for > this one file by editing. Hello Le Grand, sorry but I didn't understand your interpretation. Can you better explain?
Hi gioni, please read the comments 21 .. 24, these contain all details. Sorry for your old files, but the error was wrong handling in visualizing, the negative crops were always saved/loaded. These are used now