Apparently some time before inital CVS import a global
search-and-replace went horribly wrong and added spurious namespace
prefixes everywhere.

Change-Id: I4009bc3ab4b1d4c80412f75ad0e4628a382f99f0

Change-Id: If1b3e9807414e90341199eabfa937376084c097d

As per Repository.mk, we only have this on linux AND headless.

Change-Id: I708c89e38a661afb839ab1ac3e48ff9b2ecc040c

Change-Id: I72fc636b1187bc99370b43927b25ed6fb89fe8f3

i.e. as far as I can see the bug came about during....

commit 74cb1c4c
Author: Ivo Hinkelmann <ihi@openoffice.org>
Date:   Tue Nov 14 12:37:46 2006 +0000

with

2006/10/27 12:14:08 aw 1.2.1208.5: #i39528# ::basegfx -> basegfx adaption

in

-                Vector2D aFullVec(aStartPos - aEndPos);
-                Vector2D aOldVec(Vector2D(aRect.Left(), aCenter.Y()) - aRect.TopLeft());
                                                         ^^^^^^^^^^^
-                double fFullLen = aFullVec.GetLength();
-                double fOldLen = aOldVec.GetLength();
-                double fNewBorder = (fFullLen * 100.0) / fOldLen;
-                sal_Int32 nNewBorder = 100 - (sal_Int32)(fNewBorder + 0.5);
+                basegfx::B2DVector aFullVec(aStartPos - aEndPos);
+                const basegfx::B2DPoint aTopLeft(aRange.getMinX(), aRange.getMinY());
+                const basegfx::B2DPoint aCenterLeft(aRange.getMinX(), aRange.getHeight());
                                                                       ^^^^^^^^^^^^^^^^^^
+                const basegfx::B2DVector aOldVec(aCenterLeft - aTopLeft);
+                const double fFullLen(aFullVec.getLength());
+                const double fOldLen(aOldVec.getLength());
+                const double fNewBorder((fFullLen * 100.0) / fOldLen);
+                sal_Int32 nNewBorder(100L - FRound(fNewBorder));

Change-Id: I840caa5e49a04f9b6460c4fa8e3731f3e5ebde05

Otherwise lock files etc. aren't cleaned up, which isn't particularly
nice should when then opening the file in normal LibreOffice.

Change-Id: I822b6fb582473674371a4c1d403d5a05adb7ea6b

Change-Id: I33ae83a97be254a3d3716bd9ae05f089845fd536

Change-Id: I902f3a134b4a7dcc721eff3f67376014a4276885

Otherwise we get segfaults in cppu::idefaultConstructElements when exiting,
in addition to complaints of:
ignoring GError "Operation not supported" for <***RECURSION DETECTED***/log.txt>

Change-Id: If2f56873f50ba957288d1e5591db967d248ee7a4

(No real implementation yet.)

Change-Id: I67b84b554dbb29db449d8c190ef816645a8bff07

Means that no changes should be required here once calc/impress/draw
support tiled rendering.

Change-Id: I0987d94303f39ba37e29b9ae7b2276e82dc0ccbf

We want to have a simple interface that allows access to tiled
rendering without digging into the internals of writer
(and in the future calc/impress/draw).

Change-Id: Ia9c278a48c919333186e5361ff25bb1ab603b846

Change-Id: I6cf810af55284cb6ddd9e0bfd879fd19508d127a

Seems to be a gtk bug which we need to work around. The assertions
don't actually seem to cause any harm (they just print a bunch of
"Gtk-CRITICAL **: IA__gtk_range_get_adjustment: assertion `GTK_IS_RANGE (range)' failed"
but probably best to avoid them.

Change-Id: I5d1bb20bd5c0569c6d023a6148123208a15b9de2

desktop is no longer the right place for it now that
libreofficekit has its own directory.

Change-Id: I207f1d642e7e35c460ff85bb57aa142cb98023c8

MakeVisible only scrolls the view, so parts of the tile to be rendered
might be outside the SwView's visible area, and therefore not painted.

This however makes the background window (shown for the tilederendering
app) unuseable (but that window is invisible for all practical uses
of tiled rendering, and hence probably not a problem).

Change-Id: I6c3c2846906163b362f7cff6d8c7ba308a58a7ad

The scaling is wrong, but seems to work in principle
(i.e. we get roughly 1.5x the correct size).


Conflicts:
	sc/source/ui/view/gridwin4.cxx

Change-Id: I6db1986e6cb1e5f3889ec3a462d999a9eab57331

Very basic, but works.

Change-Id: I0c521e833b53e13065e0be48e6fa767e44b29787

These were needed for the X11 "context" rendering which is no longer used.

Change-Id: Ib60c8fff9dad06b1f8f489eed66c3b3c3597e1ee

basebmp and vcl now set the alpha channel appropriately, so no need
to do so in the viewer now.

However it would perhaps make more sense to just use RGB instead
of RGBA, seeing as the alpha channel is permanently set to be opaque.

Change-Id: I86ad758c6a8bee21b265730727a76605e5850c0c

Otherwise the alpha channel for bitmaps created directly is empty,
indicating a transparent bitmap (although we don't actually handle
transparency). This complements hardcoding of the alpha channel
in basebmp. VCL bitmaps can be copied bit-for-bit directly into
a basebmp bitmap, hence it's important to make sure we fill the
alpha channel in vcl too.

Conflicts:
	include/vcl/salbtype.hxx

Change-Id: Icb2fa417db6625a6ffa6bd82eb5773ff75be5a3c

Currently the alpha channel is completely ignored by basebmp.
However this results in completely "transparent" output, meaning
the client has to manually overwrite the alpha channel -- instead
we now set it automatically when writing colourdata.

Unfortunately this doesn't quite work -- it seems that drawing
a non-opaque bitmap/image on top of the existing bitmap can
erase the alpha channel information (i.e. these areas will
once again be transparent -- for example document borders seem
to have a transition effect overlayed onto them): presumably
there is some method that bypasses our RGBMaskSetter (probably
some form of direct manipulation of raw values?).
manipulation in basebmp

Change-Id: Ia4be6a748cc30191a4422121f9ec347d9198b225

We can now set the colourspace as desired, and we return the rowstride too.

Change-Id: Idf1e55a67b9e9ab58e82d7ed0be2813b682ec2ff

Change-Id: I3f567ff19ee0d5b0d54aeef9b163b78567d72946

Means we can get rid of hackily storing a reference to the last
buffer we created.

Change-Id: I8092a7d87bc391301f75651a59b37fbd73ac64fd

We also want to be able to set whether or not the buffers
should be painted to top down, so add that parameter
as necessary (default seems to be false, however e.g. gtk
requires this to be true, i.e. needed for tiled rendering).

Change-Id: Id98882e4c7f62508ae5a976c0d8df743460a4ab2

The Alpha channel seems to be set incorrectly by LO, hence
we need to manually set it here for now.

Change-Id: I1f9091b8b6f88c1dba6653dfb7bf51f9fe14b3fc

This is the expected format for gtk+ pixbufs which is currently
the primary target. We could potentially allow the user to choose
the format via LibLO -- but we want to eventually allow passing
in a buffer (rather than passing out an LO owned buffer) anyway, so
should add that then.

Change-Id: I8427925a94366917fa82fb8ea28e7dbb3fa1840d

Although svp defaults to BGR, we might want to use alternative
formats (e.g. for tiled rendering to bitmap buffers which are
to be used in e.g. gtk), it is probably safest to keep the current
defaults but allow the user to change to whatever format they may
require. (This currently only makes sense for the 32-bit
RGBA/ARGB/etc. formats. However the 23 bit formats could potentially
be expanded to allow a similar RGB/BGR choice.)

Change-Id: I70bd3d6e7d297faef163b910f576655efee4cb3f

We just draw one huge tile, it doesn't seem to work too well
for larger documents though where the latter portions can appear
empty.

Change-Id: Ic527aec377bf2f82a528a04392186d3d8b752762

Change-Id: Ibd69f8e766fd421b05d2305f967179a969bc5b56

The buffer width could be larger than the desired rendering
width, hence we need to give the client access to the rowstride.

Change-Id: Ic63c1f455c89960164e076ed2528d43e64e81a40

Looks pretty decent now -- however the vertical flipping isn't ideal.

Change-Id: I6ffa9d2b8fced142308781e06e8f161228f1db26

We still need some way of managing the buffers properly rather
than just keeping a static reference to the last buffer
that was rendered.

Change-Id: I17940c758948aa9418f4e0216ecd253d128cd04f

Just a hardcoded single tile for now.

Change-Id: I9bfae4243e0083aa8fca38ae98dc369fe6de36fb

We still need to add functions for getting dimensions of documents
etc. for this to be truly useful, this is also only usable for writer
documents for now.

Change-Id: I07812c9b72caca71dfd509705af48c1d355cb2f8

Change-Id: I46760c0a1329b9823fd999c470b57fef66d28914

The center-left point in the area is used to calculate the old vector length but the coordinate was incorrect.

Change-Id: I81a88182d11e30ee7a5caee3eac879b082bff160
Reviewed-on: https://gerrit.libreoffice.org/9887Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ib8ece5b151325b473f896294fe059b5b0d166cc6

So that vertical text adjustment of the shape is reflected in the
textbox layout.

Change-Id: I887d51928fe4d37db08864374e0cea54f80953b5