Bug 61789 - PDF: Error in exporting vector graphics to PDF
Summary: PDF: Error in exporting vector graphics to PDF
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: BSA bibisected40 target:4.1.0 target:...
Keywords: regression
: 60702 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-04 13:31 UTC by yakutza
Modified: 2015-12-22 01:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
SVM Export from Origin (16.78 KB, image/x-svm)
2013-03-04 13:33 UTC, yakutza
Details
One line imported from Origin directly via clipboard (8.01 KB, application/vnd.oasis.opendocument.graphics)
2013-03-14 13:48 UTC, yakutza
Details
prototype patch ... (2.90 KB, text/plain)
2013-03-25 17:12 UTC, Michael Meeks
Details
test file (14.29 KB, application/vnd.oasis.opendocument.graphics)
2013-03-25 21:51 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yakutza 2013-03-04 13:31:52 UTC
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
Comment 1 yakutza 2013-03-04 13:33:22 UTC
Created attachment 75893 [details]
SVM Export from Origin
Comment 2 Joel Madero 2013-03-04 16:22:40 UTC
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
Comment 3 Joel Madero 2013-03-04 17:01:16 UTC
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
Comment 4 Michael Meeks 2013-03-13 11:33:47 UTC
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 ?
Comment 5 yakutza 2013-03-14 13:48:50 UTC
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.
Comment 6 Michael Meeks 2013-03-14 16:57:35 UTC
Nice test file - thanks for that - the line width is very noticeably wider - which is annoying I can see.
Comment 7 Michael Meeks 2013-03-14 16:59:53 UTC
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.
Comment 8 Thorsten Behrens (CIB) 2013-03-14 17:51:38 UTC
(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.
Comment 9 Michael Meeks 2013-03-15 09:46:28 UTC
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
Comment 10 Michael Meeks 2013-03-15 10:08:26 UTC
The zero ref-count on the line attribute (according to gdb) is a little concerning; digging there ...
Comment 11 Michael Meeks 2013-03-15 10:10:03 UTC
except of course it turns out that LineAttributes use '0' to count with - meaning one reference [ in defiance of sanity etc. ;-] wow.
Comment 12 Thorsten Behrens (CIB) 2013-03-15 10:12:41 UTC
(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.
Comment 13 Michael Meeks 2013-03-22 20:42:10 UTC
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.
Comment 14 Michael Meeks 2013-03-22 20:44:25 UTC
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 ...
Comment 15 Michael Meeks 2013-03-22 21:33:33 UTC
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 ...
Comment 16 Michael Meeks 2013-03-25 17:12:58 UTC
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 ...
Comment 17 Commit Notification 2013-03-25 21:42:12 UTC
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.
Comment 18 Commit Notification 2013-03-25 21:42:32 UTC
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.
Comment 19 Michael Meeks 2013-03-25 21:50:51 UTC
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.
Comment 20 Michael Meeks 2013-03-25 21:51:06 UTC
Created attachment 77022 [details]
test file
Comment 22 Commit Notification 2013-03-27 18:51:59 UTC
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.
Comment 23 Michael Stahl (CIB) 2013-03-27 18:52:47 UTC
*** Bug 60702 has been marked as a duplicate of this bug. ***
Comment 24 Commit Notification 2013-03-28 09:44:32 UTC
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.
Comment 25 Commit Notification 2013-03-28 09:56:22 UTC
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.
Comment 26 ign_christian 2013-06-18 07:48:03 UTC
I can confirm fixed with LO 4.0.4.2 (Win7 32bit)
Comment 27 Robinson Tryon (qubit) 2015-12-22 01:31:36 UTC
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]