When OutputDevice::ImplLayout() computes glyphs, the result
is always the same for the same string (and font etc.),
and if the function is asked to work on just a subset of the string,
the returned glyphs are often also a subset of glyphs for the full
string. Since e.g. EditEngine breaks text into lines by first
laying out a full string and then repeatedly calls the same function
for a subset of the string with increasing starting index. So if
the full result is cached, it's faster to just make a subset of that,
adjust it as necessary and return that, instead of doing a layout
again.
This requires support from harfbuzz to tell us if it's safe to break
at a given position, and HB_GLYPH_FLAG_UNSAFE_TO_BREAK is that
(https://harfbuzz.github.io/harfbuzz-hb-buffer.html#hb-glyph-flags-t).
I'm keeping the optimization for tdf#144515, as avoiding the extra
layout altogether is still useful.
Change-Id: I33f70f9af89be79056e464908eac0861f58d274a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132753
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Changes to: Move Chapter Up, Move Chapter Down,
Move Chapter Up with Subpoints,
Move Chapter Down with Subpoints
Also capitalization correction ("With"->"with") for
Demote Outline Level with Subpoints in Bullets & Numbering
toolbar and menu.
Change-Id: Iacb0e798c54bf4101f7048454007bf58ec4081c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132869
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
For !LIBO_INTERNAL_ONLY, go back to the state before
d91d98a53612a972de368186415aa48698e074d9 "fix gcc-4.0.1 and/or 32bit build for
string literals" of having just a sal_Int32 overload. (For !LIBO_INTERNAL_ONLY,
the current state was confusing, as the existence of further overloads depended
on __cplusplus >= 201103L.)
And for LIBO_INTERNAL_ONLY:
* Have overloads for all integral types, with an assert checking that they do
not use out-of-bounds length arguments. (The std::make_unsigned_t dance in
the assert is needed to avoid signed/unsigned mismatch warnings as seen at
least with MSVC.) This removes the need for explicitly casting arguments that
are larger than (unsigned) int. (And I cleaned up two such places that I had
become aware of with the abandoned previous attempt
<https://gerrit.libreoffice.org/c/core/+/132825> "Let O[U]StringBuffer ctors
take sal_Int32 length parameters"; there may be more places to clean up,
though.)
* Have deleted overloads for all integral types that are not actually integer
types. (This excludes signed char and unsigned char, as at least
> OUStringBuffer aBuf( rToken.GetByte());
in ScTokenConversion::ConvertToTokenSequence in
sc/source/ui/unoobj/tokenuno.cxx does a legitimate call with an argument of
type sal_Int8 aka signed char.)
Change-Id: I2df77429f25b74f19cc3de5064e6fd982e87b05e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132951
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... and in any case abort authentication after 10 failed attempts.
Apparently some PasswordContainer can turn this into an infinite loop.
Change-Id: Ib2333b371a770999e8407ce7e1af21512aadb70d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132974
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
After Change-Id I15ecc2eba6c5ee441f6e14f8229594cab05dbba7
"tdf#148556 android: Don't delay refresh when loading doc",
the only thing that `LOKitThread#loadNewDocument` does
in addition to `LOKithThread#loadDocument` is to save the
newly created document (to a temp file) if loading was
successful.
So, have `loadDocument` return a boolean saying whether
loading was successful and call that method from
`loadNewDocument` to reduce duplication.
Change-Id: I9b99e011b3f5105bb60f95174de393462ff08271
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132966
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The previous way of using a separate Runnable
to do the refresh and posting that to the
main handler instead of doing the refresh
right away resulted in a timing issue, due
to which it could happen that a Calc document
would not be rendered when initally loaded
(but only after another tile reevaluation was
triggered, e.g. by tapping on the screen).
While this appears to happen mostly on fast hardware,
I could reproduce on my AVD as well when increasing
the minimum time that has to pass between
tile reevaluations to 100 ms:
--- a/android/source/src/java/org/mozilla/gecko/gfx/ComposedTileLayer.java
+++ b/android/source/src/java/org/mozilla/gecko/gfx/ComposedTileLayer.java
@@ -157,7 +157,7 @@ public abstract class ComposedTileLayer extends Layer implements ComponentCallba
}
long currentReevaluationNanoTime = System.nanoTime();
- if ((currentReevaluationNanoTime - reevaluationNanoTime) < 25 * 1000000) {
+ if ((currentReevaluationNanoTime - reevaluationNanoTime) < 100 * 1000000) {
return;
}
For the bad case, the Runnable that triggers the
refresh would be taken from the message queue and
run on the main thread at a point in time that
resulted in `LOKitShell.sendTileReevaluationRequest`
not getting called in `ComposedTileLayer#reevaluateTiles`
due to the above-mentioned minimum time in between
tile reevaluations.
Avoid the problem and simplify the whole handling by
no longer posting a Runnable to the main handler, but
calling `refresh()` right away.
Posting to the main handler had been introduced in
commit 27326e0f587c20d8dcf1595829233de1bd3fbe9e
Date: Fri Aug 3 07:13:00 2018 -0700
tdf#119082 Exception wrong thread on Android Viewer
to avoid crashes due to things being done on the wrong thread
when switching to another app and then back to Android Viewer
(s. tdf#119082), but that is no longer a problem, because the
document is no longer loaded anew in that case since
commit 1bc42472200c32c9a0a10dd1c3cd6c6a8a5d47d2
Date: Fri Apr 9 13:59:43 2021 +0200
tdf#95517 android: Rework app/doc lifecycle handling
, so the code path is not used there any more, but only when
the document is initially loaded, triggered in
`LibreOfficeMainActivity#onCreate`.
After all, the problem seems to be a similar one as fixed in
commit 128f67e0efa02294205a1abe1be874557ecdcecd
Date: Tue May 18 14:27:51 2021 +0200
tdf#142348 android: Avoid extra refresh after loading doc
, where another timing issue in the handling of a refresh event could
result in a blank page instead of the Calc doc being rendered.
With the refresh being done right away, the synchronization added
in
commit 55661298bb3e9087a89a08637e4285f090c4e0e8
Date: Wed Apr 1 09:00:13 2020 +0200
tdf#131195 android: Don't destroy doc while loading it
is also no more needed, because the situation described in its
commit message no longer applies:
> Since the 'refresh()' in 'LOKitThread::loadDocument' is
> not executed synchronously but posted to the main handler,
> this needs to be synchronized to prevent the document from
> being deleted while it's being used.
Change-Id: I15ecc2eba6c5ee441f6e14f8229594cab05dbba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132965
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Empty SalLayoutGlyphs is considered invalid, because otherwise
it should have at least one *Impl, but an empty *Impl is apparently
possible if it's a fallback but it doesn't find a single glyph.
This avoid the warning in OutputDevice::ImplLayout(), triggered
e.g. by CppunitTest_writerperfect_writer.
Change-Id: I410d269b07ffb73f9860806ede9cd0b809668342
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132968
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* Add information on dumping drawyinglayer primitives as xml
* Add link to a new tool named limerest on gitlab
Change-Id: I50a0018d9c3063281b2a761d437bb9def0f34bde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132936
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
instead of two GetDeltas() one of which is non-const and returning a
reference that can be used to modify the delta
no logic change intended
Change-Id: Ia5788bfffd169a589eb9b9b141b60575ab165391
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132953
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This centralizes the code that handles templates, and allows the empty
files to use default templates.
This partially reverts commits:
ada07f303e7cd1e39c73abe0741aefe7d9d73a57
Author Miklos Vajna <vmiklos@collabora.com>
Date Wed Oct 28 14:54:52 2020 +0100
tdf#123476 filter: try to detect 0-byte files based on extension
2854362f429e476d4a1ab4759c6a1f1c04150280
Author Mike Kaganski <mike.kaganski@collabora.com>
Date Wed Jan 27 16:05:54 2021 +0100
tdf#123476 filter: Also handle empty ODF
dff586735b6618d9b011823594a33287d8f7f223
Author Mike Kaganski <mike.kaganski@collabora.com>
Date Mon May 03 17:04:04 2021 +0200
tdf#123476: also use filter by extension when its service is the same
The unit tests from these commits are retained and extended for templates.
Change-Id: I755738d2d5a6d6955d84d6e12f3accc017e0391f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132938
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@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>
Writerfilter already did this earlier in the patch set.
So now change DOC format to do all the same things.
Change-Id: I8db2b4e3fc227b73c4d075ee624117e1b1f1d92e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132663
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Once the DOCX import maps Run SDTs to SwContentControl,
make -C sw -sr CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testTdf148361
starts to fail without this fix. Previously we only tested
SwContentControl end in the middle of a paragraph. Fix the paragraph end
case similar to how hyperlinks are handled to be consistent.
Change-Id: I0633ca8d7d909a2cb3c70e7edce3a85df5fac3f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132944
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
My Kate editor decided to do some whitespace cleanup, but maybe
it's fine as the main changes are not targeting functional bits anyway.
Change-Id: I5292e77e43055f94a6256a7f72d49fd59287d194
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132928
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
If cairo is available we override drawPolyPolygon and drawPolyLine
with an implementation that uses cairo to draw instead of X11.
This override was previously done in X11SalGraphics, but as we want
to have all the drawing in backends (SalGraphicsImpl children) this
also needs to be moved to one. In this case we can just derive
X11SalGraphicsImpl and implement specifics there. As there is some
common stuff now betwee X11SalGraphics and X11SalGraphicsImpl,
also add X11Common, which includes those.
Change-Id: Id1e0c5227506e03d3dd0f937e4ef50d69b17bb22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132827
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
As said in the previous commit, the default pattern is the default
style that can be edited by the user, so it's principially incorrect
to simply ignore it. If needed for performance, then it needs
to be done explicitly. This change currently should not affect
anything, as ScHorizontalAttrIterator is used only in tests.
Change-Id: I31f153d427cdfd6e98a4d7a3584cfa89676d4c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132912
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Even ScDocument::GetDefPattern() can be modified by the user (it's
the default style that can be edited), so it's conceptually
incorrect to ignore it while iterating, and clamping to allocated
columns is also no longer needed. If this makes some code slow,
then that needs explicit handling in that code or some other
way of speeding things up.
Change-Id: I4a7c7fef0a8625b559bbce4580df19a5e9ed92a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132911
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The testcase has a very long text in a cell that is really high
enough to hold only one line of text, yet EditEngine formats and
wraps the entire string. Which can be expensive because of calling
into text layout to find out width of a text portion, and this
is done repeatedly for the yet-unformatted text, so pretty much
O(N^2). For top-aligned text it's enough to format only as much
as will fit and ignore the rest, so implement that and add
EditEngine::EnableSkipOutsideFormat() to enable the optimization.
Change-Id: Ida87a1843737a368798ba2b3e60eedc99ee0f611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132932
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
For cells it normally looks better to align them to the bottom,
but if the content doesn't fit, it looks better to align to top,
because that shows the start rather than the end of the content,
and it also logically goes together with the clip mark shown
to the right of it.
Change-Id: Iac51e9e59d5ab9f5c89374a3e638a4a572f8b1fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132931
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
so use our own replacement when we want to continue to use a cairo_surface
Change-Id: I4a1a0e7f5a86d27a4290cf71c0719ea017be3f0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132930
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
before "CairoSurface" can be resolved to its type, this worked in gtk3
because there was some fallback code which guessed what function name
was needed to call to get it, but that's not present in gtk4
Change-Id: I85a957ecd37e0e7a572578e8273152fbb19dac3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132920
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
