* 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>
This patch improves ordering of the Navigator content tree Hyperlinks
members that are in text frames by placing them in the order of
document layout appearance. This is done by doing a second sort using
the text frame anchor position. Previous to this patch only a sort
using the node index of the node that contains the hyperlink and the
start position of the hyperlink in the node text are used to determine
sort order. This results in hyperlink entries being placed in document
model order in which hyperlinks in text frames are placed before all
hyperlink entries in the regular document nodes section. This sort is
still always done initially with the additional anchor position sort
only being done if needed.
Change-Id: I26f1a12657748a09c2cccd54e89c75ea42ee2ffe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133342
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Fields in text frames may not be in order of document appearance in
the Navigator Fields list. For example, when a field in the first
paragraph has a greater start position in the paragraph than the
start position of a field in the second paragraph, the field in the
second paragraph is placed before the field in the first paragraph in
the Fields list in the Navigator. This patch fixes this unexpected
behavior by first sorting the fields in document model order and then
doing a second sort using the anchor position of text frames for the
fields in text frames to place these fields in document layout order.
Change-Id: If86f133fbce72f936334dffbc237d097de382ca5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133350
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
SalLayoutFlags::BiDiStrong would be set by ImplLayout() if the entire
subset had no RTL, but the entire string may not be that, so when
creating a subset make sure to also set this flag. Similarly
SalLayoutFlags::KashidaJustification should be set only if any
glyph in the range has GlyphItemFlags::ALLOW_KASHIDA.
Change-Id: I0aa2526f2fdd0c6a6b905ad0cb4040ee556529a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133502
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It's cleaner than streaming the font and then hashing the result,
and it's also faster.
Change-Id: I6262e45362d386c21482f1e71be51912f123ee45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133500
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
that would be suggested as fallbacks by fontconfig where the original
isn't available.
Change-Id: Id7e85ec36b6ad16f11d40ccf8a8a5a92c37738be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133521
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Textbox z-order synchronization was missing in case
of Undo, resulting broken text boxes.
Regression from 504d78acb8
"tdf#143574 sw: textboxes in group shapes - part 1".
Change-Id: I2632b7fb40e327f083e680e10b19c8f405df1875
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130875
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: Attila Bakos <bakos.attilakaroly@nisz.hu>
Reviewed-by: László Németh <nemeth@numbertext.org>
also in the footnote area by formatting the footnote
number there as the footnote index number in the main
text (i.e. as anchor of the footnote).
Previously deleted footnotes were shown as not
deleted footnotes in Show Changes mode, also inserted
footnotes lost their footnote number formatting (i.e.
author color of the tracked change, and e.g. the default
underline) after file saving.
Note: for a working test, fix also MetafileXmlDump by
removing the bad 0x01 from the XML dump, which resulted
by the not expanded footnote index placeholder character.
Change-Id: Ie003f4e19d2e2cee6f09d3b195db69fe5c10e405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133503
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
