When using both wxEnhMetaFileDC (used for print preview) and
wxPrinterDC, a global scale factor was applied to the graphics context
in wxGDIPlusPrintingContext ctor and this changes size of the text
rendered using size specified in point units.
To prevent this from happening, stop applying this scale factor in the
base class GetTextExtent() and apply it instead when setting fonts in
the derived wxGDIPlusPrintingContext only. This ensures that the results
are consistent between GetTextExtent() and DrawText() and also keeps
the font scale hack entirely in wxGDIPlusPrintingContext without
affecting the base class.
It's still not totally clear why do we have to do this at all even
although we specify the font sizes in UnitPoint units which ought to be
DPI-independent -- but somehow are not. But at least the output is
correct now and the code is arguably more clear than before.
This fixes a regression with text size when printing or previewing
introduced by d5020362ffCloses#18338.
Don't always call several GDI+ functions when we often don't need their
results: only retrieve the cell descent, ascent and the line spacing if
we are going to really use any of these values.
This method allows to retrieve the window this context is associated
with, if any.
Add "wxWindow*" argument to wxGraphicsContext ctor and provide the
window pointer to it when available, i.e. when creating the context from
a wxWindow directly or from wxWindowDC, which is also associated with a
window, in platform-specific code.
No real changes yet.
This is more consistent with the other headers, which are safe to
include even when the corresponding feature is turned off.
Also remove the now redundant wxUSE_ENH_METAFILE checks in the source
code including this header.
See https://github.com/wxWidgets/wxWidgets/pull/951
After executing native operations on the graphics path, the native
current point is updated properly and should be used instead
of manually maintained logical point.
See #18111.
Handle this feature as all the other ones and provide a configure switch
and a setup.h option to disable it if necessary, as it may be desirable
to do it, especially under Linux, to avoid extra dependency on pangoft2
if this functionality is unnecessary.
Add an explicit call to wc_str() in one place where conversion to
wchar_t* is needed and use wxString::operator==() instead of lstrcmp()
to avoid having to perform this conversion explicitly in another place.
This ensures that they will be defined and work even when building with
wxUSE_GRAPHICS_CONTEXT==0 (as can happen even by default with old MinGW
versions).
Private fonts are still made available to wxGraphicsContext as well by
providing access to them from GDI+ code via wxGetPrivateFontFileNames().
wxFont::AddPrivateFont() can now be used to load a font from a file for the
applications private use. Update the font sample to show this.
Closes#13568.
It doesn't make much sense to require all the graphics backends to
create wxGraphicsPen from either wxPen or wxGraphicsPenInfo when the
former can be handled just once in the common code.
So do just this, leaving CreatePen() overload taking wxGraphicsPenInfo
where the real pen construction takes place and implementing
wxGraphicsPen creation from wxPen in the common wxGraphicsContext code.
This is not 100% backwards-compatible as any code inheriting from
wxGraphicsRenderer and overriding its CreatePen() will now be broken,
however this should be extremely rare (there is no good reason to
inherit from this class in the user code) and result in compile errors
if it does happen.
Add wxGraphicsContext::CreateFromNativeHDC() and wxGraphicsRenderer::
CreateContextFromNativeHDC() to allow creation not only from native
renderer object, but also from HDC, which is something universally
supported by win32 implementations.
For the sake of compatibility with Cairo (and Direct2D) an initial line segment should be added to the path from the current point (if set) to the beginning of the arc.
Closes#17557
To handle properly all combinations of the start and end angles and to ensure consistency with Cairo renderer behaviour there is necessary:
1. To normalize angle values the same way as it is done in Cairo.
and
2. When end angle equals start angle then actually no arc should be added but current point of the path has to be updated.
3. When difference between end angle and start angle >= 2*pi then in addition to the arc itself also one or more full circles have to be added to the path.
Closes#17558
Cairo renderer places MOVE_TO element into the path immediately after after the CLOSE_PATH element so to ensure that GDI+ will behave in the same way the new sub-path should be started at the joined endpoint of the current just closed sub-path.
See #17532
Since resulting wxGraphicPath should have the same state as appended path so we have to grab in wxGraphicsPath::AddPath also auxiliary data from appended wxGraphicsPath.
See #17532
When current point is not set before the call to wxGraphicsPath::AddCurveToPoint() then it should be set at first control point prior to adding a curve (function should behave as if preceded by MoveToPoint).
See #17526
When sub-path is closed with CloseSubpath() then current point should be moved to the joined endpoint of the sub-path (what is equivalent of moving it to the starting point of the sub-path). Native CloseFigure() doesn't move the native current point to the starting point of the figure so we need to maintain it on our own in this case.
To implement this behaviour we need to store the starting point of the figure in a dedicate data member and use it to update the current point when the figure is closed.
But native GDI+ renderer doesn't offer any support for updating directly the current point (only explicit drawing operations update its value) so we need also to remember our "logical" current point (being the result of calling CloseSubPath, MoveToPoint, etc.) in a dedicated data member and use it instead of the native current point in the next operation which requires current point location.
Closes#17520
Apparently it's a common convention to allow width and/or height of a
rectangle to be negative as both GDI and Cairo handle this natively, so also
allow this for GDI+ and document this as the expected behaviour.
Closes#17495.
Ensure that 32bpp bitmaps selected in wxMemoryDC use DIB for their internal
representation as GDI+ functions don't seem to work correctly with DDBs.
Note: Code responsible for converting and fixing the bitmap has been moved
from wxGCDCImpl::wxGCDCImpl to wxGDIPlusRenderer::CreateContext because this
is the common entry point for creating context for GDI+.
Closes#17324.
When converting internal bitmap to wxImage in wxGDIPlusBitmapData::ConvertToImage set up output alpha channel buffer only if source bitmap contains alpha channel values.
