This reverts commit e20d2de783
* DeepL is just one platform, and not open
* The function requires an account
* Implementation is experimental and not maintained
* Better solution via extension exists
* Decision to revert made at ESC on 2026/Jun/11
Change-Id: I74974671b1fbed6b3299f3532bd6f9263d65927f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206367
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
cache the information we need from the dictionary, so we avoid repeatedly calling
LinguLocaleToLanguage in SearchDicList for every single word we spellcheck.
Shaves 17% of the temporary allocations
Change-Id: Ie28dab4224a35ec703ff7f698e9ea89775594c74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198281
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Add new minimum character limit paragraph property to limit
hyphenation left to the compound constituent boundaries:
com::sun::star::text::ParaHyphenationCompoundMinTrailingChars
– With the previous option for the hyphenation right to the
constituent boundary, this new option allow to limit or disable
hyphenation completely inside the compound constituents, or
hyphenate only at constituent boundaries, with or without
inside the suffix of the word or constituents;
– xmloff: add "no-limit" to loext:hyphenation-compound-push-char-count
and loext:hyphenation-compound-push-char-count;
– "no-limit" values of this and the *LeadingChars option mean
a maximum value. When both *LeadingChars and *TrailingChars
got "no-limit", hyphenation before and inside the suffixes are
forbidden, i.e. it is allowed only at constituent boundaries;
– textflowpage.ui: set max character count to 99, in both options;
– fix ParaHyphenationCompoundMinLeadingChars implementation for
compound words with multiple constituents, when the middle word(s)
are shorter, than the limit (e.g. Hungarian "tűz|kő|pattintás"
wasn't hyphenated as "tűzkő-pattintás", only as "tűz-kőpattintás").
Follow-up to commit 3a332d9f1c
"tdf#158885 cui offapi sw xmloff: fix hyphenation at stem boundary"
and commit c899d3608d
"tdf#158885 sw: don't hyphenate right after a stem boundary".
Change-Id: I0b71562727332217364f9ace85e8ac6ea3abc8b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196345
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Accept compounds separated by hyphens, when some (or all) constituents
of the compound come from the custom dictionaries.
For example, when "CustomWord" added by the user to one of the custom
dictionaries, now "CustomWord-based", "CustomWord-CustomWord",
"CustomWord-based-CustomWord-like" etc. compounds are accepted.
Note: the recursion used by the algorithm is limited by the maximum
allowed word length during spell checking (100 characters).
Change-Id: Ie2e19714ad10b3c7436a442ca8c8775e673da579
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196271
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
linguistic: Abbreviations in the custom dictionary
were accepted without the terminating dot, too
(because bSimilarOnly comparison used by getEntry()
removes all terminating dots during the dictionary
look up.)
Because "Add to [custom] dictionary" always removed
the terminating dot, and direct editing of the custom
dictionaries is still not so comfortable, the following
user-friendly options were implemented for the
abbreviations:
– spell checking dialog: words with multiple dots
– e.g. F.A.C.S. –, are always added to the custom dictionary
with the terminating dot to reject the bad abbreviations:
"e.g", "F.A.C.S" etc.;
– context menu: add optional menu items to the context menu
of the abbreviations to put the word with the terminating
dot into the custom dictionaries, e.g. for the word "Corp.":
* standard.dic (Corp)
* standard.dic (Corp.)
as menu items of the the Add to Dictionary submenu.
Change-Id: I54532c0a63af8effe9f103e75e853703d7d57563
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196263
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
I don't know if this is possible (but the response is from an external
server, so untrusted and may potentially be anything); just make sure
we don't crash below, trying to access the first result of none.
Change-Id: Iabd6b31b558c91ae435d552594ae24662826e319
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196256
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Replace by operator[], begin() and end(), which don't have overhead
since commit 2484de6728 (Remove non-
const Sequence::begin()/end() in internal code, 2021-10-15)
and commit fb3c04bd19 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: I221470b3439bb0dc6e7705b0d99deb3cd2063484
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195176
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Similar to commit d25de4a046 (silence
unknown property 'HyphNoLastWord'... etc warnings, 2024-06-10), and
commit f8b9cd8fd1 (tdf#165354 sw xmloff:
implement HyphenationKeepLine – part 2, 2025-03-03).
The new property was introduced in commit
7d384fb1c2 (tdf#165984 sw cui xmloff:
add Paragraph/Column/Page/Spread end zone, 2025-04-01).
Change-Id: I89d5fbc78041e3a94ddc2fc4efb0f8e43cc6d7c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193855
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This is a followup inspired by duplicate bug tdf#73964,
enhancing 24.8.0's commit ee6bf912d6.
tdf#161637 linguistic: fix apostrophe in spelling suggestions
At the start of spell_Impl we used the local's quote
GetLocaleDataWrapper( nLanguage ).getQuotationMarkEnd()
and replaced it with an ascii apostrophe for dictionary checking.
It only makes sense to use that same quotation in reverse
instead of hardcoding a European U+2019 endquote.
Change-Id: Id45a58cc7f9adbb2c1ae8bee7f1fe3ede07ca9c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192759
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
not clear to me why this happens, xFactory is null before the throw
in GetAvailableGrammarSvcs_Impl() and apparently non-null after, but
a lldb watch refuses to capture when/if it changes.
expanding the ternary into if/else + set appears to work. Rewrite
these three cases with a shared helper template to make it smaller
and possibly prettier and avoid the problem on macos.
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=257, address=0x2e006e00750073)
* frame #0: 0x0000006e00750073
frame #1: 0x00000001482b2910 libmergedlo.dylib`LngSvcMgr::GetAvailableGrammarSvcs_Impl() [inlined] com::sun::star::uno::Reference<com::sun::star::lang::XSingleServiceFactory>::~Reference(this=<unavailable>) at Reference.hxx:114:22
frame #2: 0x00000001482b28fc libmergedlo.dylib`LngSvcMgr::GetAvailableGrammarSvcs_Impl() [inlined] com::sun::star::uno::Reference<com::sun::star::lang::XSingleServiceFactory>::~Reference(this=<unavailable>) at Reference.hxx:112:1
frame #3: 0x00000001482b28fc libmergedlo.dylib`LngSvcMgr::GetAvailableGrammarSvcs_Impl(this=0x0000000131897d50) at lngsvcmgr.cxx:1040:5
frame #4: 0x00000001482b43d8 libmergedlo.dylib`LngSvcMgr::getAvailableServices(this=0x0000000131897d50, rServiceName=0x000000014b554608, rLocale=0x000000016f871150) at lngsvcmgr.cxx:1394:9
frame #5: 0x00000001482ac434 libmergedlo.dylib`LngSvcMgr::UpdateAll(this=0x0000000131897d50) at lngsvcmgr.cxx:655:46
frame #6: 0x00000001482abd38 libmergedlo.dylib`LngSvcMgr::LngSvcMgr(this=0x0000000131897d50) at lngsvcmgr.cxx:414:5
frame #7: 0x00000001482b7740 libmergedlo.dylib`::linguistic_LngSvcMgr_get_implementation(com::sun::star::uno::XComponentContext *, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> &) [inlined] LngSvcMgr::LngSvcMgr(this=0x0000000131897d50) at lngsvcmgr.cxx:402:1
which looks like the same problem as seen in:
commit 9ee7a841d4
Date: Mon Apr 27 16:32:52 2020 +0200
linguistic: make LngSvcMgr::GetAvailableGrammarSvcs_Impl() more readable
It's not exactly clear why, but as a side effect, this makes a crash in
uno::Reference::release() go away in the --enable-macosx-sandbox case.
Change-Id: I5b04512ca8dd542a391deec62eab5262371398bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192047
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
This fixes a 7.5 regression from
commit ab0adac692
Fix everything using XCharacterClassification::getStringType()...
Prior to erack's commit, all of the character-type-flags were grouped
together. So it could be a mix of UPPER, LOWER, and TITLE_CASE.
IsUpper returned true if there was at least one UPPER and no LOWER.
return (nFlags & KCharacterType::UPPER)
&& !(nFlags & KCharacterType::LOWER);
Since it was a group of flags, any characters that were non-case
(like a fullstop) did not affect the result of IsUpper.
But when it was changed in 7.5 to
return aCC.isUpper( rText, nPos, nLen );
now every character needed to be considered to be upper-case,
even if it was a non-case character.
So this patch changes the logic back to the original state
(more or less).
The fly in the ointment are any Unicode characters
that would be considered to be TITLE_CASE.
Previously they were ignored (i.e. they didn't affect the outcome),
but now I consider them to be non-uppercase.
That seems to me to be the intent here anyway,
so probably this implementation "fixes a bug"
when a word consisted of a mixture of UPPER and TITLE_CASE chars.
See the first patchset where I added a dummy parameter
to ensure that this was still the only place
using erack's new function.
This proves it is safe to change the logic back,
since this is the only place IsUpper is called.
Change-Id: I7cf1d68bc3eb0a1a468da9e67ab54d1148f097aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187934
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Add loext:hyphenation-keep-line to the ODF export/import
to support HyphenationKeepLine, i.e. MS DOCX compatibility
option useWord2013TrackBottomHyphenation=false, where not
the full hyphenated line, but only the hyphenated word
is shifted to the next text block.
Add unit tests for hyphenation-keep-type="page" and "spread"
with hyphenation-keep-line="true" support.
Follow-up to commit 3e02ffb76c
"tdf#i165354 sw offapi DOCX: implement HyphenationKeepLine – part 1".
Fix unit test testTdf132599_spread, which loaded tdf132599_page.fodt
instead of tdf132599_spread.fodt (duplicating testTdf132599_page).
Restore unit test testTdf160518_auto_in_text_body_style, which was
removed by accident in commit 3e02ffb76c.
Silence the linguistic warning of HyphKeepLine, according to the
commit d25de4a046
"silence unknown property 'HyphNoLastWord'... etc warnings".
Change-Id: Ibb9643f8e20ee2a1456c4d62b901e4c66b57c341
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182424
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Andrea Gelmini