Created attachment 42942 [details] simlple document with some text and a vector drawing If an object drawing (composed of pieces that can be grouped, ungrouped, moved around and so forth) is printed to PDF Creator the drawing is first converted to an image. If instead the export to PDF is used the object remains as a vector drawing. The difference is evident because of the compression artifacts in the image, and the unlimited resolution on zoom in the object form.
Created attachment 42943 [details] page printed through PDF creator, vectors converted to image
Created attachment 42944 [details] page exported to PDF, vectors stay as vectors
When writer prints a page with a vector (object) drawing through PDF Creator the vector drawing is converted to an image. Using export to PDF leaves it as a vector. PDF Creator can print vector (object) drawings from Word to a PDF leaving them as vectors, so the problem appears to be in LibreOffice and not in PDF Creator. I looked for a setting to control this behavior (convert objects to images?) but did not find one.
Not surprisingly, the same problem is present in Impress. Next few attachments demonstrate this.
Created attachment 42946 [details] one page impress with an object based drawing
Created attachment 42947 [details] printed to PDF through PDF creator, object becomes image
Created attachment 42948 [details] exported to PDF, object becomes vector graphic
I believe this one is INVALID @mathog: Please contribute information concerning your OS, Platrorm, PDF Creator Version, details concerning PDF Creator properties! Why do you think that this is a LibO problem and not a PDF creator problem?
Windows XP SP 3 PDF Creator 1.2.0 I believe this is a problem in LibreOffice because I can print a Powerpoint slide with vector graphics object to a PDF through the same PDF Creator "printer" and it will end up as a vector graphic. Will post an example in a moment.
Created attachment 43033 [details] Word document with a vector graphic object
Created attachment 43034 [details] PDF from Word through PDF Creator PDF file generated by printing through the PDF Creator "printer" from within Word. The vector graphics object remains as a vector graphic (can be seen by zooming up to very high magnifications, where it remains sharp). The same print operation from LibreOffice Writer or Impress converts the graphic to an image first.
You see me perplexed. Both documents from WORD and OOo seem to be created with PCFCREATOR (you see it in the footer) using Ghostscript 9.0. My knowledge might be obsolete, former PDF creators always did the job via Postscript printer, and there many information got lost (classic example: hyperlinks). My suspect: PDF-Creator and GS9 have integrated intelligence to recognize and integrate (vector-) objects, but they only recognize WORD objects, not ODF-objects? I se a very low importance for this problem, because LibO has a powerful PDF export, and because I am pretty sure that it's a PDF Creator or GS problem. So we have to wait until a developer will be bored by his normal work ;-) @mathog: May be you can discuss that in <http://www.pdfforge.org/forum/> and summarize the result here?
Correct name writing in Subject line
Other data points - Inkscape 0.48 and Scribus 1.3.7 also convert object graphics to images when printed through the PDF Creator printer. Both also have export to PDF functions which leave the object graphics as vectors. Also PDF XChange Viewer printed through PDF Creator converts vector graphics to images. This is interesting because: Word -> PDF Creator-> PDF file (vector graphics) -> PDF Xchange Viewer (in display it is still vector graphics, no loss of resolution on zoom) -> Print from Xchange Viewer through PDF Creator (same settings!) -> PDF File -> PDF Xchange viewer (graphics have been converted to an image). In summary, it looks like the MS programs are embedding the vector graphics into the output, probably as postscript, since that's what the PDF Creator printer looks like (a postscript printer), but (most) other software is converting the vector graphics to images before sending it to that postscript printer. Is there an option in LO somewhere to tell it to embed vector graphics instead of converting it to an image? I know there is a PDF export, but it isn't quite as powerful as you make out - it lacks the /screen /ebook etc. settings, control over font embedding, and some of the other goodies I use in PDF Creator. [We posted at the same time. I don't think PDF Creator is looking for Word Objects, I think the MS programs are recognizing that the target is a Postscript printer and are embedding the graphics as postscript commands. The active part of PDF Creator is GS 9.0, and I'm pretty sure it doesn't know anything about MS formats at all, it only knows postscript and PDF.]
Printed the two test documents already attached, an .odt and a .doc to the same color postscript printer from LO and Word 2003 respectively, in both cases doing "save to file". The postscript file from LO was over 6MB and included a bitmap image for the graphics. Conversely, the postscript file from Word was only 26KB and had a vector version of the graphics. I will attach the second one, the first one is a bit big and anybody who wants to can easily make a copy. My conclusion, the postscript output method in LO converts vector graphics to an image before printing to a postscript device. I think that is a bug, there is no reason to do that. The vector graphics should stay as vectors. It is logically inconsistent that text is emitted to the postscript file as text, but vector graphics are converted to images instead of staying as vector graphics.
Created attachment 43036 [details] Print to file (postscript printer) from Word The vector graphics objects were retained as vector in this postscript file.
I have made some progress. It turned out that the original drawing made in Inkscape had alpha=250, even though Opacity was 100.0%. This was causing Inkscape to convert to image on printing. Changed alpha to 255 for all objects and then Inkscape printed to PDF through PDF creator as a vector. Now then, incorporated the revised SVG into an LO writer document. Printed that through PDF Creator, and it too was vector graphics. However, not nearly as good as the ones from Inkscape directly. (Circles were much lower quality.) Apparently the change in Alpha matters a lot, and also, apparently, that value matters to LO when it imports the SVG file, but LO does not seem to reveal this value anywhere. Will attach examples in a second.
Created attachment 43060 [details] Revised SVG with Alpha set to 255
Created attachment 43061 [details] PDF made by PDF Creator from revised inkscape SVG file
Created attachment 43062 [details] Revised ODT made by importing alpha=255 SVG
Created attachment 43063 [details] PDF produced from partiallyresolvedproblem.odt via PDF creator Zoom in on the circles and notice that while they are now vector based, they are not very good circles. They seem to be made up of a fairly small number of line segments and there is some rounding or truncation error, so that the circle has teeth on it, like a circular saw blade. Conversely, zoom in on the fig_alpha255.pdf circles and even at 6400% they are smooth and perfectly circular.
At this point I will summarize what (I think) is going on here: 1. Inkscape uses Cairo for 2D drawing. http://cairographics.org/ 2. LibreOffice either uses Cairo or something very similar to it. 3. Cairo uses an alpha value for any drawn color with a value between 0 and 1 to achieve various sorts of transparency. For background: http://en.wikipedia.org/wiki/Alpha_compositing 4. In Inkscape Alpha shows up as the "A" line in some of the color pickers with a range of 0 to 255, with 255 being no transparency. There is also a separate opacity setting but I do not know how they interact. 5. In LibreOffice color pickers there is a transparency setting that corresponds to Alpha. It shows up in two places. Right click object, select "Line...", select Line tab, and there is "transparency". For area Right click object, select "Area...", select transparency tab. 6. If ANY part of a drawing in LibreOffice has a transparency value other than 0 the ENTIRE drawing will be converted to an image. Some of the other image options will probably result in the same conversion. 7. An SVG drawing made by Inkscape and imported into LibreOffice with an Alpha value other than 255 will result in the corresponding transparency field being non-zero. For instance, an alpha of 250 might result in a transparency value of 2%. (I stated in comment 17 that this value was not exposed, I was wrong, I just had not found where yet.) 8. BUG. When an SVG drawing is imported circles are converted to funky polygons. LO Draw CAN create and output a perfect circle, there is just some issue with SVG import. (see "6dot" attachments, where the red circle was added in Draw, and the black "circles" were imported from an SVG). 9. ISSUE. In a complex drawing there might be thousands of objects and if a single one of them has a nonzero transparency value the entire graphic will be rasterized. The difference being a 6MB output vs. a 25KB output. One errant click can mess the whole thing up. There is currently no way to find an object with a transparency value other than 0. Suggested solution 1: tools -> select object by graphics property -> transparency: zero/nonzero/(specific value). (Similarly for the other graphics properties). Suggested solution 2: add a visual warning of some sort when a graphics object is selected indicating its type: object/raster, for instance, by showing that text on the bottom line of the frame. 10. ISSUE. This entire "will it be rasterized or not" behavior is exceedingly complex. It might be better if each extended graphics object (consisting of all graphics pieces which are either grouped or overlapping) had an overall type of object/raster, so that operations which would change type object->raster would generate a warning. I understand that this is messy since that will depend on the output file type, which isn't usually specified until one prints or exports.
Created attachment 43122 [details] 5 black "circles" imported from SVG, one red circle created in Draw Source for next PDF attachment.
Created attachment 43123 [details] PDF output, SVG import "circles" are not perfectly round,draw circle is The Red circle added in Draw is perfectly round, the black "circles" imported from SVG are funky polygons. Both are vector objects. (View the PDF at high magnification.)
Reduced print quality -> Normal Importance @ mathog: Thank you for your detailed observation results.
Bump. I have similar issue with LibreOffice 3.3.3, compiled for OpenSUSE 11.4 distribution. *ANY* document printed on PostScript device in LibreOffice Draw is initially converted into bitmap graphics, and then send as a bitmap to the postscript printer. I have a large drawing made in OpenOffice Draw, which I used to print in A0 on a PostScript->PDF converter with 1200dpi resolution for eventual rastered graphics. OpenOffice was printing it very quickly with nearly no memory overhead, and the PDF created had a size of 512KB. Now, after I switched to LibreOffice I am unable to print it at all. The LibreOffice gets killed by OOM killer (together with many other processes) after it consumes 5GB of memory. After I reduced the printer resolution to 72dpi it turned out, that the PDF document consist of only one raster image - the image of entire A0 page itself. The problem were also EPS images on the page - in printing their TIFF preview images were used, instead of the PS content. This again was not the case with OpenOffice. Before anyone claims the PS->PDF converter is guilty I repeated the test with real A0 PostScript printer and failed exactly the same way. Before the printer receives any data at all, LibreOffice converts the document into bitmap graphics. Therefore it's even impossible to "print into file" since I run out of memory before entire 1200dpi 24bit A0 raster image (which itself would be >8GB in size) is built.
[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
Checked this in 3.5.0b2 on Windows XP SP3. The transparency issue is unchanged. If any component of a drawing has a transparency value other than 0 then it will be rasterized. The SVG import problem, where circles ended up looking like polygons, seems to have been resolved.
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian