I wanted to replace an image with another one and this is what happened: 1. On making a right click on the existing image (dimension of 200 px x 258 px) and choosing "Format Image..." in the register "Type" the size is 5.42 cm for the width and 7.00 cm for the height. The image was also saved by keeping the aspect ratio but this is not shown because of bug #98413. 2. On changing to the register "Image" and selecting another file (an image with a dimension of 166 px x 250 px), changing back to the register "Type", clicking "Original Size", selecting "Keep ratio" and changing the height back to 7.00 cm the width is shown as 5.43 cm. 3. On cliking "OK" the image looks distorted and on making a right click on the image and selecting "Format Image..." the width is shown as 5.42 cm. Expected results: - At 3. I would expect to see the saved value (5.43 cm) for the width and not 5.42 cm. - At 2. I would expect to see a width of 4.65 cm instead of 5.43 cm. For the last point changing the image does change the preview but it looks like that there are still references to the attributes of the old image.
Also if I'm replacing the image on the filesystem and trying to adjust the image by clicking "Original Size", selecting "Keep ratio" and setting the height to the same of the previous linked image it seems that the changes are not even applied.
Could not repro. After replacing with another image and clicking "Original size", the width is changed. You did not mention, if you had resized the image before step 1. I did not resize. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha0+ Build ID: 4bf2b6b2e6641c82e2b714e394482f1a1620b436 CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on March 21st 2016
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170502
(In reply to Buovjaga from comment #2) > You did not mention, if you had resized the image before step 1. I did not > resize. I don't remember but I think for Writer's view the image was on its original size. On trying to reproduce this with Calc 5.3.1.2 and creating an image with a dimension of 200px x 258px and inserting it it has now a width of 5.77cm and a height of 7.45cm instead of the 5.42cm x 7.00cm as at the time I have reported this issue. However, on going into "Properties..." from the image context menu and replacing the image on the "Image" register with one that has a dimension of 166px x 250px and changing back to the "Type" register the width and height is still 5.77cm x 7.45cm and clicking on "Original Size" doesn't change these values which seems now to be an incorrect behavior. If I try to workaround this issue by pressing "OK" first after replacing the image and reopening "Properties..." from the context menu of the image again and then going to the "Type" register, clicking "Original Size", "Keep ratio" and then changing back the height to 7.45cm again the width is shown as 4.95cm (sometimes even as 4.94cm so there seems to be still a bug here) and on pressing OK the image looks still distorted while it shouldn't and on going to "Properties..." from the image context menu again the width is now shown as 5.77cm. As this post shows there are several bugs on this task and maybe they should be just split into its own tickets. If I'm now not totally wrong the only partially fixed thing is now: >- At 2. I would expect to see a width of 4.65 cm instead of 5.43 cm. in case it is not a consequence of the workaround because I saw now the lower width but it seems it was now just not correctly applied to the image on clicking "OK".
(In reply to sworddragon2 from comment #4) > On trying to reproduce this with Calc 5.3.1.2 and creating an image with a > dimension of 200px x 258px Please create an example document at the point of this step.
I think it is better to give then instructions how to create such a document if this is unclear: 1. Create an image with a dimension of 200px x 258px with an image editor of your choice (in this case I have created it with GIMP and given it a black background). 2. Open Writer and go to the menu bar -> Insert -> Image... and select and open the created image.
(In reply to sworddragon2 from comment #6) > I think it is better to give then instructions how to create such a document > if this is unclear: > > 1. Create an image with a dimension of 200px x 258px with an image editor of > your choice (in this case I have created it with GIMP and given it a black > background). > 2. Open Writer and go to the menu bar -> Insert -> Image... and select and > open the created image. No, it's just quicker for testers, if you provide it.
Status NEEDINFO from comment #5 Set status to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
Due to the conclusion of comment #5, comment #6 and comment #7 I'm not providing this information since it is not needed to solve this issue. But of course - due to the nature of the requested information - anybody else who feels so can also provide it.
Created attachment 136135 [details] Calc document to test (In reply to sworddragon2 from comment #4) > On trying to reproduce this with Calc 5.3.1.2 and creating an image with a > dimension of 200px x 258px and inserting it it has now a width of 5.77cm and > a height of 7.45cm instead of the 5.42cm x 7.00cm as at the time I have > reported this issue. However, on going into "Properties..." from the image > context menu and replacing the image on the "Image" register with one that > has a dimension of 166px x 250px and changing back to the "Type" register > the width and height is still 5.77cm x 7.45cm and clicking on "Original > Size" doesn't change these values which seems now to be an incorrect > behavior. If I replace the rectangle in this document with a random image, Original size works just fine. Please re-test and hopefully this report can be closed. Btw. it's not very useful to refuse to provide a test document as we are all workers here. The width and height assigned to the rectangle in my document do not match the values you mentioned.. Not that it matters, but we don't know the PPI value you used in GIMP. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: a27eb931c22313d4dd5c73b35358c0532d20b79e CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on September 8th 2017
(In reply to Buovjaga from comment #10) > Btw. it's not very useful to refuse to provide a test document as we are all > workers here. Nah, it shouldn't matter who would have been provided the testcase (if anybody) as the total amount of work would be the same. And since my todo-list is basically exploding I have to schedule things more carefully. The alternative would have been to not react at the request at all but I don't think that would be better. I'm retesting this issue once LibreOffice 6 is in the Ubuntu repository. Not unlikely I will forget it until this time but the ~yearly bot would then remind me.
(In reply to sworddragon2 from comment #11) > (In reply to Buovjaga from comment #10) > > Btw. it's not very useful to refuse to provide a test document as we are all > > workers here. > > Nah, it shouldn't matter who would have been provided the testcase (if > anybody) as the total amount of work would be the same. And since my > todo-list is basically exploding I have to schedule things more carefully. > The alternative would have been to not react at the request at all but I > don't think that would be better. > > I'm retesting this issue once LibreOffice 6 is in the Ubuntu repository. Not > unlikely I will forget it until this time but the ~yearly bot would then > remind me. You can test it right now on 5.4 or master using AppImages: http://libreoffice.soluzioniopen.com/ The burden of providing a test case is by default on the bug reporter. Ignoring the ethical question of dividing work fairly, a crucial thing is that there might be some detail that only becomes apparent when the reporter does it. I could have in fact closed the report upon your refusal. It does not make sense to bring your unrelated-to-LibreOffice todo list into the discussion.
(In reply to sworddragon2 from comment #11) > (In reply to Buovjaga from comment #10) > > Btw. it's not very useful to refuse to provide a test document as we are all > > workers here. > > Nah, it shouldn't matter who would have been provided the testcase (if > anybody) as the total amount of work would be the same. And since my > todo-list is basically exploding I have to schedule things more carefully. > The alternative would have been to not react at the request at all but I > don't think that would be better. Ok, closing as NOTSUFFICIENTDATA. Best regards. JBF
I believe things are heavily being misunderstood here. The post that I'm very busy and thus not providing optional information which could be provided by anyone able to reproduce the STR was meant as a help to let nobody in the dark. Comment #12 sounds a bit offending but I did not intend to post just for it and instead continue as planned by doing a retest at some point in the future and then providing the results. But comment #13 sounds very offending (probably a short circuit reaction) especially since the requested information was already provided in comment #10 and thus closing this ticket as INSUFFICIENTDATA makes no sense.
It's true that closing this was a mistake. However, it is you who is offending people here. I've seen much worse on this tracker, though..
(In reply to Buovjaga from comment #15) > However, it is you who is > offending people here. I don't think this is true and it seems something is still unclear in this ticket - feel free to point me to what I'm missing here.
(In reply to sworddragon2 from comment #16) > (In reply to Buovjaga from comment #15) > > However, it is you who is > > offending people here. > > I don't think this is true and it seems something is still unclear in this > ticket - feel free to point me to what I'm missing here. When QA asks you to provide something, you do it. The fact that you left the construction of the test case to me is unbelievable in this context, where we are volunteers and peers.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20180404
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20180502