| Age | Commit message (Collapse) | Author |
|---|
|
The code was guessing orientation based on the start and end points and
mistakenly considered Arabic text to be 180° rotated which ended up
raising the wavy line above baseline and covering the RTL text.
Use font orientation instead of guessing it. Caching wavy line seems
broken with RTL text as well (it was skipped for RTL before because of
the wrong guessed orientation, so probably never worked), so we skip it
explicitly as well for now.
Change-Id: I4b0f5c4d6be2c6e3d33ea79b917b14927374acfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147488
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Used sal_Int32 instead of sal_uLong
Change-Id: I229c4e59054b3aa1885698d1cd5332ebd9d162d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143513
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
do it like this to avoid adding another mapmode and to keep things
"the same" as much as possible
Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I906fb6525e20933f4611b3e2d81bf3524fbaf0a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143544
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia635d83a5d3dd257948777e9f6976fecfeb4ee98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141526
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
This reverts commit 0cef06f0a2c0963e8c1579b78975710e6af4471c.
Reason for revert:
https://gerrit.libreoffice.org/c/core/+/141234/comments/89325e55_2271cfe8
> Stephan Bergmann:
>
> I saw the unrelated <https://gerrit.libreoffice.org/c/core/+/143026/1> fail its Jenkins <https://ci.libreoffice.org/job/gerrit_windows/140750/> build on tb88-win with
>
> C:/cygwin64/home/tdf/jenkins/workspace/gerrit_windows/vcl/qa/cppunit/logicalfontinstance.cxx(53) : error : Assertion
> Test name: VclLogicalFontInstanceTest::testglyphboundrect
> equality assertion failed
> - Expected: 51x82@(7,-80)
> - Actual : 50x82@(7,-80)
Change-Id: Idc4132adbaf0b051dcf955f3f1e7c44841c60117
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142928
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
MacOS produces a slightly different glyph height.
Quoting from Khaled in dev IRC:
"Currently GetGlyphBoundRect() calls different platform-specific
implementations on each platform, so even with the same font it is
possible to get some difference. So my suggestion is to use a large font
size and allow for some fuzziness".
Consequently I'm using a 110pt font.
Change-Id: I939e633eb1e45a16171ad0675216246b31966454
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141234
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This patch fixes tdf#152012 which caused an assertion failure on opening
date picker field in a DOCX file
The assertion was:
include/o3tl/span.hxx:83: constexpr o3tl::span<T>::value_type& o3tl::
span<T>::operator[](o3tl::span<T>::size_type) const [with T = const
int; o3tl::span<T>::reference = const int&; o3tl::span<T>::size_type
= long unsigned int]: Assertion `pos < size()' failed.
And the backtrace was:
1 __pthread_kill_implementation pthread_kill.c:44
2 __pthread_kill_internal pthread_kill.c:78
3 __GI___pthread_kill pthread_kill.c:89
4 __GI_raise raise.c:26
5 __GI_abort abort.c:79
6 __assert_fail_base assert.c:92
7 __GI___assert_fail assert.c:101
8 o3tl::span<int const>::operator[] span.hxx:83
9 OutputDevice::ImplLayout text.cxx:1396
10 OutputDevice::DrawTextArray text.cxx:948
11 Calendar::ImplDraw calendar.cxx:71
12 Calendar::Paint calendar.cxx:1133
The problem was caused by an out of bound access to a vector of integers
which was created for rendering calendar header consisting of the first
letters of 7 days of week, when you clicked on the down arrow on the
date field.
The function OutputDevice::DrawTextArray() takes an 'rStr' string to
draw, and 'pDXAry' array for the exact position of the the individual
characters. It also takes 'nIndex' as the first index, and 'nLen' as the
length of the array. 'nLen' has the default value of -1. In this case,
the length is calculated from the size of the string passed to the
function. This works well if the one who uses the function makes sure
that the size of the array and the length of string are equal.
Previously, for the 7 days of the week, a 7 letter string "smtwtfs"
(depending on the week start day this can be different, but length is
always 7) was sent to this method without providing the length, thus
the string length: 7 was used. In this case, positions of the letters
were calculated and used from other array named mnDayOfWeekAry[7].
mnDayOfWeekAry[k+1] was used as the position of letter k (k=0..5).
In this case, there was 7 letters for 7 days, and only 6 positions
provided by the array. This caused assertion failure in span.hxx:83
when trying to accesss mnDayOfWeekAry[7] via o3tl::span<T>::operator[].
Value of mnDayOfWeekAry[0] was used in other calculations, therefore to
fix this problem, mnDayOfWeekAry was extended from 7 to 8, and the last
position was set to the end of drawing rectangle.
The other thing that is done in this patch to avoid this problem in the
future is removing the default value from the function prototype, so
that the use should always be done by providing the length of array and
starting index. After removing these defaults, it became necessary to
provide empty arrays for 'pKashidaAry' which provides the kashida
positions, if needed.
With this fix in place, the assertion failure no longer happens.
A UI test is added to make sure the crash will not happen again. The
test can be run by invoking:
cd sw && make -srj1 UITest_writer_tests5 \
UITEST_TEST_NAME="DateFormFieldPropertiesDialog.dateFormFieldDialog.test_date_picker_drop_down" \
SAL_USE_VCLPLUGIN=gen
Change-Id: I347afb358fbc4956524f7f0a0abc3a221bf42992
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142642
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
which have served their bootstrapping purpose
Change-Id: I04b832fde21e4932ed191d972737bee97510f53a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140903
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I66f96a305bb095716023ae1e565950971826bce0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140242
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
AllSettings is just a cow_wrapper, so no need to allocate this separately
Change-Id: I8f7705d55ab70da209d1383f3812249e0750df5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139740
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It makes more sense for an emphasis mark to be an object that can be
queried, than it is for it to be a function with lots of output
parameters.
I have added a unit test, note that for now something doesn't seem right
with polypolygon equality checks (test fails, but the disc is generated
the same way) so not testing the shape creation.
Change-Id: I7597603419b69639b8d9764afdb68e266da7a56b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122601
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Previously, when measuring caret position, Writer would measure the
width of the substring before the caret (i.e. layout it independent of
the text after the caret and measure its width).
This is incorrect, though. It assumes cutting the string laying it out
would result in the same width as when laid out as part of a bigger
string, which is invalid assumption when e.g. cutting inside a ligature
or between letters that have different shapes when next to each other,
etc.
This appears to work when the width of the substring laid out alone is
close enough to its width when laid out with the full text. But in cases
where is widths are largely different, like the extreme case in the bug
report, the caret will be jumping around as it is positioned based on
the unligated glyphs not the ligated, rendered glyphs.
This change introduces a special mode of measuring text width for caret
positioning, that will layout the whole string that return the width of
the requested substring.
Fields and small caps text are trickier to handle, so old behaviour is
retained for them. Now one will probably notice but if they do, it can
be dealt with then.
This also tries to be conservative and keep other pleases using the
existing behaviour which might be desirable (e.g. when measuring text
width for line breaking, we want the unligated width), but there might
be other places that should use the new behaviour.
To handle caret inside ligatures, the grapheme clusters in the ligature
are counted and the width of the whole ligature is distributed on them
evenly. A further improvement would be using HarfBuzz API to get
ligature caret positions for fonts that provide them, which helps when
the ligature components have different widths.
Change-Id: I02062e2e2e1b1a35c8f84307c0a8f5d743059ab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138889
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Always render glyphs with a mode suitable for rendering of
resolution-independent layout positions if we scale the text positions.
The idea being to typically continue to use the system defaults for font
settings for UI elements, but where we are rendering into application
canvases where there's a mapmode set then automatically use a good mode
to render that.
Change-Id: I0e5857e377da72ae1a2ede1d88d6408819fc9200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138324
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Renamed GetNonMnemonicString() to removeMnemonicFromString()
Change-Id: I272714f97bb6d9174360631c18c4fd9bb485698e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138103
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If5a8624c1150919cc66f7b7d635edf112b480523
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138738
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5378169e2c1d4d15fa160c3c2d2a130556dc80b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138747
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Icab3c11d6968efbbdb0f9f7f1dfeba2709e22a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138746
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I958296225c5491a2cd78d64fb16d079272d7c28d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138140
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If19db43248d9144f83a205890b3a00a23fcb6267
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138040
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Communicate Kashida insertion positions in an explicit way.
Rest of LibreOffice communicate adjustments to character widths (e.g.
for justification or spacing) using so-called DX array. DX array is an
array of absolute character positions (e.g. DX[n] is the position after
character n from the start of the lines, and its widths is DX[n] -
DX[n-1]).
This DX array is modified also when Kashidas are inserted after a given
character for Arabic justification, by expanding its width. VCL would
use this to know where to insert the Kashidas and how many ones.
But because DX array is used for both widths adjustments and kashida
insertion, this turns out to be a source of bugs since VCL has tosecond
guess the DX array to find which is pure width adjustment and which also
involves Kashida insertion, and the heuristics it uses are fragile.
This change adds a second array of booleans that records where Kashida
is inserted and communicates it all the way from where Kashida insertion
is decoded in Writer and down to VCL layout.
This change passes the Kashida array only when it seems necessary (e.g.
during drawing but not when measuring text since the DX array is enough
in this case). Hopefully no places where Kashida insertion needs to be
passed down were missed.
A couple of glyph and layout flags that were used for old heuristics and
no longer needed and are removed.
This also fixes:
tdf#87731
tdf#106309
tdf#108604
tdf#112849
tdf#114257
tdf#127176
tdf#145647
tdf#146199
Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
GLYPH_FONT_HEIGHT not used since:
Commit: d538d3d84172a74dfe97d59a6d3daf9a45459cab
Short title: This fallback code makes no sense any more
Change-Id: I9c87e2fb2eb33abbc2a7e4d82435704f1a895c75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137631
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
For some reason it may differ even if vcl::Font is the same.
Without this ScExportTest2::testTdf66668 fails.
Change-Id: I728a0848ac0420ce0d746134c7072f6ab59f2761
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133537
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
SalLayoutFlags::BiDiStrong would be set by ImplLayout() if the entire
subset had no RTL, but the entire string may not be that, so when
creating a subset make sure to also set this flag. Similarly
SalLayoutFlags::KashidaJustification should be set only if any
glyph in the range has GlyphItemFlags::ALLOW_KASHIDA.
Change-Id: I0aa2526f2fdd0c6a6b905ad0cb4040ee556529a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133502
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
We use the AddTempDevFont() API to add a new font. Sadly there is no
corresponding way to remove such a temporarily added font.
Change-Id: I6fe61919daa5af29e964cec1caf7293aefa8ea4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132948
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I278e485e03cf27bc57724233453a672569dfd53f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132682
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The result depends only on the string, so it's possible to cache it
easily, and caching this for text drawing calls can have a good
hit rate.
Change-Id: I56c6e254cc176ab07afe0df24ed37b19579fe64d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131556
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I8d88558be5bcf4556d94ab86015f5e039e72da08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131503
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The (private :( ) document contains a large number of small shapes
for which VclProcessor2D::RenderTransparencePrimitive2D() gets
called, which results in GetBitmapEx() on the VirtualDevice.
And Cairo normally needs to do a roundtrip to the XServer to fetch
the content, which makes the rendering pretty slow. Forcing
image-based surface for small sizes of VirtualDevice actually has
better performance for the document, and the lack of possible
HW acceleration generally shouldn't matter for a surface this small.
Additionally drawinglayer's VirtualDevice reusing tries to reuse
even a large one when a small one is needed, so a hack is needed
to avoid that in this case, I couldn't find a better way.
Change-Id: I0f58659ab88165a6bd915f100fc3b1d4802a0fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128309
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ied157d8d4bc9b57cfa17716453189ddf48cba641
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128485
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I16a585abf4805d87a2eeb4e3e9d9bd9f2697b838
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128472
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
When rendering in ResolutionIndependentLayout mode keep the scaled
glyph positions as floating point all the way down to the renderer
Change-Id: I02415f18c26737a886751972f472b499a25c776b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128379
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6b8c815fda3a48917467719432071c0716e3e9ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127338
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
no logic change intended
Change-Id: Id24fb2647e2e6c00a485165edd7fc265ad090c23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128373
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I815fb3ce366c93b81f60d19eeed906dc7288708a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127030
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
No need to have split out the function, we can just check the gradient
style type. However, if we are checking the steps for a metafile we can
make this a static function.
Change-Id: If0524567ec5974db92aff928e0733ab746ecbeba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127029
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7.
Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff
Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Unfortunately the add/usage of HasFastDrawTransformedBitmap did disable the
system-dependent implementations/fast-path for DrawTransformBitmapExDirect
and it's implemenations, except for Skia.
This means that the current backends for Windows/Mac/Cairo/headless/Qt5
have to do expensive pixel operations when a Bitmap is 'really' transformed
(rotate/shear) since some time.
The nine implementations using ::hasFastDrawTransformedBitmap (grep for it)
all return false, except the Skia one.
Since HasFastDrawTransformedBitmap() uses that and itself is used in the very
central mehod OutputDevice::DrawTransformedBitmapEx(...) to decide if that
fast-path shall/can be used at all, it was *no longer used* - except for
Skia - what makes Skia definitely performing better with transformed Bitmaps,
or the other way around - the others worse.
HasFastDrawTransformedBitmap() is used in only two places, the second is in the
canvas helper to decide if to try to use that fast-path for presentation
rendering.
A method at OutputDevice to see if that fast-path is implemented is therefore
currently needed, but for the canvas helper only. Since this will/should be
converted to primitive usage (hopefully) anyways, nine impementations calling
these virtual functions often and the danger to produce a mismatch/
error beween implementations of hasFastDrawTransformedBitmap and
drawTransformedBitmap (as happened here, but can also happen when someone
adds or removes an implementation) I looked for a way to solve that differenly
and more safe.
Since SalGraphics::DrawTransformedBitmap anyways returns a bool to signal it's
success I take this as base to implement a buffered test directly at
SalGraphics, also directly set a local flag to detect that functionality if
DrawTransformedBitmap is used anyways before the test is/would be needed.
Combined wih that small test to check only if this was not yet used and thus
tested by DrawTransformedBitmap anyways I can offer a reliable non-virtual
method at OutputDevice called ImplementsFastDrawTransformedBitmap() that will
be used at the single necessary location - in the canvas helper.
Since that small test direcly uses one of the nine implementations of
hasFastDrawTransformedBitmap it is fundamenally more reliable and probably
the copy bitmap/writeBack never really used (I tested that it works) due
to an earlier use of DrawTransformedBitmap did the check potentially already.
I also took a look at the cairo version (since I had this one running here)
and ensured that the buffering of the system-dependent form of the Bitmap
as cairo surface still works. Regarding the newly introduced fAlpha
parameter I want to add some remarks:
- It should be called fOpacity to make clear that it describes opacity,
defining that if 1.0 == fAlpha means *no* transparency. That word is
used in other graphic systems and makes more clear what function it has.
It is the opposite of transparency, but works the same.
- Currently all implementations of ::drawTransformedBitmap - except Skia
where it was implemented - do not use it, but return false. It will in most
cases not be too complicated to add/implement it, e.g. for cairo anyways a
transparency surface will/is created, fAlpha can just be merged in, and the
criteria for buffering that may be extended to remember for which value
(if at all) of fAlpha that was prepared. I strongly recommend implementing
these for our main graphic backends.
- The primitive renderer uses another more general way to add an extra alpha
channel to paint when needed - it draws the content (any content) that needs
to be transparent to a buffer and then that buffer using the intended
transparency. This is discussable since may be more expensive, but more
general and keeps the interface less complex. We can see here that adding
that complexity to the existing interface at OutputDevice makes the
implementations more complex what might be the reason his was only
implemented for one of nine backends. When adding something like this and
extending the complexity I would prefer that at the same time it gets
also *implemented* in all or most or at least most used cases. I want to
make clear that from my POV in those cases choosing possible runtime speed
over complexity is not always preferable.
Change-Id: I5bab59f59fca878a7b11a20094e49e8b50196063
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126480
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ieb0d5d6f1a7c9fff3671ef74ffac9eaf37dcb0e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123060
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I45cff1f3182fd17776281d1daf49477077779ebe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125099
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Solves accessibility issue of too faint spellchecking indicators
Change-Id: Ic5bc9e205981e90c8f4ee12aa52dde723da1e7aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125038
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
A document specifies which font each text is supposed to use,
but we still need to map that to a real available font, which
includes also font fallback in case the font selected doesn't
cover all glyphs.
This commit adds API to track this font mapping, first
StartTrackingFontMappingUse() will make VCL record this
information, and then FinishTrackingFontMappingUse() will stop
and return all the information, as a listing saying that
a requested font got mapped to a list of fonts and the number
of times this took place. This can be useful to find out
what actually gets used for a specific document, or compare how
changing fonts available affects a specific document.
Change-Id: I6426ecef354166bef337b1dc9b9007fda148d5c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123051
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I26ad2727dbc258a49e7f370167b80e98438a50e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124494
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id3f037e132a4d07cb2b68dbb93dd24f7f6b33ab6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124461
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I36ddc11b39763dc77086591fe9bb756195b4294f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124459
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we get bounds checking in debug mode
Note that I cannot just pass around the std::vectors
involved because there is a place in editeng which
calls with a subset of a vector.
Change-Id: I5088a139593c27bf9cbe5d843ab4b0048ac6d508
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124330
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If we are filling *and* drawing border then we do the border
transparently, but if we're not filling we draw the border
without transparency? I can't see that this is intentional.
Change-Id: Idf8d84bed7f93b1fc4ee05ea56bc10c5e5c6e875
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124261
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
use the clip rectangle to stop early when the text exceeds the height
of the cell
Change-Id: I63dadc5b63c1f6c0852e0ba86a58f18c2b207cca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124221
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iefbbcb186b2811748abf49546351a2c68e8af462
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124155
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
