Remove support for Borland C++ compiler, it wasn't tested since a long
time and probably didn't work anyhow and there was no interest in
keeping support for it since many years.
See https://github.com/wxWidgets/wxWidgets/pull/2087
Reimplement the logic of 16a02e6338 (Use DPI independent text size in
wxSVGFileDC, 2019-08-06) without using GetContentScaleFactor(), but
using wxDC::GetPPI() directly and do it under the platforms not using
logical pixels only.
This makes the units correct again in SVGs produced when using high DPI
under MSW even although wxDC::GetContentScaleFactor() now returns 1 in
this case.
Don't let the text size in the SVG file depend on the DPI of the system it was
created on. Let GetTextExtent, GetCharHeight and GetCharWidth return sizes
based on the default (96) DPI.
Draw the background rectangle per line, instead of one big rectangle.
When there are multiple lines and one line is shorter, the area behind that
line should not get a background colour.
The text in a wxDC is adjusted to the screen DPI, but text in a SVG file is DPI
independent. Scale the text attribute so it has the same size as in the wxDC.
Scaling will modify the position of the attribute, correct this with translate.
If nothing else, this avoids 2 calls to each of wxGetDisplaySize() and
wxGetDisplaySizeMM() on each and every wxGCDC construction which are
completely unnecessary as wxGCDCImpl uses its own hardcoded resolution
of 72 DPI, as do some other classes deriving from wxDCImpl.
And even for the classes which do compute these fields using the display
resolution, it may still be unnecessary to do it as they can be never
used if neither GetSizeMM() nor SetLogicalScale() are called on the
corresponding wxDC object.
Finally, this is more than an optimization as when using Cairo-based
wxGCDC without display (which is explicitly supported), calling
wxGetDisplaySize() simply doesn't work at all.
This function always returns true in practice and it's completely
useless to call it during each wxDC object construction, especially
because wxDC::m_colour itself is not used anywhere.
* Switch to pure Core Text Implementation, Start extended Font API
* mac fixes
* First msw implementation
* Fixing paste error
* fixing typo
* Rearranging lines to former fallthrough order
* Blind fixes for covering new abstract methods
* Blind gtk implementations
* Fixing according to travis ..
* Removing method defined in base
* formatting adaptions
* Extending the schema definition for new weights
* fixing typo, using wxRound, other fixes according to comments
* changes according to suggestions
* fixing init order, before the init of m_info was overridden by Init()
* redo
* redo
* redo
* Cleanup
Removing obsolete code snippets, proper traces for font names
* Moving common code
Only the Get/SetNumericWeight calls should now be implemented in the native part, the ‚old‘ Get/SetWeight are common code and use the numeric counterparts.
* Updating docs
* commit wa missing changes.txt
* Doc fixes
* Full stops added
wxSVGFileDCImpl class uses the default, i.e. inherited from wxDCImpl,
implementation of this method, but for it to work, the clipping box
coordinates stored in wxDCImpl need to be updated when the clipping
region changes or is destroyed and this wasn't done before.
Fix this now and add a unit test verifying that this indeed works.
::abs() truncates floating point values to ints, so use fabs() instead. This
could have been also corrected by using std::abs(), which is overloaded for
multiple types, but use fabs() for consistency with the existing code.
This fixes a problem introduced in 1e0719ad81.
See #17557.
For some combinations of start and end angles, the wrong large-arc-flag was calculated. Fixed by correctly converting the wxDC angles to SVG angles (shift -90 degrees, and invert to clockwise direction).
Arcs with the same start and end point (circles) where not drawn because the angle becomes 0 degrees. Fixed by drawing two half circles.
Elliptic arcs with a non-transparent brush had an extra line from the center to the start point of the arc. Fixed by first drawing the arc without border, then only the border.
Arcs with small angles would become invisible because the start and end point map to the same (integer) coordinate. Very large arcs would be distorted because the start and end point coordinates did not line up. Using floating point values resolves this.
See issue #17557.
Ellipses with the same start and end point (circles) where not drawn because the angle becomes 0 degrees. Fixed by drawing two half circles.
Do not close ellipses if a transparent brush is used (to match wxDC behavior).
See issue #17557.
Override SetDeviceOrigin, SetLogicalOrigin and SetAxisOrientation from wxDC and mark the graphics as changed, so the correct transform translations are applied.
Use the correct doc-type and specify the encoding. 'title' is not a valid attribute of <image> so remove it.
Removed superfluous white-space and improved indenting in generated XML.
