The appearance of inserted OLE objects is (incorrectly) based on window size/shape and the document display within its window when last saved. When an OLE object is inserted, LO uses both the window dimensions and the document appearance relative to the window (zoom factor and scroll positions) of that OLE (as last saved) to determine the horizontal and vertical extents of what is shown. It then stretches and compresses the appearance to match. This is a bug because both of these attributes -- window dimensions and document appearance within the window -- change frequently. If the tiniest change has taken place in either of these within a linked OLE, when links are updated, the appearance changes. The user must then open the linked OLE file and try to figure out how to size the window and redo the display so that it appears correctly again. This is a back-and-forth process that many users never figure out (judging from forum posts). Even for those who understand how it works, this practice is maddening. The same applies when trying to do a direct (not linked) insertion of an OLE object. Its appearance within its own window must first be tweaked so that it appears correctly when inserted. FIX: The horizontal and vertical extents of what is displayed when an OLE object is inserted should be based on the content of the object itself, and never on anything as ephemeral as window size or placement within the window when it was last saved. REPRODUCE: Take a sample text document, for example, zoom 200% and save it. Open a spreadsheet and insert that text document as an OLE object. See that it is cut off. Now flip back to the text document, maximize its window and hit Save. Go back to the spreadsheet and update links. See the inserted OLE compress to the left. Play with the text document, resizing its window, zooming and scrolling. After each change, save it and go over to the spreadsheet to update links. See the craziness! POSSIBLY RELATED TO: Many have reported OLE bugs and at least some of these are related to this underlying bug, which is the root of the problem: https://bugs.documentfoundation.org/show_bug.cgi?id=51508 https://bugs.documentfoundation.org/show_bug.cgi?id=47243 https://bugs.documentfoundation.org/show_bug.cgi?id=34619 https://bugs.documentfoundation.org/show_bug.cgi?id=37152 https://bugs.documentfoundation.org/show_bug.cgi?id=44838 https://bugs.documentfoundation.org/show_bug.cgi?id=46364 https://bugs.documentfoundation.org/show_bug.cgi?id=47197 https://bugs.documentfoundation.org/show_bug.cgi?id=47773 https://bugs.documentfoundation.org/show_bug.cgi?id=51119 https://bugs.documentfoundation.org/show_bug.cgi?id=51334 https://bugs.documentfoundation.org/show_bug.cgi?id=57017 https://bugs.documentfoundation.org/show_bug.cgi?id=58323 https://bugs.documentfoundation.org/show_bug.cgi?id=60508
Sounds like a good summary, I'm setting to NEW. Raising priority a bit due to large number of related reports.
Thanks, @Buovjaga. Descriptions are not accessible once submitted so I make edits as follows: - Second paragraph, last sentence should read: "It then stretches and compresses the appearance to match, which nearly always distorts the OLE's appearance within the current file." - Under REPRODUCE, delete "for example," - The colon at end of last paragraph is replaced with a period. Developing the way inserted OLE appearance *should* work: a. It should be intuitive, to match the LO UI standard. The current scheme is a puzzle. b. The entire object should be inserted, then the appearance can be modified in the local document. c. For consistency, the OLE's anchor point can be at upper left corner, at least initially. Until fixed, this temporary workaround seems to produce the best results: 1. Open the file which is to be inserted as an OLE object and Zoom 75%, or a zoom factor that allows the document to be completely displayed within the window, and with the entire window visible on screen. 2. Drag a window corner to the pixel where both scroll bars just disappear. 3. Zoom entire page, then save. 4. Go to local document and insert the just-modified file as OLE. There should be no distortion.
** 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-20170901
Bug is still present. Just tested the latest Debian/Ubuntu(x64) release, 5.1.6.2, and find graphics still frozen like a stone while other data sorts normally. Nothing tried -- and pretty sure I've tried everything -- makes the graphics move with their rows when sorted. When a graphic is anchored to a cell, it's like the anchor passes through to anchor instead to the page. If that's what's happening, this could be a very easy bug to fix. Just need a developer to take a look.
Please disregard (and delete) my comment 4 -- wrong bug.
This bug is also still present. Tested latest Debian/Ubuntu(x64) release, 5.1.6.2. No difference from when first reported.
** 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 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
Dear u2nBz, 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://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
Dear u2nBz, 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
Bug still present. Version: 6.4.7.2 Build ID: 1:6.4.7-0ubuntu0.20.04.5 A twist is that when reproducing the bug, the Update button does nothing. However, the OLE object appearance is still dependent on the zoom and pan characteristics of the saved file, and expanding the window still stretches the object rather than showing a larger, undistorted view of it.
(In reply to u2nBz from comment #0) > REPRODUCE: > Take a sample text document, for example, zoom 200% and save it. Open a > spreadsheet and insert that text document as an OLE object. See that it is > cut off. > > Now flip back to the text document, maximize its window and hit Save. Go > back to the spreadsheet and update links. See the inserted OLE compress to > the left. I don't reproduce this with updating links (it does not update the view at all). If I right-click and edit, the switch away from edit mode. I can see the whole text (as expected after maximising and saving). As 6.4 is quite old, I recommend to test with a fresh version. You might try https://wiki.documentfoundation.org/Installing_in_parallel/Linux#Automated_installation Arch Linux 64-bit Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: f5c6ef40dd494f6984c6ed784fccc02806999836 CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 7 September 2022
(In reply to Buovjaga from comment #11) > (In reply to u2nBz from comment #0) > > REPRODUCE: > > Take a sample text document... > > I don't reproduce this with updating links (it does not update the view at > all). Yes, that's what I mentioned as the "twist." Earlier versions updated the display of the link based on saved changes to the link's file. > > As 6.4 is quite old, I recommend to test with a fresh version. You might try > https://wiki.documentfoundation.org/Installing_in_parallel/ > Linux#Automated_installation > This is a new install so I've not gotten around to bypassing the distro's repo. (It is the latest available there.) Will update and re-test.
Right, sorry. I do confirm that when entering edit mode after the maximising and saving of the source, the object area is not yet expanded, making the contents squished. However, this is only seen once.