With simple transliteration, TextSearch::searchForward used to use
whole string to perform the search, then started to create substring
to search. But it left the precautions from
commit c00601dab0 by Eike Rathke:
searching for $ may actually return a result set pointing behind the
search string which it does with the ICU regex engine.
The precaution made it to skip reverse mapping if index was 0.
Commit 9aae521b45 by Michael Stahl
didn't consider the case when nStop is 0, and startPos > 0. Then it
tried to get offset[-1].
Anyway, using value of startPos in those conditions seems illogical.
Removed those precautions (and made assertions for that).
Fixed handling zero indexes.
Change-Id: I2066abc51fff7fb7323bc7f6198bdea06439d4f3
Reviewed-on: https://gerrit.libreoffice.org/19840
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
enabling us to delete a whole pile of foo
For android we patch cairo, which is internal in that case, to swap the rgb
components so that cairo then matches the OpenGL GL_RGBA format so we can use
it there where we don't have GL_BGRA support.
Change-Id: I25e34889c7b7263438b143dd2a2ad882fb0f190a
comparing the pointer values in std::unique_ptr's can never be true
(since they cannot point at the same thing, by definition)
Change-Id: I38eb6406b61d5a3662adb68ca1558248925d7e90
Image could be of 2 types - BITMAP or IMAGE, where BITMAP used to
store the content in a Bitmap and IMAGE in a ImplImageData, which
contained a BitmapEx. This was refactored with this commit to
always store the content in a BitmapEx and there are no distinct
image types anymore. This greatly simplfies the code.
Drawing of the image in case of type IMAGE was done in the class
ImplImageBmp which also modified the image according to
DrawImageFlags (for example to create a "disabled" image). This
was moved to ImplImage and the bitmap manipulation code was moved
to BitmapProcessor (done in previous commits).
Change-Id: Iec9f63a7c05618c457d8465f1ec60ed4f16bd579
With this, if a comment has enough content that it gets a vertical
scrollbar, then tiled rendering output looks OK, even with non-100%
zoom.
Change-Id: I699aadc11b6c34fb0791e70705719fd61169d972
Since commit 2b5bf2f1c5
"graphic import improved" from 2006-11-20 by Oliver Specht,
there is an unused code reading pixel size (PROP_SIZE_PIXEL) of an
image in a part of GraphicImport::createGraphicObject() that imports
the wrap polygon.
When there's no PROP_SIZE100th_M_M in graphic, the imported wrap
polygon was simply dropped, and then automatic contour was generated
for graphic. Now we import contour correctly in this case.
Also, as paragraph background overlaps non-opaque graphics,
we need to set opaque to true regardless of behindDoc value of
wp:anchor.
Change-Id: Ifa5eec9f8ccaf5ba051732b6e4f965ae8606a1cf
Reviewed-on: https://gerrit.libreoffice.org/20103
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
See include/vcl/devicecoordinate.hxx.
(But why do we use the vague 'long' and not sal_Int32? Note that
'long' is not necessarily any "longer" than 'int', so if we don't want
to use (the admittedly ugly-looking) 'sal_Int32', why not simply
'int'?)
Change-Id: I8d27b43b64eaed86dd95eb89866db8d5680cc60b
