My expectation was that <w14:checked w14:val="0"/> would be mapped to a
single SPRM where the int value is 0 or 1 depending on if this is a true
or false boolean. But the w14 tokenizer rules actually created a
NS_ooxml::LN_CT_SdtCheckbox_checked token with a
NS_ooxml::LN_CT_OnOff_val token in it, which itself again didn't contain
just a bool but dedicated NS_ooxml::LN_ST_OnOff_true,
NS_ooxml::LN_ST_OnOff_1, etc values.
To make this more complicated, TextEffectsHandler even depends on this
weird behavior.
Bring the w14 rules closer to the "main" wml rules by folding the
NS_ooxml::LN_CT_OnOff_val token into the parent token
(NS_ooxml::LN_CT_SdtCheckbox_checked in this case), but leave the
NS_ooxml::LN_ST_OnOff_* values unchanged for now.
The rest of the changes are more straightforward: we now handle
inline/run checkbox SDTs similar to rich text ones, i.e. map them to
Writer content controls, rather than just doing a poor mapping to
grab-bags.
The main benefit here is that the checkbox type of Writer content
controls actually change their value on mouse click, so it's possible to
fill in such forms.
Change-Id: Idbf49a8ff1843d5271f2836e5299c4387bb58e55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133588
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The curved*Arrows start with two arcs, which should be connected by a
line. The used commands are double V and double B respectively. Both
have an implicit moveTo, so that there should be no line between.
Other applications show the shapes correctly without line. But because
of bug 148714 LO shows a connecting line so that the error was not
earlier detected.
The patch changes the segment definition so that for the second
command the variant with implicit lineTo is used. This does not change
rendering in LO but makes other applications rendering the shapes
like LO.
Change-Id: I4f799f89497e52b1a7e00d8e5345a66ce21c00a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133586
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
This is a rather weird corner case than I can see only with
JunitTest_svx_unoapi failing without this, when asking to lay out
characters 7-9 from "paragraph 1" with layout mode set to RTL.
Change-Id: Ic55e571a5934ea2b9de2f09b7c066abf014ac212
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133578
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
So that so much stuff doesn't get rebuilt on --with-java change.
Change-Id: I87388590a4fd218fd22e68ba0edd290831f6f0fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133570
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
There might be a more general place where this belongs,
to cover other similar kinds of situations.
However, putting it here is very targetted,
and shouldn't get me into unanticipated trouble.
Any changes made in the "top view" need to be accepted before
they are committed. In this case, the user switched gears
and added a new sheet while in the process of editing.
So what should happen here? Should we commit the change
before changing task? Perhaps. Certainly it should
NOT show up on the new sheet - but that is what was happening.
Accepting the change when the user gets side-tracked is the norm
in cases like print-preview, switching to another soffice app,
or simply clicking on a different cell or switching tabs.
So auto-accepting in this situation is consistent behaviour.
Change-Id: I4f3f0103ad4fcc1aa8a0c6118383b63ace07ff5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126501
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
Revert part of 02e1be8883 which broke
with-system-nss builds - the hasht.h header was actually needed.
Change-Id: Ida36bc6cd91f0a9b26a2029f1cab835f90f40dde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133571
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
replace the obscure graphemes with a bullet that exists in the font
Change-Id: Ib95ae2a8f83a04a3a8b32cf3f7d9d1ecaf7d5f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133564
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Additionally the magic number were replaced with enum
Change-Id: I7d825ec84ff5cd5ff315ee37613e3b84cb6f0567
Change-Id: Ic33022a0e225099f2397dd300f4792055184fd10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133526
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
* Update helpcontent2 from branch 'master'
to d7890e97169844d9a2f46703b893c1123dd8ebce
- Drop reference to AskBot and update link
It is never a good idea to hardcode the name of the backend software for
a website in a translatable string directed to users. It’s not future-proof.
Also, we’ve never called it that; it’s always been “Ask LibreOffice”.
But in this case, I’ve carefully avoided mentioning the product name, for
the sake of corporate builds.
Change-Id: Ic4c1c01e7ecc86d44157fec638a5d79dcb809733
Left page border -> Left of page text area
Right page border -> Right of page text area
The CSS box model is the underlying idea here, where
LO uses "page text area" for what is called "content area"
in the box model. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Box_Model/Introduction_to_the_CSS_box_model
The reference to "border" in the options was incorrect.
The renamed controls refer to the regions to the
left (and right) of the page text area. These regions
can be used for horizontal positioning of shapes and images.
Change-Id: I2ea8c682da8fb34b04496b3629819bf5201e86e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133403
Tested-by: Jenkins
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Apparently not using it makes the ImplLayout() call treat everything
as one run, which changes whether a glyph may get ALLOW_KASHIDA.
Change-Id: I1a951dbc4242d1fe8e4ee5074d9f9ad1d80480be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133546
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This is basically the same like 7b7d2f4a3e,
triggered by CppunitTest_sw_uiwriter3's testTdf104649 on Mac.
Change-Id: Ibb3c33dd6924e8f0c8856185fc7fb7aeaaf72177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133545
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* Update helpcontent2 from branch 'master'
to d4e7c6e6e119fe3fab827753bbb8d27caff195c2
- tdf#148797 improve explanation of multiple selection in add to list
Some of the options for using the Add to List command are not
available when the Ctrl key is pressed. The existing description of
how to use the Ctrl key may have contributed to confusion about
how to use the command. This patch aims to improve the
description of the workflow with multiple selection.
Also the order of the two procedures were switched, on the
assumption that the most typical use was to add some consecutive
items to a list, so now that explanation comes first.
Change-Id: I4e7c57dba4b6060fcd87eb1046b9e0788dd50b1c
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/133483
Tested-by: Jenkins
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Since 16 bits part is well taken into account for photometric interpretation "RGB",
just consider greyscale as subcase of rgb since greys are just "RGB" colors with same value for red, green and blue
Finally, in ConvertScanline, nPhotometricInterpretation <= 1 (so "min is white" and "min is black") with nSamplesPerPixel = 1
corresponds to nDstBitsPerPixel = 8 here, so consider this specific case in the same block.
The last piece to adjust is when calling SetPixel:
nPhotometricInterpretation = 1 corresponds to the same case as nPhotometricInterpretation = 2
since RGB black is 0, nPhotometricInterpretation = 1 is minisblack so here too black is 0
Change-Id: I5c8e420f851ed6e31998c0698d86300aaa7c4b19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133251
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
For some reason it may differ even if vcl::Font is the same.
Without this ScExportTest2::testTdf66668 fails.
Change-Id: I728a0848ac0420ce0d746134c7072f6ab59f2761
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133537
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
They call non-const GetHbFont() internally, but conceptually they
are const.
Change-Id: Idec7f06425383c5e78030c76da2c50f560bf64fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133536
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Map the 4 UNO properties to the following XML construct:
<w14:checkbox>
<w14:checked w14:val="0"/>
<w14:checkedState w14:val="2612"/>
<w14:uncheckedState w14:val="2610"/>
</w14:checkbox>
Change-Id: I6457754e5dc9750204da7f2e5e479589380f3992
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133532
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
New DOCX compatibility flag "WordLikeWrapForAsCharFlys"
has been introduced which true in case of importing DOCX
documents. It modifies the wrapping of long words
with as_char anchored flys anchored into the same line,
resulting e.g. correct import of poor man's header lines
drawn by using underline characters under an image.
Note: this example was imported as a broken header line:
half of it was there after the left aligned image in the
same line, and after the line break, only the other half
under the image.
Change-Id: I9474900ef778bcf5ddc9d95f39d536d67015f3b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132571
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Glyphs are in the reverse order in this case, so the character
positions for the wanted range must be treated that way. This improves
e.g. the second attachment from tdf#112989. Unfortunately it's
not that significant, as arabic glyphs are often unsafe to break at.
Change-Id: I836ebff6282c420462c5cd5906d30d2e9431f218
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133494
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This patch splits the footnotes and endnotes section in Navigator.
Before, there was one section for both footnotes and endnotes and
now there are two sections, one for footnotes and one for endnotes.
Change-Id: Ic0f3af92efa1c0487ee3c407a819bf34138ef4ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132796
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
While at least Linux distros typically provide the zxing include files in a
dedicated ZXing sub-directory (i.e., /usr/include/ZXing/), the bundled
external/zxing does not (it rather provides them in
workdir/UnpackedTarball/zxing/core/src/, cf. RepositoryExternal.mk). Therefore,
source files like cui/source/dialogs/QrCodeGenDialog.cxx
#include <BarcodeFormat.h>
etc. rather than
#include <ZXing/BarcodeFormat.h>
etc., and for --with-system-zxing ad92c7dfa6 "fix
system zxing build" simply hardcoded ZXING_CFLAGS=-I/usr/include/ZXing (i.e.,
the typical location for these include files).
However, for e.g. a Fedora Flatpak-from-RPM build of --with-system-zxing
LibreOffice, the include files will be in /app/include/ZXing/ rather than in
/usr/include/ZXing/. (And which AC_CHECK_HEADER would find via
CPLUS_INCLUDE_PATH containing /app/include for such a build. But the hardcoded
ZXING_CFLAGS then caused compiling e.g. cui/source/dialogs/QrCodeGenDialog.cxx
to fail because it didn't find BarcodeFormat.h etc. in the hardcoded
/usr/include/ZXing/.)
So when checking for the sample zxing include file (MultiFormatWriter.h), try
any $CPLUS_INCLUDE_PATH paths one by one (and with a fallback to /usr/include).
(The explicit unset ac_cv_header_MultiFormatWriter_h is needed so that the
second and later iterations of the for loop don't erroneously reuse a cached
"no" result.)
Change-Id: Id85f9960ffd3759c7960ef3a81982b85bc3c04c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133189
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This is always direct formatting, so FillProperties::pushToPropMap()
always has the needed info at hand.
Change-Id: I3317b618e0e8bb7688d0f0fbfe4546e2e8b4e947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133525
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
A glyph may may composed from several characters, when asked to make
a glyph subset for a character range, make sure the end of the range
is not inside this character group.
Change-Id: I41d82b432858a87e103dcb0d2fac6a11f25a32dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133530
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The pointer comparison can be false even though the contents match.
Change-Id: I584d30fdc7f311fd1a6058ae3cef98ce8b243f86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133529
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Columns should be dynamically allocated on demand, so there should
be theoretically no good reason to allocate 64 initially. In practice
doing so hides all places that do not allocate columns as needed.
Change-Id: I8b46ecc97852ed23369e720f50f3266c48440435
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133311
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
UITest_calc_tests' columns.CalcColumns.test_column_hide_show fails
with INITIALCOLCOUNT being 1 because column C was hidden, but
searching only up to the first allocated column + 1 searched only
up to column B. Whether an entire column is hidden is not part
of ScColumn, it's stored in ScTable.
Change-Id: Ib1befe5cd0db8d50a6196bc6621fb1b0967e6209
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133524
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
