Issue 115962

Summary: Broken antialiasing on exporting curved objects to PDF
Product: Draw Reporter: mr_smyle <mr_smyle>
Component: save-exportAssignee: Armin Le Grand <Armin.Le.Grand>
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P3 CC: Armin.Le.Grand, helenrussian, issues, kpalagin
Version: OOo 3.3 RC7   
Target Milestone: ---   
Hardware: PC   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
Source file none

Description mr_smyle 2010-12-07 10:38:22 UTC
Example file attached.
To reproduce export it to PDF.
Screenshot of part of PDF with broken objects is attached too.
This is very important because printed document seems terrible.
Comment 1 mr_smyle 2010-12-07 10:39:01 UTC
Created attachment 75256 [details]
Comment 2 mr_smyle 2010-12-07 10:39:41 UTC
Created attachment 75257 [details]
Source file
Comment 3 mr_smyle 2010-12-07 21:54:50 UTC
May be this is related to  issue 70519? And it should be reopened?
Comment 4 wolframgarten 2010-12-08 08:00:27 UTC
Reproducible. Reassigned.
Comment 5 3dolab 2011-02-13 10:03:48 UTC
Rectangular shapes with rounded corners are rendered correctly when filled with
flat colors.
Faded filling breaks to heavily aliased corners.
Comment 6 Armin Le Grand 2011-11-02 14:44:16 UTC
ALG: All objects with transparency get raster converted badly, all non-transparent ones look good. Need to investigate...
Comment 7 Armin Le Grand 2012-02-06 14:52:47 UTC
ALG: Dismantled the test graphic. Problem happens with the MetaFloatTransparentActions used (transparence gradient with any content). This cannot be directly exported to PDF, but gets converted to bitmaps with transparency (vcl/source/gdi/pdfwriter_impl2.cxx ln 402 ff). I checked the size calculations by giving the object a size of 1x1 inch, leading (with the used 27 DPI) to exactly 72x72 pixels for an object with that size. Of course this looks bad, but is correct at the first view.
Comment 8 Armin Le Grand 2012-02-06 16:50:58 UTC
ALG: Checked various aspects of PDF export: Normally implying 720 DPI (see VirtualDevice::SetReferenceDevice with REFDEV_MODE_PDF1 used from the PDF Exporter). Just for MetaFloatTransparentAction this is not used, but:

nMaxBmpDPI = i_rContext.m_bOnlyLosslessCompression ? 300 : 72;

This means there is a workaround to choose lossless compression in the PDF dialog to get 300 DPI for conversion of MetaFloatTransparentActions to BitmapEx. This also means even then nut the full implied DPI for PDF export is used. The workaround also increases PDF file size by exporting images lossless. There is also an increase of data (of course) when going from 72 to 300 DPI, but compared with using 720 DPI (I tried that out) it is acceptable and gives acceptable results, a good quality/filesize compromize.

For solving this I tend to raise the default resolution to 300 DPI for exporting of MetaFloatTransparentActions, independent from set lossless compression.
Comment 9 Armin Le Grand 2012-02-06 17:00:41 UTC
ALG: This works as interim solution. There is also the possibility to not create MetaFloatTransparentAction when preparing PDF export by converting primitives to Metafile, but this would just use an even higher resolution. The long term solution is to export the transparence gradient to PDF (1.4 is capable of this) or (even better) base PDF export on primitives and do this.

ALG: Comitted, done in r1241078.