Created attachment 50617 [details] Minimal file to produce the bug. Two layers, one transparent. Detailed description with example file and confirmation this is occurring to others here: http://nabble.documentfoundation.org/Libre-Office-Draw-Printing-Incorrectly-td3280018.html#a3289372 Printing a drawing with two bitmap filled layers works correctly. Change one layer to transparent (1% to 99% inclusive) and the bezier curves turn to points resulting in a "jaggy" printout. I.e. it is retaining the bezier points but not rendering the curves. Confirmed on HP and Samsung laser printers in Windows 7 (Samsung printer)and Windows XP professional Service pack 3 (HP5550 printers). Exports to PDF and prints correctly under windows. In the thread linked above, one person reported the same "jaggy" problem exporting to PDF's under Linux. The same drawing displays correctly AND prints correctly in Openoffice 3.2 (so this bug was introduced since the fork) on the same computers. Repeated with other drawings-- this was the minimal case to reproduce the bug.
Created attachment 50640 [details] This is a more complex document where the bug is very noticable. Displays perfectly- printout is mangled badly.
This problem still exists on 3.4.3. I am also having problems printing I posted the following in Nabble. http://nabble.documentfoundation.org/Libre-Draw-Print-Problem-td3488558.html "It appears that Libreoffice 3.4.3 draw has some serious bugs in printing out, this problem is not in Openoffice 3.3 draw. It happens on prints to a Canon Pixma. Samsung laser & to the XPS printer. This is what we get when we print. http://users.spin.net.au/~boostlinux/Print%20out.jpg This is what Openoffice prints. http://users.spin.net.au/~boostlinux/Print%20out%20OO.jpg
It also exists on the 3.4.4 Rc2
It seems to print ok on LO 3.3.4, Linux.
That is to say the more complex attachment 50640 [details] prints fine.
It also works on 3.3.4 on Windows 7 x64 for the more complex document here and my file.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Also occurs with: LOdev 3.5.0beta3 Build ID: e40af8c-10029e3-615e522-88673a2-727f724 linux.
Created attachment 55559 [details] pdf file of attachment 50617 [details] printed to cups-pdf from LOdev 3.5.0beta3
Created attachment 55560 [details] pdf file of attachment 50617 [details] printed to cups-pdf from LO 3.3.4
thanks for testing. in fact (leaving out all emotions) a bug that is present introducedin the late OOo-dev 3.4.0 DEV300m105 (build 9581) too.
This bug is still present in the 3.5.1 rc1 More complex document still fails to print correctly
In think is is an issue of the PDF print driver being selected. For example, the 50617 prints perfectly fine in: LO 3.3.4 ApacheOpenOffice 3.4.0 (*if* the PS driver is selected)[1] ApacheOpenOffice OOo-dev 3.4.0 (*if* the PS driver is selected)[1] LO 3.5.5.1 _partially_ gets the print correct - *if* the PS driver is selected. Howevever if the default 'PDF' driver is used[2], the print output is as the previous LO 3.4.x examples. All tests are from standard LO files (i.e., no linux distribution versions were tested or harmed for these tests). [1] For my tests I used a cups-pdf virtual printer (linux), but could have easily used an Epson Workforce printer as well. To select: File|Print|cups-pdf:Properties|Device|Postscript Level:PostScript (Level from driver). [2] File|Print|cups-pdf:Properties|Device|Postscript Level: PDF (default in LO 3.4.x, LO 3.5.x., AOO3.4.0, OOo-dev3.4.0. Note that LO 3.3.x defaults as "from driver".
Exporting to PDF gives the correct output. Printing to Windows 7 XPS printer and to a Samsung SCX-5637FR printer (3.11.34.00.23 driver) as well as to a Samsung ML-2010 (2.02.05.00.24 universal driver) give the same result of a corrupted print out. Tested on Windows 7 x64
Still broken in 3.4.6 RC1 and 3.5.1 RC2
[Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit). Print via FreePDF looks identical to printout Samsung CLS-3185FN, bitmap filling will not follow bezier shape outline, but looks angular. Results are worrying. I created a more simple test doument "stonetest_ab.odg" with some variants of the shape with bitmap and color background with and without tranparency. That seemed to confirm that the problem is limited to transparent bitmap background (but see screenshot fro print preview!) But "stonetest_b.odg" shows the problem also in printout for bitmap background without transparency For details please see test kit with sources and results. Might be related "Bug 43318 - PRINTING standard shapes with bitmap area: filling exceeds shape area (regression since 3.3.4)" Looked ok with 3.3.0. first observation with 3.4.1RC1 (oder 3.4 versions currently not available), seems that that started with 3.4.0
Created attachment 58657 [details] Test Kit See comment 16
Created attachment 58658 [details] Test Kit 2 Most ugly result reproducible with a simple smiley and bitmap result.
Created attachment 58702 [details] Test Kit 2 print pdf from LO 3.3.4 Prints fine in: LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.4.1 (linux) Fails in LO 3.4 and above. This is regression between 3.3 and 3.4.
Still broken in the 3.5.3rc1
This bug is still not fixed in the 3.6.0.1 release.
This bug is still present in the 3.6 stable release.
Still not fixed in the 4.0 Beta1 Has this been forgotten?
Worked fine with Server Installation of "LibreOffice 3.3.3 German UI/Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit), so Regreession AOOo 3.4.1 does the job without a murmur I nominate this one as HardHack on <http://wiki.documentfoundation.org/HardHacks> and shift it to 4.0mab, because lifecycle of 3.5 is terminated
*** This bug has been marked as a duplicate of bug 43318 ***
oops, sorry...
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5b58f8e82dcf25426088ff2deb555d043c37e3e Fix fdo#40421 Take current clip into account for shape bounds. 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.
Bit hard to reproduce here - but TestKit2's ownsamplewithsmiley.odg shows the problem here. Fixed in master.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a10bc9322dd234549a4d061f77df038d89fb5c2a&h=libreoffice-4-0 Fix fdo#40421 Take current clip into account for shape bounds. It will be available in LibreOffice 4.0.4. 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.
Created attachment 80843 [details] Printed attached file on comment 1 It seems still occur. I attached print result (using PDFcreator) from file attached on comment 1. LO 4.0.4.2 (Win7 32bit)