Resolves: #i121591# Corrected some transparent printing stuff for windows
(cherry picked from commit d4b5b8bf22edc31f18232abd764edddb2ca19738) Conflicts: vcl/win/source/gdi/salgdi_gdiplus.cxx Change-Id: I8191f945de10786982fcd1e94afc4f8adbe653bc
This commit is contained in:
committed by
Caolán McNamara
parent
b0e2f891f0
commit
8681545a76
@@ -282,8 +282,14 @@ void OutputDevice::DrawTransparent( const PolyPolygon& rPolyPoly,
|
|||||||
const double fTransparency = 0.01 * nTransparencePercent;
|
const double fTransparency = 0.01 * nTransparencePercent;
|
||||||
if( mbFillColor )
|
if( mbFillColor )
|
||||||
{
|
{
|
||||||
// draw the transparent polygon
|
// #i121591#
|
||||||
// NOTE: filled polygons are assumed to be drawn as if they were always closed
|
// CAUTION: Only non printing (pixel-renderer) VCL commands from OutputDevices
|
||||||
|
// should be used when printing. Normally this is avoided by the printer being
|
||||||
|
// non-AAed and thus e.g. on WIN GdiPlus calls are not used. It may be necessary
|
||||||
|
// to add (OUTDEV_PRINTER != meOutDevType) to the entering if statement, thus
|
||||||
|
// using the fallbacl some lines below (which is not very good, though). For
|
||||||
|
// now, WinSalGraphics::drawPolyPolygon will detect printer usage and correct
|
||||||
|
// the wrong mapping (see there for details)
|
||||||
bDrawn = mpGraphics->DrawPolyPolygon( aB2DPolyPolygon, fTransparency, this );
|
bDrawn = mpGraphics->DrawPolyPolygon( aB2DPolyPolygon, fTransparency, this );
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@@ -187,6 +187,33 @@ bool WinSalGraphics::drawPolyPolygon( const ::basegfx::B2DPolyPolygon& rPolyPoly
|
|||||||
Gdiplus::DllExports::GdipSetSmoothingMode(pGraphics, Gdiplus::SmoothingModeNone);
|
Gdiplus::DllExports::GdipSetSmoothingMode(pGraphics, Gdiplus::SmoothingModeNone);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
if(mbPrinter)
|
||||||
|
{
|
||||||
|
// #i121591#
|
||||||
|
// Normally GdiPlus should not be used for printing at all since printers cannot
|
||||||
|
// print transparent filled polygon geometry and normally this does not happen
|
||||||
|
// since OutputDevice::RemoveTransparenciesFromMetaFile is used as preparation
|
||||||
|
// and no transparent parts should remain for printing. But this can be overriden
|
||||||
|
// by the user and thus happens. This call can only come (currently) from
|
||||||
|
// OutputDevice::DrawTransparent, see comments there with the same TaskID.
|
||||||
|
// If it is used, the mapping for the printer is wrong and needs to be corrected. I
|
||||||
|
// checked that there is *no* transformation set (testcode commented out below) and
|
||||||
|
// estimated that a stable factor dependent of the printer's DPI is used. Create
|
||||||
|
// and set a transformation here to correct this
|
||||||
|
const Gdiplus::REAL aDpiX(aGraphics.GetDpiX());
|
||||||
|
const Gdiplus::REAL aDpiY(aGraphics.GetDpiY());
|
||||||
|
|
||||||
|
// test code to check the current transformation at the graphics device
|
||||||
|
//Gdiplus::Matrix matrix;
|
||||||
|
//aGraphics.GetTransform(&matrix);
|
||||||
|
//Gdiplus::REAL elements[6];
|
||||||
|
//matrix.GetElements(elements);
|
||||||
|
|
||||||
|
Gdiplus::Matrix aPrinterTransform;
|
||||||
|
aPrinterTransform.Scale(Gdiplus::REAL(100.0) / aDpiX, Gdiplus::REAL(100.0) / aDpiY);
|
||||||
|
aGraphics.SetTransform(&aPrinterTransform);
|
||||||
|
}
|
||||||
|
|
||||||
Gdiplus::DllExports::GdipFillPath(pGraphics, pTestBrush, pPath);
|
Gdiplus::DllExports::GdipFillPath(pGraphics, pTestBrush, pPath);
|
||||||
|
|
||||||
Gdiplus::DllExports::GdipDeletePath(pPath);
|
Gdiplus::DllExports::GdipDeletePath(pPath);
|
||||||
|
Reference in New Issue
Block a user