disregard text language for emoji and tag with und-zsye to
get fontconfig to give us the default emoji font
Change-Id: I8f94b0c41dea3204c9db77b96ad8f0d98bae2239
Reviewed-on: https://gerrit.libreoffice.org/78600
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
For one, that broke round-tripping with e.g. UTF-8 (see the test case added to
Test::testComplex in sal/qa/rtl/textenc/rtl_textcvt.cxx) which did not treat
noncharacters as invalid.
For another, <https://unicode.org/faq/private_use.html#nonchar7> is meanwhile
quite clear on the matter:
"Q: Are noncharacters prohibited in interchange?
"A: This question has led to some controversy, because the Unicode Standard has
been somewhat ambiguous about the status of noncharacters. The formal wording of
the definition of 'noncharacter' in the standard has always indicated that
noncharacters 'should never be interchanged.' That led some people to assume
that the definition actually meant 'shall not be interchanged' and that
therefore the presence of a noncharacter in any Unicode string immediately
rendered that string malformed according to the standard. But the intended use
of noncharacters requires the ability to exchange them in a limited context, at
least across APIs and even through data files and other means of 'interchange',
so that they can be processed as intended. The choice of the word 'should' in
the original definition was deliberate, and indicated that one should not try to
interchange noncharacters precisely because their interpretation is strictly
internal to whatever implementation uses them, so they have no publicly
interchangeable semantics. But other informative wording in the text of the core
specification and in the character names list was differently and more strongly
worded, leading to contradictory interpretations.
"Given this ambiguity of intent, in 2013 the UTC issued Corrigendum #9, which
deleted the phrase 'and that should never be interchanged' from the definition
of noncharacters, to make it clear that prohibition from interchange is not part
of the formal definition of noncharacters. Corrigendum #9 has been incorporated
into the core specification for Unicode 7.0.
"Q: Are noncharacters invalid in Unicode strings and UTFs?
"A: Absolutely not. Noncharacters do not cause a Unicode string to be ill-formed
in any UTF. This can be seen explicitly in the table above, where every
noncharacter code point has a well-formed representation in UTF-32, in UTF-16,
and in UTF-8. An implementation which converts noncharacter code points between
one UTF representation and another must preserve these values correctly. The
fact that they are called 'noncharacters' and are not intended for open
interchange does not mean that they are somehow illegal or invalid code points
which make strings containing them invalid."
Change-Id: I4fcc0156e3d2fd305a7c7bb0c7b3dbef846c9e64
Reviewed-on: https://gerrit.libreoffice.org/78598
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to Track Changes toolbar by creating the new Writer UNO command
.uno:RejectTrackedChangeToNext and .uno:AcceptTrackedChangeToNext.
Note: This feature is similar to what Word does by default.
Change-Id: Ic5d7f5663217c605ccbee2f16b49e76522f911e6
Reviewed-on: https://gerrit.libreoffice.org/76719
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
glyphs in starmath at a fairly low stretch ratio. The failure will set
CAIRO_STATUS_FREETYPE_ERROR on the surface which cannot be cleared, so all
further painting to the surface fails.
This appears fixed in 2.9 with
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=91015cb41d8f56777f93394f5a60914bc0c0f330
"Improve complex rendering at high ppem"
Change-Id: I8cbf8347ccd29beda4057b14f2e68678f6030bf4
Reviewed-on: https://gerrit.libreoffice.org/78587
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
If the first level of horizontal category axis labels
is rotated vertically, then the other levels should not be
rotated.
Regression from commit: 23c0b3e13f88d6d71d528777d4f86f50c0766672
(tdf#107074 uncommenting createLabels for the axis fixes the issue)
Change-Id: Ia1978fdc345fa154cff2ea03d2a94475f73398a6
Reviewed-on: https://gerrit.libreoffice.org/78557
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
<http://udk.openoffice.org/cpp/man/spec/textconversion.html> specifies that
FLAGS_UNDEFINED_ERROR, FLAGS_MBUNDEFINED_ERROR, and FLAGS_INVALID_ERROR: "Read
past the [erroneous] code in the input buffer [...]" But actual behavior of
rtl_convertTextToUnicode for the various rtl_TextEncoding values has been
inconsistent. Some erroneous input (mostly single-byte UNDEFINED and INVALID
ones) has not been consumed at all, some (multi-byte MBUNDEFINED and INVALID)
has been consumed partly, and some has been consumed fully as required.
However, at least since 8dd4265b9ddbd7786b6237676909eae5b540da0e "CWS-TOOLING:
integrate CWS hb18", Custom8BitToUnicode in sw/source/filter/ww8/ww8par.cxx
appears to rely on the broken behavior of not consuming erroneous input. (It
reads the chunk of valid input with e.g. some RTL_TEXTENCODING_MS_125x that
happens to exhibit the broken behavior of not consuming erroneous input, then
wants to try to re-read the erroneous input with RTL_TEXTENCODING_MS_1252. For
example, opening sw/qa/core/data/ww8/pass/forcepoint50-grfanchor-1.doc triggers
that code. For whatever reason, the am_faksas.dot attached to
<https://bz.apache.org/ooo/show_bug.cgi?id=9240#c1> "Do not show lithuanian
letter 'Š'" appears to not, or at least no longer, trigger that code.)
Therefore, it would be useful to have a mode in which rtl_convertTextToUnicode
does not consume erroneous input. (And I plan on doing changes in
sal/osl/unx/file* that would benefit from that behavior, too.) But changing
rtl_convertTextToUnicode to generally not consume erroneous input would not be
feasible: If calls do not set RTL_TEXTTOUNICODE_FLAGS_FLUSH, part of an
erroneous input can already have been consumed by a previous call, so the
current call cannot undo that.
But a change that looks like it can work is to change the behavior only if
RTL_TEXTTOUNICODE_FLAGS_FLUSH is set. In that case we can at least not consume
the part of an erroneous input that has not yet been consumed by a previous call
(which would necessarily have been done with RTL_TEXTTOUNICODE_FLAGS_FLUSH
unset). The expecation is that code that relies on the don't-consume behavior
will do only single calls with RTL_TEXTTOUNICODE_FLAGS_FLUSH set (so reliably
not consume the complete erroneous input), while other code (which might do
calls in a loop) will not care whether erroneous input has been consumed,
anyway. This can be considered a mild form of behavioral API CHANGE (but note
that the old implementation didn't exhibit the requested behavior anyway).
So all implementations of rtl_convertTextToUnicode for the various
rtl_TextEncoding values have been adapted to the new behavior. The only
exceptions are ImplDummyToUnicode (sal/textenc/textcvt.cxx), which is a special
case anyway used by RTL_TEXTENCODING_DONTKNOW, and two out of three places
(marked with a "TODO" each) in ImplUTF7ToUnicode (sal/textenc/tcvtutf7.cxx),
where it is hard to retrofit the expected behaivor, and RTL_TEXTENCODING_UTF7 is
probably not relevant for the use cases relying on the don't-consume--behavior,
anyway.
Whether a similar change should be done for rtl_convertUnicodeToText can be
examined later.
Change-Id: I1ac2c4cfd99e2a0eca219f9a3855ef110b254855
Reviewed-on: https://gerrit.libreoffice.org/78584
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The comment had been added with e38e3fc6c0ba5cef622f7412a573bd96c2476ca2
"#i9240# During 8bit conversion fallback to 1252 if a character is undefined in
our source charset. Word appears to do this" (i.e., mentioning i9240 instead of
i9241), and <https://bz.apache.org/ooo/show_bug.cgi?id=9240> "Do not show
lithuanian letter 'Š'" looks more relevant here than
<https://bz.apache.org/ooo/show_bug.cgi?id=9241> "The compound words
�FAKSIMILINIS PRANE�IMAS� have to be Align Centered
Horizontally."
Change-Id: Idb1f50891cd01a96aee4ab19bb606b74a9050e1c
Reviewed-on: https://gerrit.libreoffice.org/78583
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Conversion of spaces to underline characters was only in bookmark names,
but not in the URLs using these bookmark names.
Change-Id: Idb0d9945c79139d8a935ffcf6a3b29a9298c2270
Reviewed-on: https://gerrit.libreoffice.org/78267
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
The problem is that the bugdoc has multiple w:num numbering definitions
that refer to the same w:abstractNum abstract numbering definition.
Apparently (and i can't find this documented anywhere) w:abstractNum
corresponds to a SwList in Writer, i.e. all w:num that refer to the same
w:abstractNum share the same numbering tree, but they may have different
numbering properties via w:lvlOverride.
So i think this should be imported as a single SwList per w:abstractNum,
and every use of w:lvlOverride should create a new SwNumRule, but still
share the same SwList; the previous situation was a SwNumRule + SwList
per w:num element.
This implements simply a SwNumRule per w:num (regardless of
w:lvlOverride) because that was easy; the AbstractListDef class gets a
member to store the ListId of the created SwList when any of its
associated w:num / ListDef is used first, and the non-first ones get
this ListId set to force them into the same SwList.
Unfortunately it turns out the export has the same
SwNumRule->w:abstractNum problem, which remains to be fixed.
Change-Id: I92ce989afd15f24e36b6be6ccaf67ba3e0128963
Reviewed-on: https://gerrit.libreoffice.org/78556
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
in the Select Address List dialog if there are no entries
Change-Id: Iaff60bd0e031884bf1032cf656260353f48ce60d
Reviewed-on: https://gerrit.libreoffice.org/77025
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Only set the widget as sorted in the ctor, it remains sorted
Change-Id: I96897cf5512e91192c69874ca857a967b09a1490
Reviewed-on: https://gerrit.libreoffice.org/76866
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Update SheetView attribute topLeftCell only
in the case of embedded OLE sheets.
Regression from commit 3707e2a7b8b05617b0afb75374f866c967593861
"tdf#122624 XLSX OLE in DOCX: export view positions".
Change-Id: I9ea57ff1531d710bff34df12fb7e0bb1e3edbea5
Reviewed-on: https://gerrit.libreoffice.org/78570
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Noto Color Emoji is a bitmap color font, Cairo knows how to scale such
fonts and FontConfig will identify them as scalable but not outline
fonts, so change the FontConfig checks to checks for scalability.
Make sft.cxx:doOpenTTFont() accept non-outline fonts, the text will not
show in PDF but that is not worse than the status quo.
Change-Id: I756c718296d2c43e3165cd2f07b11bbb981318d3
Reviewed-on: https://gerrit.libreoffice.org/78218
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
This removes duplicating typedefs from NotebookBarAddonsMerger,
and removes dependency of include/vcl/builder.hxx on
include/vcl/NotebookBarAddonsMerger.hxx.
Change-Id: Ica5787c934d1b8ce21623f28ce155337637fdf54
Reviewed-on: https://gerrit.libreoffice.org/78549
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Without setting this sql_mode, NULL or 0 inserted to an auto-incremented column
of a prepared statement would cause that to be auto generated.
Setting NO_AUTO_VALUE_ON_ZERO allows us to copy/paste auto-incremented
columns which may contain zero values as well.
Change-Id: I9602746371c75c82c99ff63240025e8cfb03776a
Reviewed-on: https://gerrit.libreoffice.org/78560
Tested-by: Jenkins
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
These exist since OOo 3.0.1 but were never documented; at least the
ListLabelString looks generally useful.
Append them instead of inserting them before OutlineLevel because the
compare tool complains about the changed order.
Change-Id: Ie70272913de3cc6df34295e68235651f0fa0f7e4
Reviewed-on: https://gerrit.libreoffice.org/78555
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
<http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks>
(as of recent LLVM trunk towards LLVM 10) states:
"-fsanitize=object-size: An attempt to potentially use bytes which the optimizer
can determine are not part of the object being accessed. This will also detect
some types of undefined behavior that may not directly access memory, but are
provably incorrect given the size of the objects involved, such as invalid
downcasts and calling methods on invalid pointers. These checks are made in
terms of __builtin_object_size, and consequently may be able to detect more
problems at higher optimization levels."
A `make check screenshot` with --enabled-optimized runs into two such issues
that were not diagnosed with --disable-optimized, in both cases because a struct
with an "idiomatic trailing dynamic array member" (statically declared to be an
array of size 1) is allocated without any space for that array member, as the
dynamic array size is 0 in the specific case:
* For
> [CUT] sc_ucalc
> cppu/source/uno/copy.hxx:46:19: runtime error: member access within address 0x6020001aaa70 with insufficient space for an object of type 'uno_Sequence' (aka '_sal_Sequence')
> 0x6020001aaa70: note: pointer points here
> 2b 00 80 6a be be be be be be be be 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
> #0 in cppu::allocSeq(int, int) at cppu/source/uno/copy.hxx:46:19 (instdir/program/libuno_cppu.so.3 +0x41f03f)
> #1 in uno_type_sequence_reference2One at cppu/source/uno/sequence.cxx:813:20 (instdir/program/libuno_cppu.so.3 +0x41f03f)
[...]
the call to
pNew = allocSeq( 0, 0 );
in uno_type_sequence_reference2One is inlined, so
sal_uInt32 nSize = calcSeqMemSize( nElementSize, nElements );
in allocSeq is known to be too small.
* For
> testSignatureLineODF::TestBody finished in: 2044ms
> engine-gpg.c:302:6: runtime error: member access within address 0x604001f24f10 with insufficient space for an object of type 'struct arg_and_data_s'
> 0x604001f24f10: note: pointer points here
> 6e 01 00 26 be be be be be be be be be be be be be be be be be be be be be be be be be be be be
> ^
> #0 in add_data at workdir/UnpackedTarball/gpgmepp/src/engine-gpg.c:302:6 (instdir/program/libgpgme.so.11 +0x120c2b)
[...]
> make[1]: *** [solenv/gbuild/CppunitTest.mk:114: workdir/CppunitTest/xmlsecurity_signing.test] Error 1
the
a = malloc (sizeof *a - 1);
is apparently detected to be too small only with optimization enabled.
In both cases, the solution is to operate on the too-small dynamically allocated
object via a reinterpret_cast'ed pointer to some newly introduced "struct
prefix" type.
Change-Id: Ie814db1d00a439bb9189474b91d729e538e81984
Reviewed-on: https://gerrit.libreoffice.org/78548
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
because the list wants to ensure that at least one thing is selected and the
multiselect is implemented with two events of deselect-all followed by select.
post a user event on getting either deselect or select and process it
once when the dust has settled
Change-Id: I553bf23d7a8c4625a8706fb2df4b169d91b7ad32
Reviewed-on: https://gerrit.libreoffice.org/78541
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
and use TEXT_FRAME like calc and other similar users of
of an EditEngine as a frame do.
Change-Id: I9d73362aa44273f87b283fcfc508d27abb50cb40
Reviewed-on: https://gerrit.libreoffice.org/78420
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
so any error dialog which are parented to the calc window are not
hidden by the menu which is destined to be dismissed after the
sort anyway
Change-Id: I7c49737231901de0e61c290fe161d37809d68424
Reviewed-on: https://gerrit.libreoffice.org/78539
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
move it to svx so we can reuse the a11y code in svx for
EditEngines hosted in shapes to provide a11y for EditEngines
hosted in a native widget
Change-Id: I4068c413cdb8ddb0d0ef899774fbe9f65e1bdc60
Reviewed-on: https://gerrit.libreoffice.org/78407
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Replace with comphelper::getUnoTunnelImplementation.
Also use isUnoTunnelId().
Change-Id: I1cf42a483a5c2c9734e4c1f8dd3ba76fd9c7f5e6
Reviewed-on: https://gerrit.libreoffice.org/78429
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... to simplify the logic
Change-Id: I45a23f17e10d634aeb322ac5797adc175006f5eb
Reviewed-on: https://gerrit.libreoffice.org/78424
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
