The EmfPlusStringFormat object specifies text layout, display manipulations,
and language identification. With this commit the support for font language
and country was added. Also Bold style is applied,
for strings which needs that.
Change-Id: Id9735a9ddb959aebd20d6d4d1bb5da0fa9c1fb85
Reviewed-on: https://gerrit.libreoffice.org/36555
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
The EmfPlusDrawlLines record specifies drawing a series of connected lines.
Bit 0x2000 indicates whether to draw an extra line between the last point
and the first point, to close the shape.
In this commit support of additional line which close shape was added.
Change-Id: I47ae3d8003cbfdd5b8ff5ba78e1ebe10f97af04b
Reviewed-on: https://gerrit.libreoffice.org/36317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
just the simple and obvious case for now, of a local var being allocated
and deleted inside a single local block, and the delete happening at the
end of the block
Change-Id: I3a7a094da543debdcd2374737c2ecff91d644625
Reviewed-on: https://gerrit.libreoffice.org/33749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This helps make emfplus.cxx more readable.
No source code was changed, only moved except these
renamed to avoid inheritance warnings::
EMFPBrush::transformation renamed to brush_transformation
EMFPPen::transformation renamed to pen_transformation
Change-Id: I6952d6300c9c459833c2dda2b715d851b9e80de7
Reviewed-on: https://gerrit.libreoffice.org/31165
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
... except in include/rtl, include/sal, include/uno, where sal_Size is
retained for compatibility, and where callers of rtl functions pass in
pointers that are incompatible on MSVC.
Change-Id: I8344453780689f5120ba0870e44965b6d292450c
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
probably not much performance benefit, but it sure is good at
identifying leftover intermediate variables from previous
refactorings.
Change-Id: I3ce16fe496ac2733c1cb0a35f74c0fc9193cc657
Reviewed-on: https://gerrit.libreoffice.org/24026
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Sequence.h(xx), Any.h(xx) and Type.h(xx)
and remove unused using-declarations from these files.
Add a few missing includes provided by them.
Change-Id: I6b91b6d1fdf9d0496dd546c0aab9bdcc6831a5d4
Reviewed-on: https://gerrit.libreoffice.org/23805
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
comphelper, connectivity and cppcanvas.
Replace with C++11 delete copy-constructur
and copy-assignment.
Removed unused boost/noncopyable.hpp includes from
some source files in cppcanvas.
Change-Id: I90780820e21fbfd291ac10c266e7d16616e3a81b
Reviewed-on: https://gerrit.libreoffice.org/23905
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
For presentation transparence groups are rendered by the canvas
using VirtualDevices and Bitmaps. To adapt for then painting
the Bitnmap to the canvas the RenderState needs to be adapted
to e.g. reflect the already applied scaling. Missing was to adapt
a set clip polyPolygon to be synchronized with the new RenderState
transformation.
Change-Id: If760a8076e016a6dcf306db71971f1fd2fef7017
Reviewed-on: https://gerrit.libreoffice.org/22720
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
I'm changing the Font class function names:
- SetSize -> SetFontSize
- GetSize -> GetFontSize
- SetHeight -> SetFontHeight
- GetHeight -> GetFontHeight
- SetWidth -> SetAverageFontWidth
- GetWidth -> GetAverageFontWidth
That's because it really makes no sense to say that there is a
single constant font width because obviously proportional fonts
don't have one - the best we can do is an average font width,
which is what folks like Microsoft sort of do already. On a fixed
font, the average is still accurate, for obvious reasons :-)
I'm also not a fan of GetSize/SetSize as I find it a might too
generic.
Change-Id: Ib80a604ba62d6883fd6cbc7994da763976be5c70
Reviewed-on: https://gerrit.libreoffice.org/22069
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
and consistently map css::drawing::LineJoint_MIDDLE to the same thing that
css::drawing::LineJoint_MITRE points to everywhere else
Change-Id: I77b7586ea13f3fe84c0529172758256666488d36