Created attachment 123166 [details] source image for gallery The preview does not work in the newly created gallery. For the galleries created with LibreOffice older versions, the preview works fine. This feature worked from OpenOffice-1.0 to LibreOffice-4.3. This is a very critical regression. The view shown in gallery_preview_errors.png and old_gallery_preview.png files. Reproduce: Open gallery_preview_errors.odg file. Create new gallery. To put the image from the sheet in a new gallery.
Created attachment 123167 [details] bad preview
Created attachment 123168 [details] good preview for old gallery
Is the problem also in 5.1.1? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
>Is the problem also in 5.1.1? Yes. This problem exists in LibreOffice-5.1.1.3-3 too.
I reproduce. For reproducers (I never remember the workflow): https://help.libreoffice.org/Common/Adding_Graphics_to_the_Gallery The bug is not in 5.0 alpha0 (50max bibisect repo latest). I don't know of a 51max bibisect repo, so unable to bibisect. 64-bit, KDE Plasma 5 Build ID: 5.1.1.3 Arch Linux build-2 CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha0+ Build ID: 96c1ae1d8e78ae8b9bd7d4001645cad24d62b720 CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on March 25th 2016
I'm not reproducing this on any version I try - exact reproducible steps would be really nice. Here's what I'm doing: 1) open draw; 2) View -> Clip Art Gallery 3) New Theme... (in sidebar) 4) Push Ok +New theme created 5) open nemo file browswer; 6) drag a png from nemo to the gallery Observed: I see a preview without an issue (will attach) What am I missing?
Created attachment 124140 [details] Preview Visible
(In reply to Joel Madero from comment #6) > What am I missing? You have to use attachment 123166 [details], the image included in it. Use the procedure described in https://help.libreoffice.org/Common/Adding_Graphics_to_the_Gallery
(In reply to Joel Madero from comment #6) > 6) drag a png from nemo to the gallery This problem exists with native vector objects Draw. Not with png or other raster images. For technical drawing and circuit diagram the raster images is absolutely unusable. In addition to the description: this bug occurs, if the group object includes one or more simple lines.
(In reply to spectre9009 from comment #9) > (In reply to Joel Madero from comment #6) > > 6) drag a png from nemo to the gallery > > This problem exists with native vector objects Draw. Not with png or other > raster images. > For technical drawing and circuit diagram the raster images is absolutely > unusable. > There's no need for you to keep saying how it's such a serious bug for the corner case users like yourself - that's not going to get the bug fixed. If you're using LibreOffice in a professional setting then I suggest professional support contract with a certified developer. That's how you get your pet bugs fixed on your schedule. Else, realistically it could be some time (a long time) before this is resolved. If I can bibisect it that might help move your pet bug forward but first I need to confirm it's a regression. Just tested on 3.3 and it had different but still wrong behavior.
Bodhi Linux Version: 5.2.0.0.alpha0+ Build ID: ef34535ceb60d7d63b8d8671e4c6e9e43ffbd17d CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-03-27_09:53:05 Locale: en-US (en_US.UTF-8) On this version I can no longer drag the image at all into the gallery. So to summarize: 5.0.2.2: Confirmed 5.2 (from 2-3 weeks ago): Confirmed 5.2 daily (today): Can no long drag 3.3: Cannot drag image into the gallery With this I'm asking the original reporter to clarify: 1) Did this ever work EXACTLY as the wiki describes to do it; 2) If so - what version? 3) Can you test daily and confirm the new bad behavior? http://dev-builds.libreoffice.org/daily/ Marking as NEEDINFO - once clarification has happened please set back to NEW. Thanks
It would also be really nice if you installed something like 3.3 to really confirm that it worked then. Please give us exact reproducible steps - you can read the wiki provided by Buovjaga and carefully compare what you're doing to what the wiki says to do (again, using 3.3, or maybe 4.0 would work). I just want to get 100% confirmation that this is a known regression using precisely identical steps. http://downloadarchive.documentfoundation.org/libreoffice/old/
(In reply to Joel Madero from comment #11) > With this I'm asking the original reporter to clarify: > 1) Did this ever work EXACTLY as the wiki describes to do it; > 2) If so - what version? I often use this feature, so I can say that it works exactly as the wiki describes in 4.3.7.2-2 and ALL older versions (this is the default behavior). 4.3.7.2-2 is the latest version of the preview is good (it works exactly). Works exactly for 3.3 too. Probably you are unable to move the image to the gallery by moving the cursor at step 4 of the wiki. At step 4 of the wiki do not move the cursor until it changes to copying form. Only then will you be able to drag the image to the gallery. > 3) Can you test daily and confirm the new bad behavior? > http://dev-builds.libreoffice.org/daily/ Yes I can check for daily (a little later).
Now I'm baffled. The problem is seen on Ubuntu 16.04 Version: 5.1.2.2 Build ID: 1:5.1.2-0ubuntu1 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: en-US (en_US.UTF-8) But when I try to bibisect in said Ubuntu: Works in: Version: 5.0.0.0.alpha1+ Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86 Locale: en-US (en_US.UTF-8 Version: 4.5.0.0.alpha0+ Build ID: 2851ce5afd0f37764cbbc2c2a9a63c7adc844311 Locale: en_US Version: 4.4.0.0.alpha2+ Build ID: 3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 Locale: en_US Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Dragging doesn't work AT ALL: Version: 5.1.0.0.alpha1+ Build ID: dad6be8af0e670a56d3d399a1b0a35859bd7b093 Locale: en-US (en_US.UTF-8) From July 2015 up to the last commit in git://dev-downloads.libreoffice.org/lo-linux-dbgutil-daily-till51.git Works ok in build from 2015-06-18 and the oldest build in it. So either drag and drop doesn't work at all OR the preview is fine. I can't see the broken preview in the bibisect repos.
I'm in the same position - this isn't bibisectable....as to why....who knows. Marking as such. @spectre: One thing you can do is to try to narrow it down a bit more to a pre-release (find out the exact pre-release version that introduced the issue). We ask users to do this for their own bugs (vs. bibisects which we do) because it's not hard, just install and uninstall versions until you find one that works and one that doesn't: http://downloadarchive.documentfoundation.org/libreoffice/old/ Change the version to the first version that this problem shows up in. After that, not much that can be done outside of waiting.
Summary: java-6.0-sun for 3.3.0-6; java-7.0-openjdk for other versions; install all versions without kde-integration; clear install for all versions (with delete profile). Gallery preview for native objects of Draw: 3.3.0-6 OK 4.2.8.2-2 OK 4.3.7.2-2 OK 4.4.0.1-1 OK 4.4.4.1.0-1 OK 4.4.5.2-2 OK 4.4.6.1-1 bad 4.4.6.2-2 bad 4.4.6.3-3 bad 4.4.7.2-2 bad 5.0.5.2-2 bad 5.1.1.3-3 bad 5.2.0.0.alpha0-1(1016-03-27) bad 5.2.0.0.alpha0-1(2016-04-09) bad For all these versions I have no problems with dragging. This other bug (if you have it). Then need to open another bug to the appropriate version. My platform is other: ALT Linux (rpm based) LXDE 32-bit GTK-2
Fantastic - I think we've done everything we can do. Now we wait and hope a developer finds it interesting enough to tackle. This might even be an easy hack so I'll request some additional input from developers.
This seems to have begun at the below commit. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks 4a101ce68b02931a5486f32d1eb7acddbd13268d is the first bad commit commit 4a101ce68b02931a5486f32d1eb7acddbd13268d Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Jul 29 15:44:27 2015 -0700 source d1046e7c3f66e5f3384ee1ef534ef28346702fc6 source d1046e7c3f66e5f3384ee1ef534ef28346702fc6 author Caolán McNamara <caolanm@redhat.com> 2015-07-15 09:10:25 (GMT) committer Caolán McNamara <caolanm@redhat.com> 2015-07-15 12:11:14 (GMT) commit d1046e7c3f66e5f3384ee1ef534ef28346702fc6 (patch) tree 489a30028d5895b286e4c610cf3794a433a4dc5a parent 536051f8862203e0e115a5394a6379acd83cc8fe (diff) Resolves: tdf#63955 clip 19km long line to some sane limit
Hmm, we want to clip these to some sane size relative to the host page to avoid the 19km impossible to sanely handle original case. I see that the default page isn't of 0 width/height (which was special cased) but of 10 width/height (which has no explanation mentioned)
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=93efd7ebbad293d3729b8ea4b9726aff498f607f Resolves: tdf#98366 paste document has 10x10 sized SdPages... It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b3b213ba00481375dcbeb0708066f625667e2ce&h=libreoffice-5-1 Resolves: tdf#98366 paste document has 10x10 sized SdPages... It will be available in 5.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=17c61cc64278c006b06f8b152d79073c0ef16993&h=libreoffice-5-0 Resolves: tdf#98366 paste document has 10x10 sized SdPages... It will be available in 5.0.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=141a31fa26d398491194249789bb35f0d52801d9&h=libreoffice-5-0-6 Resolves: tdf#98366 paste document has 10x10 sized SdPages... It will be available in 5.0.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 96418 has been marked as a duplicate of this bug. ***