Created attachment 51184 [details] doc with mis-printed slides I have a presentation created using 3.4.3 that contains graphics of various shapes, eg, polygons, ovals, etc. They looked fine when viewing in a browser and they looked fine in the little preview in the printer dialog box. However, for some of the slides in the presentation printed on my Epson 400SX, the polygons are printed as squares (but with the polygon border visible within) and the ovals are printed as polygons (again with the oval border visible within). I reinstalled LibreOffice 3.4.3, no joy. I uninstalled and installed 3.4.2, no joy. I uninstalled and installed 3.3.4, and they are now printed correctly. So, it seems there is some problem with the 3.4 series. See the attached document, originally created by my daughter. The polygons came from "Basic shapes" and the oval from "Ellipse". We also used "Flowcharts", though I can't remember if they print incorrectly too. When slide 5 is printed, some of the polygons are printed as rectangles and ovals as polygons, though the shape borders are correctly printed. There are also 2 extra shapes printed that I think (but cannot be sure) were never part of the slide: a slim rectangle and a large triangle. When slide 6 is printed, again some of the polygons are printed as rectangles and ovals as polygons, though the shape borders are correctly printed. I originally raised this on the LibreOffice Users mailing list, where NoOp helpfully managed to reproduce the problem with the attachment. See http://nabble.documentfoundation.org/Impress-3-4-prints-polygons-as-rectangles-and-ovals-as-polygons-td3329585.html
was OK in 3.3.x, according to test by Gary Schnabel
@Cor: Simon (marshals) also verified that it is OK in 3.3.4. The issue is 3.4.3. I tested with 3.4.3 and 3.3.4 on Win7; 3.4.3 failed, 3.3.4 worked. I only printed page 5 of Simons german_and_history_homework.odp from LO 3.4.3 Win7 to an Epson Workforce 635; the results were not pretty. I then exported as a PDF and that looked fine. So I then printed to PDFCreator and the results of that PDF look nearly the same as when printed to the printer. Screenshot of page 5 with PDFCreator is attached as: Screenshot-german_and_history_homeworkPDFCreator.pdf - Adobe Reader.png Note: I can attach the entire PDFCreator PDF file if requested. Scanned image of print (Win7 LO 3.4.3) is also attached as: germanprint.png I then completely uninstalled 3.4.3 installed 3.3.4 & page 5 prints just fine. Scanned print image is attached as: german334.png
Created attachment 51220 [details] Screenshot of printing to PDFCreator via 3.4.3
Created attachment 51221 [details] Scanned page 5 after printing via 3.4.3
Created attachment 51222 [details] Screenshot after printing page 5 via 3.3.4
[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
I'm away and I'll be back on Tue Jan 3. "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/corp/About_Us/misys_operating_companies.html. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.
(In reply to comment #6) > 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. Yes, I can confirm this exists in 3.5.0 beta2. I used a WinXP VM, and installed 3.4.4 to confirm I could reproduce the bug in that environment. The attached doc viewed ok in Impress, but when printed via Microsoft Document Image Writer to a tiff file, slides 5 and 6 were corrupted as described previously. I then uninstalled and installed 3.5.0 beta2 with the same results when printing the doc in the same way.
I can confirm this exists in 3.5.0 rc3.
I can confirm this exists in 3.5.0 release, this time verified with pages 5 and 6 using Win7 and printing via Microsoft XPS Document Writer. So the problem is reproducible with 2 different Epson printers and 2 different Microsoft printer writers.
setting to version 3.4 as this is the first release where the problem shows up
On Vista with 3.6.2.2 version, I made a test with pdfcreator and had same result of 3.3.4 so it seems ok. Could anybody give a try to 3.6.2? Even if the problem is reproduced with 3.5.7, there shouldn't be 3.5.8 (except if important fixes like crashes), so I don't know if it worths to test 3.5.7
I'm away and I'll be back on Mon Nov 5. "Misys" is the trade name of the Misys group of companies. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.
Created attachment 69652 [details] Slide 5 print to PDF from LO 3.6.2.2 Works for me in 3.6.2.2 linux and WindowsXP & Win7: Version 3.6.2.2 (Build ID: da8c1e6) See the attached PDF.
Created attachment 69653 [details] slide 5 from windows 3.6.2.2 to pdfcreator Apologies. I rechecked in Windows (both via PDFCreator and printing directly to an Epson Workforce printer), and the Windows version failed. Attached is the pdf from PDFCreator.
(In reply to comment #15) > Apologies. I rechecked in Windows (both via PDFCreator and printing directly > to an Epson Workforce printer), and the Windows version failed. Attached is > the pdf from PDFCreator. i can confirm the problem remains in lo-3.6.3.2/win7hp-64b with the attached doc and writing to Microsoft XPS Document Writer. for me, writing from lo to pdf is fine. btw, i see the status is NEEDINFO. what info would you like me to provide?
marshals: thank you for your feedback, i put it back to NEW.
I tested it in LO-4.0-beta1 on Ubuntu 12.04 x86_64. The problem doesn't exist here. Can somebody try against the 4.0-beta in Windows?
I'm away and I'll be back on Wed Jan 2. "Misys" is the trade name of the Misys group of companies. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.
(In reply to comment #18) > I tested it in LO-4.0-beta1 on Ubuntu 12.04 x86_64. The problem doesn't > exist here. Can somebody try against the 4.0-beta in Windows? I tried it in 4.0.0 beta 2, and I still have problems with slides 5 and 6. For the test, I used a Win7 32b VM, and printed to the Windows XPS printer. I've attached the output from both 3.5.4 and 4.0.0. Fwiw, slide 5 is differently wrong from the earlier versions: 3.6.4 gets the oval wrong; 4.0.0 gets the trapezoid wrong; both get the hexagon wrong.
Created attachment 72377 [details] all slides by 3.6.4 for comment 20
Created attachment 72378 [details] all slides by 4.0.0 for comment 20
More or less [Reproducible] with "LibO 4.0.0.2 rc - GERMAN UI / German Locale [Build ID: 5991f37846fc3763493029c4958b57282c2597e)]" {tinderbox: @6, pull time 2013-01-24 07:20(?)} on German WIN7 Home Premium (64bit) with User Profile automatically created form renamed /3 User profile used by 3.6.5.2. My results with slide 5 differ from "slide 5 from windows 3.6.2.2 to pdfcreator.pdf" in many details, but I can confirm the core of the observations: Background exceeds Shape contour. Most impressing printing damages with slide 6, there all backgrounds (except hatching) in printout (FreePDF) do not follow shape contour, but are shown as rectangles. That problem is not limited to Impress, also visible with shapes copied to DRAW That's already visible in Print preview in printing dialog. But strange, I do not see a problem with slide 5 "Why Learn German (the main reasons)?" I already similar bugs and I am pretty sure that this one is a bug or at least related, and also here some relations to other bugs are mentioned in various comments. We will have to sort that. I'm afraid we have too many similar and related, but not identical problems in the sample document, we will have to check for each shape (IMHO slides 5 and 6) what exactly the problem is, whether thee problem already has been reported, ... . For example: The main problem seems to star with 3.4. but NoOp also observed differences between Versions 3.6.2 and 3.6.4. For all new problems visible we should spin off a new bug with reference to the sample here, what will ease develpers' work (<http://wiki.documentfoundation.org/BugReport#General_information> item 4!) I will contribute some observations to Slide5 shape "For a holiday", soon
So back to UNCONFIRMED due to <https://wiki.documentfoundation.org/QA/BugTriage#Set_Status_.26_Prioritize>
Created attachment 73813 [details] Print Results for "For a holiday" My results with 4.0.0.2 rc (WIN) and print via FreePDF (same as laser printer) for "For a holiday" please see in attachment. a) Print only selected shape shows background as big rectangle, b) printing whole slide shows backround as a rather crazy shape, but only in that presentation, not when shape has been copied to a separate shape. I will do tests with other versions and check for DUPs for this shape
Background problem from comment before was not with 3.3.3 Selection print problem is visible with 3.4.5, but printing all slide there still is ok, this separate problem is ok until 3.6.5.2 and starts with 4.0. I will check for DUPs and leave comment concerning my results here. OT: lots of other elements on slide look different in every version i check, we will have to examine that carefully
i don't really follow why it's back to UNCONFIRMED - the label implies to me that, eg, nobody has confirmed (by reproducing it) that it is a valid bug - but i trust that was the correct thing to do. more importantly, is there anything you would like me to do? afaics, there are several attachments that demonstrate the bug(s), but if there's anything i can do to help, plz let me know.
@marshals: The reason for UNCONFIRMED is that the report is no "ready for fixing". It has been confirmed that problems exist, but there are many (similar but) different problems shown in the sample document. In accordance to developers' workflow we have to create separate reports for each detail problem, see Comment 24! So we will use this report with it's sample document as a stone pit to get material for separate reports for each detail problem. I will start with this work today in the evening or tomorrow and will leave some brief hints here how to do the same for other problems. Indeed with some coworking we will get this prepared much faster.
I submitted a separate "Bug 60091 - PRINTING all page of particular .odp shows extra rectangles with bitmap shape background" concerning a problem in 4.0.0.0 and Master printouts. Can someone please try to reproduce the "extra bitmap background rectangles" problem there? An other Problem visible in prints from doc with mis-printed slides: Printing Slide 5 from installation (own profile) of "LibreOffice 3.5.6.2 German UI/Locale [Build-ID: e0fbe70-5879838-a0745b0-0cd1158-638b327] on German WIN7 Home Premium (64bit) shows a big green rectangle below the Heading as you also can see in " Screenshot of printing to PDFCreator via 3.4.3". Can someone please submit a new bug (if problem is not yet reported) and narrow down the reasons and roots for that problem (when did that start / end, other conditions) as I did in Bug 60091?
"Bug 58482 - PDF Export: the all Bitmap background can be seen behind a shape when a transparency gradient is used on it" also seems related to this one. Can someone please narrow down roots, reasons, effects, difference Print / PDF, gradient and transparency Influence for that bug similar as I did in "Bug 60091"?
"Bug 40421 - PRINTING shapes with transparent(?) Bitmap background loses bezier curves" also seems to be related to these Bitmap Background problems @Björn: For what shape name did you do the bibisect? We have a bunch of different problems here, and with different OS / Versions and may be settings very different results might be shown.
@Rainer: No bibisect at all, just setting the version to the oldest version that other commenters found the bug in (and bibisect only starts at mid-3.5 unfortunately and there is little we can do about it)
FYI, committed fix for bug 40421 - unclear if this is related.
Created attachment 80864 [details] Results of PDFcreator I can confirm bug (on slide 5 & 6) still occur while printing using PDFcreator (see attached file). But 'Export as PDF' did the job well (correct). LO 4.0.4.2 (Win7 32bit)
As this bug has been confirmed several times - marking as NEW :) Especially last comment 34 which tested against 4.0.4 ign_christian - adding meta tracker for triage contest, it's yours though :)
Changing priority: Normal - can prevent high quality/professional work High - pretty general feature to print bitmaps, broken for both pdf & physical print so essentially no workaround
i can confirm the problem remains in lo-4.1.0.1/win7hp-32b with the attached doc and writing to Microsoft XPS Document Writer.
this is still a problem in 4.2 rc1 (win7ult-32b)
(In reply to comment #38) > this is still a problem in 4.2 rc1 (win7ult-32b) and for 4.2.0.4 (win7ult-32b)
Migrating Whiteboard tags to Keywords: (notBibisectable)
Removing [Task] from summary.
Checked with Win32 version (Version: 5.2.0.0.alpha0+ Build ID: 7dda56143f17f9b85bcc9630f2fad12b65541fc2 CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; Locale: de-DE (de_DE)) Print indeed makes problems on pages 5 and 6 where CustomShapes with tiled BitmapFill are used. PDF export works well, so there is a workaround for printing now. The printing problem seems to be related to the bitmaps not being correctly clipped, tried various variations of BitmapFill. Besides the TestDoc it is very simple to reproduce: - New Draw - Draw a shape (e.g. horizontal arrow) - open Format/Area... dialog - choose Bitmap fill, any bitmap (Droplets) - Okay, close - Print -> preview already shows the problem
Checked on Linux. Print preview in described testcase is okay. With testfile, preview is okay. PDF export is okay. Printed to PS, opened, is also okay.
With what version of LibreOffice?
@Joel: Pretty much the same as Win in comment 42
Found the reason, it's a hack (called so in source) from f64ef72743e55389e446e0d4bc6febd475011023 in EnhancedCustomShape2D that adds polygons with a single point in the corners of the BoundRect to allow the Slideshow to correctly paint gradients. Those single-point polygons lead to failure in Win-specific code for ClipRegion generation in WinSalGraphicsImpl::setClipRegion at the call to CreatePolyPolygonRgn (WinFunctionCall). Checking what could be done about it...
Besides that it would be better to fix the original reason, it is for now okay to only accept polygons with an area for ClipRegions. These are ones with more than two points or curves - curves are out of play here, polygon gets subdivided. Checked if that works, all looks good with that change. Doing some more tests...
Okay, solution on gerrit.
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ffbe65924d532f5ec35fc32ecd95f9535b478214 tdf#40863 only use polygons with area for WinClipRegions 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.
(In reply to Armin Le Grand (CIB) from comment #48) > Okay, solution on gerrit. thanks! will it be backported to 5.0 and 5.1?
@ marshals: I tried using gerrit, did not work. Seems as if the file vcl/win/source/gdi/gdiimpl.cxx has moved to vcl/win/gdi/gdiimpl.cxx, same for libreoffice-5-1. This makes it more complicated, argh. Does gerrit cherry-pick not support file moves, info should be in git...?
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f9578581e61d7c1419e7df84789e25ae0af0aed4&h=libreoffice-5-1 tdf#40863 only use polygons with area for WinClipRegions 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.
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a223d0b5006dade7043444ad7db6663d65366748&h=libreoffice-5-0 tdf#40863 only use polygons with area for WinClipRegions 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.
@armin - thanks, i'll test it at 5.0.x or 5.1.x
Found another sideeffect of the hack: When adding any customshape (even the ellipse on the toolbar nowadays is one) and converting to 3D and adding lines, the extra points create (ugly) lines 'around' the 3D object
Tried to reproduce the original 'error' in shading from Thorsten's hints in a weblog, could not reproduce (with hack temporarily removed). I cannot get the mentioned shading in PPT, e.g. the 2D pseudo-3D cylinder with cap where the cap is lighter than the body - can someone...?
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-0-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d50411a65fc7a3f02109057d1f92ccc3c97bab84&h=libreoffice-5-0-6 tdf#40863 only use polygons with area for WinClipRegions 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.
This regression was introduced before branch 4.4, thus it can't be bibisected with the current bibisect repositories. Changing keyword 'notBibisectable' to 'preBibisect'
Hi, Is this bug fixed? If so, could you please close it as RESOLVED FIXED? Regards
(In reply to Xisco Faulí from comment #59) > Hi, > Is this bug fixed? > If so, could you please close it as RESOLVED FIXED? > Regards i can reproduce it on Win-10 LO-5.0.4.2 (x64) but not on just-upgraded-to 5.2.1.2, so i'll close