Age | Commit message (Collapse) | Author |
|
Don't use our own char.txt.
Quite possibly we wouldn't need to use the other data in the
i18npool/source/breakiterator/data folder either. See the README file
there for the sad details.
Change-Id: I82923ae76407fdd3fa3642d818d43427fe4f5591
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106632
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I95fe065f4dcbe9d7bab105944ba4f835e80718ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105678
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
During text search, ASCII apostrophe ' (U+0027)
of the search term matches the typographic
apostrophe ’ (U+2019) of the text, too.
There was a UX regression in document editing from
commit e6fade1ce133039d28369751b77ac8faff6e40cb
(tdf#38395 enable smart apostrophe replacement by default),
because Find and Replace window and Find toolbar
doesn't replace ASCII apostrophe, so the search term
hadn't matched the text (now with the automatically
replaced typographic apostrophes), as before the commit.
Regex search hasn't been modified, i.e. searching U+2019
is still necessary a search term with U+2019.
The typographic apostrophes of a search term only match
ASCII apostrophes of the text, if the search term contain
also an ASCII apostrophe, too.
Note: as a more sophisticated solution, it's possible to
add a new default transliteration option for this later.
Change-Id: I5121edbef5cf34fdd5b5f9ba3c046a06329a756a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105717
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...introduced with 5d8f0fad50f90195a11873c70ddab4644f5839ea "Adapt
CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)" (see
there for details) but erroneously removed with
877f40ac3f2add2b6dc37bae280d4d98dd102286 "tdf#42949 Fix new IWYU warnings in
directories [h-r]*"
Change-Id: Id22a4c0fdfe1471e2455ec3316f2c6c93cc00b22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105549
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I886b6f446293d3b1cfbf4ae05e8dbd7fabab9f20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105510
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I9366193085a4c46ef64f0a9660e51b8678ca35f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105252
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
use standard true.
/home/rene/LibreOffice/git/master/i18npool/source/calendar/calendar_gregorian.cxx: In member function 'virtual void i18npool::Calendar_gregorian::setLocalDateTime(double)':
/home/rene/LibreOffice/git/master/i18npool/source/calendar/calendar_gregorian.cxx:363:40: error: 'TRUE' was not declared in this scope
363 | body->getTimeZone().getOffset( fR, TRUE, nZoneOffset, nDSTOffset, status );
| ^~~~
/usr/include/unicode/umachine.h says:
@deprecated ICU 68 Use standard "true" instead.
Change-Id: I45d2b0afa6a9043767af5c2cf41ba24377f2cdc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105151
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
...introduced with 7a09d67e1c76db7cb6a87a2ceaa6de7325342b75 "convert some more
long -> tools::Long"
Change-Id: Ia565aea1eae4b3e03939c58f22e4263a4334ec80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105070
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I633d396bb2cbeaa6829de543fab6ce3726ad11ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104968
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9ab8876aac7b2f8b488db6dfa9c6fd0cecd2238b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104626
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which are not portable between Linux and Windows because long
is not portable.
In preparation for converting long -> tools::Long
Change-Id: I8bf1aa1570946ca887a6c83dd5f99c024d437336
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104374
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2973128a9c6c53187e1da400d1a5df763d515596
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104020
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id5a5d71b7f457d18b9d0982f9b4df95566c09be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103122
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
See https://bugs.documentfoundation.org/show_bug.cgi?id=137009#c4
Change-Id: I01612e79ffd947c1a4c0cf252d71bda48bc3ef8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103638
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I06b9479e48bfcc3421ae1ec634064f9f3209cffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103301
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...and in turn add OUString::operator = and OUString::operator +=
overloads that take a std::u16string_view. Without making the ctors explicit,
the operator overloads would have caused ambiguities when called with raw
sal_Unicode pointers/non-const arrays, as those can convert to both OUString and
to std::u16string_view.
But the std::u16string_view operator overloads will generally be useful when
changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which
point many existing uses of OUStringLiteral will be replaced with uses of
std::u16string_view.
Implementing this change turned up a need for an operator = overload for
OUStringNumber, which has thus been added. No such need turned up for a
corresponding operator += overload, but which can easily be added when the need
arises.
It also revealed that the operator == overloads between an OUString and a raw
sal_Unicode pointer/non-const array were implemented rather inefficiently,
creating a temporary OUString from the raw argument. Those have been improved.
Preceding commits have already taken care of many dubious or simply unnecessary
implicit uses of the now-explicit OUString ctors. This commit makes explicit
the few remaining reasonable uses. (And in some cases needed to change variable
initialization syntax from using parentheses to using curly braces, to avoid the
most vexing parse issue. And needed to explicitly add OUString ctors from
char16 const[2] string literal lvalues in a conditional expression in
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary
because MSVC apparently still insists on doing array-to-pointer decay there.)
All of this only affects LIBO_INTERNAL_ONLY.
Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...avoiding the construction of an intermediary temporary OUString, assuming the
given `word` will never contain embedded NUL characters.
(This change is a prerequisite for making the OUString ctor taking a raw pointer
explicit.)
Change-Id: I3b500557abb3554e9dfda63ef30b22c6c06c99c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102084
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...instead of having individual overloads for OUString, OUStringLiteral, and
literal char16_t const[N]. (The variants taking OUString are still needed for
!LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char
const[N] are also left in place.)
This nicely reduces the number of needed overloads. std::u16string_view allows
to pass as arguments:
* OUString
* OUStringLiteral
* OUStringChar (with the necessary conversion added now)
* OUStringNumber
* u"..." char16_t string literals
* u"..."sv std::u16string_view literals
* std::u16string, plain char16_t*, and more
A notable exceptions is OUStringConcat, which now needs to be wrapped in
OUString(...), see the handful of places that needed to be adapted.
One caveat is the treatment of embedded NUL characters, as
std::u16string_view(u"x\0y")
constructs a view of size 1, while only
u"x\0y"sv
constructs a view of size 3 (which matches the old behavior of overloads for
literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16
machinery). See the new checkEmbeddedNul in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx.
The functions that have been changed are generally those that:
* already take a string of determined length, so that using std::u16string_view,
which is always constructed with a determined length, is no pessimization
(e.g., there are operator == overloads taking plain pointers, which do not
need to determine the string length upfront);
* could not benefit from the fact that the passed-in argument is an OUString
(e.g., the corresponding operator = overload can reuse the passed-in
OUString's rtl_uString pData member);
* do not run into overload resolution ambiguity issues, like the comparison
operators would do.
One inconsistency that showed up is that while the original
replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0)
overload takes an optional third fromIndex argument, the existing replaceAll
overloads taking OUStringLiteral and literal char16_t const[N] arguments did
not. Fixing that required a new (LIBO_INTERNAL_ONLY)
rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in
sal/qa/rtl/strings/test_strings_replace.cxx).
Another issue was posed by test code in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the
RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that
certain function calls should not compile (and would compile under
RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to
OUString as arguments). Those problematic "should fail to compile" tests have
been converted into a new CompilerTest_sal_rtl_oustring.
Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Between <https://github.com/llvm/llvm-project/commit/
0e00a95b4fad5e72851de012d3a0b2c2d01f8685> "Add new warning for compound
punctuation tokens that are split across macro expansions or split by
whitespace" and <https://github.com/llvm/llvm-project/commit/
0da84535b1e328188efbc1bb697dc7276f9e7d27> "Remove
-Wcompound-token-split-by-space from -Wall", Clang 12 trunk emitted such "'::'
and '*' tokens forming pointer to member type are separated by whitespace"
warnings, so just clean those places up for good even if the warning would not
hit out of the box with any official Clang release.
Change-Id: Ic58c0da4b3dcce428f5aaa54e13d15299394cf9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101987
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...from which an OString can cheaply be instantiated.
The one downside is that OStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a containers that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::string_view, without loss of efficiency
compared to the original OStringLiteral, and without loss of expressivity (esp.
with the newly introduced OString(std::string_view) ctor).
The new OStringLiteral ctor code would probably not be very efficient if it were
ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OStringLiteral is in all cases where an
object that shall itself not be an OString (e.g., because it shall be a
global static variable for which the OString ctor/dtor would be detrimental at
library load/unload) must be converted to an OString instance in at least one
place. Other string literal abstractions could use std::string_view (or just
plain char const[N]), but interestingly OStringLiteral might be more efficient
than constexpr std::string_view even for such cases, as it should not need any
relocations at library load time. For now, no existing uses of OUStringLiteral
have been changed to some other abstraction (unless technically necessary as
discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC
bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". Those places, as
well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx
and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been
replaced with OString::Concat (and which is arguably a better choice, anyway),
also caused failures with at least Clang 5.0.2 (but would not have caused
failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that
have meanwhile been fixed).
This change also revealed a bug in at least recent Clang 12 trunk
CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least
in some calls from loplugin code (for which it can be fixed for now in the
existing compat::getSubStringAsWritten).
A similar commit for OUStringLiteral is planned, too.
Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie8f5c015d32b67ad9148c1d0bb8d73425a5b563a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101827
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
O[U]StringView had an odd mixture of uses. For one, it was used like
std::[u16]string_view, for which directly using the latter std types is clearly
the better alternative. For another, it was used in concatenation sequences,
when neither of the two leading terms were of our rtl string-related types.
For that second use case introduce O[U]String::Concat (as std::[u16]string_view
can obviously not be used, those not being one of our rtl string-related types).
Also, O[U]StringLiteral is occasionally used for this, but the planned changes
outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral
from char[] to char16_t[]" commit message will make that no longer work, so
O[U]String::Concat will be the preferred solution in such use cases going
forward, too.
O[U]StringView was also occasionally used to include O[U]StringBuffer values in
concatenation sequences, for which a more obvious alternative is to make
O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat
machinery.
Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Remove case sensitivity from NON case-sensitive Hungarian collator
in i18npool, added by commit 7b1eb6313c0d2621c364df1724c69d28f8267841
(tdf#116666 fix Hungarian sorting). It seems, this doesn't affect
Writer, where it's possible to choose case-sensitive sorting, too.
Note: Handling of space is still a problem for normal text,
i.e. sorting according to Hungarian orthography, see
commit 7618490d334409c3fc4167f32732537ef738647f
(tdf#123204 hu_HU collation: don't ignore special characters).
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I667eb5e22401a7fcef0e6e6111c48ce7d9c4aaf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101527
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Inherited from en-GB, zh-HK
Change-Id: I966d19cfa2da26d3d882af35afe79a2f77eaffa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101139
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
after
commit 155c056b1d4674d5ff73bbb5e1ad1dcd1e6aae36
i18npool: create instances with uno constructors
this fixes two things
(*) the names of some of the constructo functions were wrong
(*) the native-code.py script needed updating
Change-Id: I5f3cad78eb2f84cb78ba7fed9f98122858fc6b81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100599
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic309fc9b07186ce0b86ca54028d62e0fafd104fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99950
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
and rename some classes to match their UNO implementation name.
See tdf#74608 for motivation.
Change-Id: I16aa64781d30a500f234029da6f6b00a645c46bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100133
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icea2dac6e4ef6493c2a7fe5f7def0f1708caf6d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95684
Tested-by: Jenkins
Reviewed-by: Tomoyuki Kubota <himajin100000@gmail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I607e1defbd657546bfc017d16d0edfcf0dc2c028
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99721
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: I814512ccc546bd015558a8122f0d2e3803437e38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99722
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Follow-up for 4804d969bacd25ad586b3bf70d3dc8c27adb48ef:
* change abbreviations to omit trailing periods, as officially preferred
* add quotes around literal characters in date formats
(so those formats wouldn't be mistakenly detected as "user-defined")
* revert sorting of a few date formats for backwards compatibility's sake:
- when opening files created in 7.0, previous versions shouldn't add
". a" anymore to formats that aren't supposed to have it
Change-Id: I666273aa32e7ca363aa929b8a1fd83bf46533f6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99264
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I09c8d3a129c0d1d2fab561add0447869156b193f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96693
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
If sw text formatting gets the result of the special-case code added to
the "word boundary break" condition, it may call again the next time
with the preceding index, and fall into the "Line boundary break"
condition, which hence also needs to special case '/'.
(regression from ICU 60, 9206a08ada00e8762c4a634f242bd566028964bb)
Change-Id: I2aaefbc7b25af157e0a6ef15fabaa71bff1e8d9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99104
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Id5144e95ac0120b3125258cdde46e4f7f6e1690b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99109
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: I5f8113393120fdad192f7347109a2186db141acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98708
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I47e920a98833f71bd5c8db0a0590a4f8cdcb83b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98465
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: If41314c90397199c14c91fe65ed41243ac385dae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97827
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8b93f7610103f4bd8e86e2d9f57929922b6dc92c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97568
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie06a19b902e4dc12914fe0f2328a5abafa85368e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96208
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See bt here:
https://bugs.documentfoundation.org/attachment.cgi?id=161882
Change-Id: If5a6c5e2b52af9ef97af9522296aaa58352cfa69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96161
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5644ca7f2ef1b251ce1c262d3001ca48f2ed9edd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95482
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Single Quotes AutoCorrect, i.e. pressing Ctrl + '
will insert typographic apostrophes (third level
Hungarian quoation marks) instead of » and «, like MSO does.
This reverts commit 0d0c13bfbdff85a18433aee6e94558689f0cb722
(tdf#115382 Hungarian autocorrect: help apostrophe usage), too.
See also commit b9910e87de4eea1cb3684bb7af8e58d681cbe809
(Resolves: tdf#116062 revert [fr-CH] to use previous
single quote characters)
Change-Id: I9ff5cb9a55699c253b6a57589186caa7caa170a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95210
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Iedfd492c963eb89fe75fdd73cae630e7e1dae119
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95100
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|