Mac / Win cairo is not built / used, this cairo code can be removed to
reduce code bloat.
4th Revised version with Android fixes
Change-Id: I6e56850f535ca13b77839b7d67e227c5f39d388e
Reviewed-on: https://gerrit.libreoffice.org/16218
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
the VirtualDevice is a SvpSalVirtualDevice and it
uses its own SvpSalGraphics to render to itself,
so we don't have to worry about being asked to
render to a VirtualDevice
i.e. Revert "just in case, fallback if not cairo-surface"
This reverts commit 756b2c9451.
Conflicts:
vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx
Change-Id: I3bd3ce42e7c943f8cfca1cc1d2ea6e5eb51bb349
as it now works again after ancient emf import bug is fixed by
commit 5e5b90c128
Date: Thu Feb 26 13:47:58 2015 +0000
in BITFIELDS mode (3) there are *3* pal entries not 12
and two writer qa tests adapted to test for the actual pixel color vs the
underlying pixel data
This reverts commit 3c4f7704e0.
Change-Id: Id94f98f9c620c90fda097fa97fc34c9ee957c483
This reverts commit a785df6a5f plus follow-up
3594c9ce1c "presumably destroy flushes" and
b5b19508da "WaE: -Werror=unused-variable," as it
triggered the assert(nLen <= 8) in ColorMask::ImplCalcMaskShift
(include/vcl/salbtype.hxx) in various tests.
Change-Id: Ic5433522fcd9b8cc7c4e82704cebe7d9bbcea586
That way the conversion from basebmp to cairo becomes unnecessary on blitting
the thing onto a cairo surface for gtk3 and opens a route to using cairo, e.g.
especially for text, to render to basebmp surfaces.
Change-Id: I1d11f503410af9c92a97018e9ee20045412b157e
Problem is that for the "CM Typewriter" font the Width for "space" (32)
is exported as 0 instead of 525, which is the correct value in the AFM.
The reason is that PDFWriterImpl::emitEmbeddedFont() has various arrays
to map from font code points to Unicode code points, and there are
duplicate mappings, so the 160->32 mapping overrides 32->32.
The PrintFontManager::PrintFont::readAfmMetrics() actually creates a
Unicode to font code mapping (which may legitimately be n:1) that is
then inverted; add an additional hack to store a set of "preferred"
Unicodes so that PDFWriterImpl can pick the right Unicode.
Presumably the code that is stored explicitly via "C" or "CH" in the
AFM should take priority over more generic mappings.
Change-Id: Id4205a1cd45ba6a0a5facee1e39f70c3535e7dd4
for the cases where we don't want the full result
and mark some ultra-dubious code with a TODO
Change-Id: I7cf57b8d44bbad2a6db86a8b862a757ae5062c50
Reviewed-on: https://gerrit.libreoffice.org/14189
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Where we can prove that the virtual method is never overriden.
In the case of pure-virtual methods, we remove the method entirely.
Sometimes this leads to entire methods and fields being
eliminated.
Change-Id: I138ef81c95f115dbd8c023a83cfc7e9d5d6d14ae
Implemented by both SalFrame and SalVirtualDevice, to help us to
un-tangle code that needs to operate on resources associated with
both of these without special cases.
Change-Id: If681a002647e20c57186577fe039d4ac85bba872
The aim of this patch is to allow for native gradient rendering in
SalGraphics (i.e. let OpenGL do this natively). It is a two step
process:
1. I need to allow gradient draw into SalGraphics, however the current
completely intertwined with the metafile code in OutputDevice. I am
seperating the gradient metafile code from the gradient drawing code.
2. After splitting the metafile stuff from the actual gradient drawing,
I am now able to call on SalGraphics::DrawGradient(). This just
calls on SalGraphics::drawGradient() which returns false if there is
no way of drawing native gradients, and true if there is. If false,
then we use OutputDevice's DrawGradient() functionality.
Change-Id: Ibaaabe13b76a8e7a037d9f751b5f662653a50566
Reviewed-on: https://gerrit.libreoffice.org/12119
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
