Issue 115962 - Broken antialiasing on exporting curved objects to PDF
Summary: Broken antialiasing on exporting curved objects to PDF
Alias: None
Product: Draw
Classification: Application
Component: save-export (show other issues)
Version: OOo 3.3 RC7
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Armin Le Grand
QA Contact: issues@graphics
Depends on:
Reported: 2010-12-07 10:38 UTC by mr_smyle
Modified: 2017-05-20 10:33 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

antialiasing (67.79 KB, image/jpeg)
2010-12-07 10:39 UTC, mr_smyle
no flags Details
Source file (54.98 KB, text/plain)
2010-12-07 10:39 UTC, mr_smyle
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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.