From "tdf#124603 sw: pressing Up/Down triggers pending spell
checking", only assert GetWrong() after moving cursor out of bad word.
Change-Id: I0e722e5c56713fe1a2a7c672d7aab76438d1727f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144202
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
As described in the comment in the above code, CGBitmapContextCreate()
and CGBitmapContextCreateWithData() will try to access pixels up to
mDirtyRect.x() + pixmap.bounds.width() for each row. When reading the
last line in the SkPixmap, the buffer allocated for the SkPixmap ends at
mDirtyRect.x() + mDirtyRect.width() and mDirtyRect.width() is clamped to
pixmap.bounds.width() - mDirtyRect.x().
This behavior looks like an optimization within CGBitmapContextCreate()
to draw with a single memcpy() so fix this bug by chaining the
CGDataProvider(), CGImageCreate(), and CGImageCreateWithImageInRect()
functions to create the screen image.
Change-Id: Ic83f6162f8eb63de22693c0c40015da3b88aee65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144194
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Revert two commits[1][2] that are related to fixing tdf#135991
( but keep the unit tests) and rework the solution.
Cases related to IsNeighborFrame() imply either IsCellFrame()
( a table cell ), or IsColumnFrame() ( a column inside a
section ). Original patch[2] affected both of tables and
sections. Try to limit the affected case to the section
so it does not affect table layout for tdf#152031.
[1]
1bf82b26ae
Author: Mark Hung <marklm9@gmail.com>
Date: Fri Sep 9 16:09:47 2022 +0800
tdf#150642 fix table layout with vertical writing.
[2]
1e21902106
Author: Mark Hung <marklm9@gmail.com>
Date: Sun Aug 14 15:23:14 2022 +0800
tdf#135991 fix unexpected hidden RTL sections.
Change-Id: If50e2b50b47352dad8eafebd6cce0af0530abefa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143317
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
I reviewed the effect of the recent change to how showingPlaceholder
status was reset. It really didn't have any effect that I could find,
but the code review resulted in these minor improvements.
Change-Id: I4ba8da694c1dd4a4e7c77fe0cf20e5a5082564df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144134
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
when the mouse pointer is over comment content type and content entries
in the Navigator content tree
Change-Id: I81f8667231fe0e94f0b81c4c2d4955ba17aaa3da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143979
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Current the .uno:InsertBookmark command allows inserting a bookmark with
a provided content into the document, but an existing bookmark can't be
updated similarly. This is a problem in case Zotero citations are to be
modeled with bookmarks.
Another trouble is that bookmarks don't have dummy characters, so we
need to be careful to replace the content in a way that maintains these
bookmarks, a naive delete + insert will collapse them.
Fix the problem by introducing a new .uno:UpdateBookmarks command,
somewhat similar to what commit 7765b442e1
(sw: add a new .uno:TextFormFields UNO command, 2022-11-28) did.
As usual, the provided new text is meant to be HTML, which allows
multi-paragraph, formatted content.
Change-Id: Id5bb3fd2fd9e147d98709b5a7e0c322e73c6d283
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144167
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to 07a7f0f505d659779dfe7d344e65fd47d38f111e
- Document new FilterFormula and FilterScope arguments in SF_Calc service
This patch updates the ScriptForge's Calc service to document the FilterFormula and FilterScope arguments that were added to the following methods:
- ClearAll
- ClearFormats
- ClearValues
- SetCellStyle
Change-Id: Ice17a37ca49576f07be7f57800b11050054d90b3
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/144057
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
... with change tracking enabled.
Corner case where there are no extents for the node but the deletion is
in a single node (i.e. delete from node start to node end).
Make this consistent with what happens without change tracking.
(regression from commit 28b77c89df)
Change-Id: Ib63c4108c86c36508e1a378824ab3511dc46ae47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144109
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... if SwTextNode content changes; for the unit test here we get:
Error: elements in iterator range [first, last) are not partitioned by
the predicate __comp and value __val.
Also, the SwTextNode may have multiple text frames on multiple pages.
Change-Id: I05d4276e4b4b94fe3cd2cdfda3418ad51fa08f5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144108
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The current implementation will ignore slow zoom gestures because each
event may result in zoom change of less than 1% which will be truncated
to zero during floating-point -> integer conversion.
Storing accumulated amount and changing the zoom level once a whole
integer quantity is accumulated solves this problem.
Change-Id: If27a88d7695d0eed241dada5a09b25b2cb577841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143751
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Both sfx2::XmlDump and css::qa::XDumper were (only) used to dump various data
from ChartModel and ChartView instances in debugging (e.g., F12 and Shift-F12 in
an SW_DEBUG=1 Writer) and testing scenarios. The problem with XmlDump was that
it was used as the target of a dynamic_cast from a UNO type, which is dangerous
(see the upcoming commit introducing loplugin:unocast for details). One fix
would have been to replace that dynamic_cast with a use of XUnoTunnel, and make
ChartModel and ChartView implement that. But those classes already implement
XDumper, so it looks more natural to use XDumper for that purpose too.
However, the information that was obtained via XDumper was rather different from
the information that was obtained via XmlDump. So make an incompatible change
to the (unpublished) XDumper, adding a kind parameter distinguishing the
original behavior of XDumper (kind == "shapes") from the original behavior of
XmlDump (kind == "").
Change-Id: Ia7379bedfc45ab62a298fdc2f030cebaf21c4885
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144145
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Cursor invalidation message shouldn't carry a hyperlink info to online
side if there is no hyperlink under the cursor
Change-Id: Ibdb6e32d029e101212d03bc117a5a14a712822ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143986
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I1b0e544145c364cb9ee669b913132f41c1a8a66a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144147
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I8014f683b939da9d638545c77dbddb3e478a385e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144143
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Update helpcontent2 from branch 'master'
to 970907045a2400da7ed6e3d14ef76f7ad3b2d783
- Fix prepending xargs to gb_ExternalExecutable_get_command, help part
...as was done in f048f02f505704a76c4f01b4ff3f369e8ed928b5 "hid2file.js
generation: process in batch, not each file one-by-one", causing my build to
fail with
> [XSL] CustomTarget/helpcontent2/help3xsl/hid2file.js
> xargs: LD_LIBRARY_PATH=/home/sbergman/gcc/trunk/inst/lib64:/home/sbergman/lo/core/instdir/program:/home/sbergman/lo/core/instdir/program: No such file or directory
Change-Id: I94ea42878de55a887e6955b350997425438bb90e
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/144154
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as was done in
<https://git.libreoffice.org/help/+/f048f02f505704a76c4f01b4ff3f369e8ed928b5%5E!>
"hid2file.js generation: process in batch, not each file one-by-one", causing my
build to fail with
> [XSL] CustomTarget/helpcontent2/help3xsl/hid2file.js
> xargs: LD_LIBRARY_PATH=/home/sbergman/gcc/trunk/inst/lib64:/home/sbergman/lo/core/instdir/program:/home/sbergman/lo/core/instdir/program: No such file or directory
Change-Id: I5a58874aa746de13cfc86b691c11349196092dce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144151
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I4ecaa3cfafbb2e01ede956e4f3f6d58f40bdbb57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144146
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: If35b179b83383d8252a356c5bf43ae6ebb1d63f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144148
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I962b2a11a6407a543fb8b4ad972128d59f62a8a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144142
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Iee184c75fb5d4a8f00b932c001df023de795c469
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144144
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ibc2511c8521923c854e4b450649ea616581af2fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144141
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Thorsten Behrens