Problem description: I imported a vector graphic from Origin (originlab.com) or over a svm file Example file: https://www.box.com/s/4x59yudb7e6b16fgm6fw Wenn I export it again, with or without changes, to PDF by the quicklink or by File --> Export. The linewidth in the created PDF file is incorrect. It occurs after the update to LO 4 (4.0.0.3 and 4.0.1.2.rc) (when the issue with the export to png was solved^^) In 3.6.4 befor everythin was fine with pdf Steps to reproduce: 1. Download the linked file 2. drag n drop it to draw 3. export it to pdf Current behavior: Expected behavior: Operating System: Windows 7 Version: 4.0.1.2 rc Last worked in: 3.6.4.3 release
Created attachment 75893 [details] SVM Export from Origin
Thank you for reporting this issue! I have been able to confirm the issue on: Version 4.1.0.0.alpha0+ (Build ID: 2bb13b83e40aec362964d26921a3fc1660a5da2) Date: Thu Feb 28 20:17:25 2013 +0100 Platform: Bodhi Linux 2.2 x64 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem I am marking as: New (confirmed) Normal (prevents high quality work when exporting to pdf) High (regression + not quality looking, no workaround) Version: Changing to 4.0.0.3 as version field reflects OLDEST version that we can confirm the issue, we use comments to say it still exists in newer version. I am currently bibisecting this bug, will have it up shortly + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage and join us on freenode at #libreoffice-qa There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
bibisect: 9a5620ca6473969359f262802c76daf35cbcbb5d is the first bad commit commit 9a5620ca6473969359f262802c76daf35cbcbb5d Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 01:59:31 2012 +0000 source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc commit ae4e4a11d4300f7448cb6bd170fcb034542caddc Author: Rene Engelhard <rene@debian.org> AuthorDate: Tue Nov 6 21:24:32 2012 +0100 Commit: Rene Engelhard <rene@debian.org> CommitDate: Tue Nov 6 21:24:32 2012 +0100 typo... Change-Id: I2c7968194afbcf74967cd16c639dce7de858a513 :100644 100644 c09b92a8ddf24b8738a7cd3a695ae1e4482d354c 6b13afd13f023cedac65a896318de4aa55dead27 M autogen.log :100644 100644 bcee1e11bd693642ca5a6330175b58082e5dcdd0 54d2377f5b3afd6ed668b3e24cb877c289119ec5 M ccache.log :100644 100644 75677cef16786d2cc95c0d8f301482278ca055c3 d18a6ebcd3b8537c3dd3dbc16e862fb6370ecb8a M commitmsg :100644 100644 83b4ecc0ecb3e031c804d49f45f854e95d5cc961 d482c00e5fff6081c6b87b637fd9ffaf3e1e2c6c M dev-install.log :100644 100644 91437b9974ffada7e049273419bb8c66c91c0539 abf45ab9609c77a5ab952aa310eafe8c2ffaf85c M make.log :040000 040000 45c0bab8b669778ab523c8f65a25e8c9afde604a f4bfa15b2f72d3df5675b07bcf32254a819b9d19 M opt # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262 # bad: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 git bisect bad 47498a36f7af8f54e6e3dda89cd4708802a409e6 # good: [f4e2d84db194943180f3e7ed4adce5f8e377d9bc] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good f4e2d84db194943180f3e7ed4adce5f8e377d9bc # bad: [fb4214f9d134b556582a4a5280e5458de5f8eebd] source-hash-683758efb22d08a4cf211a6d985148f513da2a90 git bisect bad fb4214f9d134b556582a4a5280e5458de5f8eebd # good: [e2e46267c18c2706de771a08472ebfce19f68520] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588 git bisect good e2e46267c18c2706de771a08472ebfce19f68520 # bad: [9a5620ca6473969359f262802c76daf35cbcbb5d] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc git bisect bad 9a5620ca6473969359f262802c76daf35cbcbb5d
In the range: git log --numstat 4316e643ef345b0f673b4a03a80a4b7cb3185588..ae4e4a11d4300f7448cb6bd170fcb034542caddc contains a rather significant set of re-basing commits. Could we get a simpler / smaller (preferably just one line) test case ?
Created attachment 76527 [details] One line imported from Origin directly via clipboard I attached an odg file with a single line imported directly from Origin via clipboard. I deleted all other lines of the graph in Origin before.
Nice test file - thanks for that - the line width is very noticeably wider - which is annoying I can see.
Hi Thorsten; if you could give me a code pointer for where an SVM like this would be rendered - I can try to peel it back :-) Thanks.
(In reply to comment #7) > Hi Thorsten; if you could give me a code pointer for where an SVM like this > would be rendered - I can try to peel it back :-) Thanks. > I would start from drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx:1631, the case PRIMITIVE2D_ID_METAFILEPRIMITIVE2D one - you should get the ~original metafile handed in there from the GraphicObject.
breaks in here: 1183 case PRIMITIVE2D_ID_POLYGONSTROKEPRIMITIVE2D : 1184 { 1185 const primitive2d::PolygonStrokePrimitive2D& rStrokePrimitive = static_cast< const primitive2d::PolygonStrokePrimitive2D& >(rCandidate); 1186 const basegfx::B2DPolygon& rBasePolygon = rStrokePrimitive.getB2DPolygon(); p *rStrokePrimitive.maLineAttribute.mpLineAttribute $6 = {mnRefCount = 0, maColor = {<basegfx::B3DTuple> = {mfX = 0, mfY = 0, mfZ = 0}, <No data fields>}, mfWidth = 176, meLineJoin = basegfx::B2DLINEJOIN_ROUND, meLineCap = com::sun::star::drawing::LineCap_BUTT} Forcing mfWidth to 1 at this stage yields the output I'd expect; so apparently the LineAttribute mfWidth is wrong by this stage. #0 drawinglayer::processor2d::VclMetafileProcessor2D::processBasePrimitive2D (this=0x9396800, rCandidate=...) at /data/opt/libreoffice/master/drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx:1186 #1 0xb6272dd4 in drawinglayer::processor2d::BaseProcessor2D::process (this=0x9396800, rSource=uno::Sequence of length 1 = {...}) at /data/opt/libreoffice/master/drawinglayer/source/processor2d/baseprocessor2d.cxx:64 #2 0xb628687c in drawinglayer::processor2d::VclProcessor2D::RenderTransformPrimitive2D (this=0x9396800, rTransformCandidate=...) at /data/opt/libreoffice/master/drawinglayer/source/processor2d/vclprocessor2d.cxx:1075 ... #10 0xb6272dd4 in drawinglayer::processor2d::BaseProcessor2D::process (this=0x9396800, rSource=uno::Sequence of length 3 = {...}) at /data/opt/libreoffice/master/drawinglayer/source/processor2d/baseprocessor2d.cxx:64 #11 0xaf24b2f4 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay (this=0x8f9e068, rDisplayInfo=...) at /data/opt/libreoffice/master/svx/source/sdr/contact/objectcontactofpageview.cxx:259 #12 0xaf24b49b in sdr::contact::ObjectContactOfPageView::ProcessDisplay (this=0x8f9e068, rDisplayInfo=...) at /data/opt/libreoffice/master/svx/source/sdr/contact/objectcontactofpageview.cxx:123 #13 0xaf26cbf2 in SdrPageWindow::RedrawAll (this=0x937dc78, pRedirector=0xbfffc41c) at /data/opt/libreoffice/master/svx/source/svdraw/sdrpagewindow.cxx:309 #14 0xaf319506 in SdrPageView::CompleteRedraw (this=0x93b7110, rPaintWindow=..., rReg=..., pRedirector=0xbfffc41c) at /data/opt/libreoffice/master/svx/source/svdraw/svdpagv.cxx:305
The zero ref-count on the line attribute (according to gdb) is a little concerning; digging there ...
except of course it turns out that LineAttributes use '0' to count with - meaning one reference [ in defiance of sanity etc. ;-] wow.
(In reply to comment #9) > breaks in here: > > 1183 case PRIMITIVE2D_ID_POLYGONSTROKEPRIMITIVE2D : > 1184 { > Eh - so we break up the metafile into primitives. Whereas before we rendered it ~directly. That seems to be the catch.
Wow this is annoying :-) I can't create an SVM like this that breaks LibreOffice 4.x's PDF export using either LibreOffice 4.x or 3.6. Apparently there is something rather unusual / unexpected about the SVM itself.
The problematic one-line SVM is: 00000000 56 43 4c 4d 54 46 02 00 32 00 00 00 01 00 00 00 |VCLMTF..2.......| 00000010 01 00 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 |................| 00000030 01 63 ce 01 00 3a 41 01 00 0e 00 00 00 01 8b 00 |.c...:A.........| 00000040 01 00 02 00 00 00 20 00 8d 00 01 00 02 00 00 00 |...... .........| 00000050 00 00 8b 00 01 00 02 00 00 00 20 00 8d 00 01 00 |.......... .....| 00000060 02 00 00 00 00 00 8c 00 01 00 00 00 00 00 8b 00 |................| 00000070 01 00 02 00 00 00 20 00 8d 00 01 00 02 00 00 00 |...... .........| 00000080 00 00 8c 00 01 00 00 00 00 00 8b 00 01 00 02 00 |................| 00000090 00 00 20 00 84 00 01 00 05 00 00 00 00 00 00 00 |.. .............| 000000a0 01 6d 00 03 00 31 00 00 00 02 00 20 9a 00 00 f7 |.m...1..... ....| 000000b0 94 00 00 df 4d 01 00 42 a8 00 00 03 00 18 00 00 |....M..B........| 000000c0 00 01 00 b0 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 04 00 00 8d 00 01 00 02 00 |................| 000000e0 00 00 00 00 8c 00 01 00 00 00 00 00 8c 00 01 00 |................| 000000f0 00 00 00 00 |....| 000000f4 Whereas LibreOffice 3.6 generates: 00000000 56 43 4c 4d 54 46 02 00 32 00 00 00 00 00 00 00 |VCLMTF..2.......| 00000010 01 00 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 |................| 00000030 00 56 54 00 00 24 6d 00 00 12 00 00 00 01 8b 00 |.VT..$m.........| 00000040 01 00 02 00 00 00 ff ff 89 00 01 00 21 00 00 00 |............!...| 00000050 01 00 1b 00 00 00 0d 00 b2 fb ff ff cb fb ff ff |................| 00000060 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 |................| 00000070 00 81 00 01 00 10 00 00 00 4e 04 00 00 35 04 00 |.........N...5..| 00000080 00 a3 58 00 00 58 71 00 00 8b 00 01 00 02 00 00 |..X..Xq.........| 00000090 00 20 00 82 00 01 00 21 00 00 00 02 00 1b 00 00 |. .....!........| 000000a0 00 02 00 02 00 00 00 00 00 00 00 23 6d 00 00 01 |...........#m...| 000000b0 00 00 00 00 00 55 54 00 00 02 00 00 95 00 01 00 |.....UT.........| 000000c0 04 00 00 00 00 00 00 00 96 00 01 00 02 00 00 00 |................| 000000d0 09 00 84 00 01 00 05 00 00 00 00 00 00 00 01 00 |................| 000000e0 02 01 00 6e 00 00 00 15 00 58 50 41 54 48 53 54 |...n.....XPATHST| 000000f0 52 4f 4b 45 5f 53 45 51 5f 42 45 47 49 4e 00 00 |ROKE_SEQ_BEGIN..| 00000100 00 00 4f 00 00 00 01 00 49 00 00 00 01 00 13 00 |..O.....I.......| 00000110 00 00 02 00 90 24 00 00 0b 19 00 00 5a 3f 00 00 |.....$......Z?..| 00000120 63 1e 00 00 00 01 00 02 00 00 00 00 00 01 00 02 |c...............| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 |................| 00000150 00 00 00 00 00 84 00 01 00 05 00 00 00 00 00 00 |................| 00000160 00 01 85 00 01 00 05 00 00 00 00 00 00 00 00 6d |...............m| 00000170 00 03 00 31 00 00 00 02 00 90 24 00 00 0c 19 00 |...1......$.....| 00000180 00 5a 3f 00 00 64 1e 00 00 03 00 18 00 00 00 01 |.Z?..d..........| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001a0 00 00 00 00 00 04 00 00 00 02 01 00 1d 00 00 00 |................| 000001b0 13 00 58 50 41 54 48 53 54 52 4f 4b 45 5f 53 45 |..XPATHSTROKE_SE| 000001c0 51 5f 45 4e 44 00 00 00 00 00 00 00 00 8c 00 01 |Q_END...........| 000001d0 00 00 00 00 00 8b 00 01 00 02 00 00 00 20 00 82 |............. ..| 000001e0 00 01 00 21 00 00 00 02 00 1b 00 00 00 02 00 02 |...!............| 000001f0 00 00 00 00 00 00 00 23 6d 00 00 01 00 00 00 00 |.......#m.......| 00000200 00 55 54 00 00 02 00 00 8c 00 01 00 00 00 00 00 |.UT.............| 00000210 8c 00 01 00 00 00 00 00 |........| 00000218 for a similar single-line SVM export. Hmm ...
re-exporting the embedded svm as an svm using file->export and then re-loading that corrects the issue - which is somewhat irritating :-) if you then export that SVM to PDF then all is well. In this case in the fixed svm the PolyLine is embedded inside a META_COMMENT_ACTION - which is what we see when it's exported (erroneously) to PDF as well. Most odd ...
Created attachment 77010 [details] prototype patch ... It appears that not transforming the width in the stroke as well as the LineInfo could be one potential cause of this; prototype patch attached. With it - we export to PDF nicely. Unfortunately, this breaks exporting to svm and re-importing; it's also unclear how beautiful any of this is for fat-lines ...
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=432b6ab482d6fcef05514ab17e4bc762ee552139 fdo#61789 - move metafile line width scaling somewhere more sensible. 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.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd335d180b1d549e884b9692ba1a4e51a014dcd5 fdo#61789 - improve SvtGraphicStroke / metafile scaling 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.
Thorsten - I'd love review of: https://gerrit.libreoffice.org/#/c/3044/ There are a few related fixes eg. http://cgit.freedesktop.org/libreoffice/core/commit/?id=501145f2e3c84d1b07930ea8f0a012060dbff48b http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd335d180b1d549e884b9692ba1a4e51a014dcd5 that may also help - at least for SVG export. I'll attach a useful test file too - any ideas on unit testing appreciated too I guess. Load -> export as SVG, re-load, and check line widths would be good - but of course the embedded SVM (which was the problem) has no easy way to check that.
Created attachment 77022 [details] test file
Related issues are: https://issues.apache.org/ooo/show_bug.cgi?id=101734 https://issues.apache.org/ooo/show_bug.cgi?id=113922
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f8ca5b1b95b92e9410df6037781680dcd35ff963&h=libreoffice-4-0 fdo#61789 - move metafile line width scaling somewhere more sensible. It will be available in LibreOffice 4.0.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.
*** Bug 60702 has been marked as a duplicate of this bug. ***
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=51f50a0dee2867b0f9e3f869e5fbe14923fcef3a fdo#61789 Fix crash, pSvtGraphicStroke is allowed to be NULL. 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.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=277ee3f0d1135158237698b88705d0cb1ec57c46&h=libreoffice-4-0 fdo#61789 Fix crash, pSvtGraphicStroke is allowed to be NULL. It will be available in LibreOffice 4.0.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.
I can confirm fixed with LO 4.0.4.2 (Win7 32bit)
Removing comma from Whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started [NinjaEdit]