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 ad92c7dfa64c9e08aa2bcf612a9a4a68e9deae22 "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 504d78acb866495fd954fcd6db22ea68f174a5ab
"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>
For now, it only contains buttons opening the dialogs accessible
from Format menu. This is enough for the initial implementation,
and should later be changed to individual controls allowing to
set the formula properties directly.
Change-Id: Ia0e52915198ddb2648d13d577d55b367f178b1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133508
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The export to custGeom uses currently a static version of the shape. Its
vertices are calculated with EnhancedCustomShape2d::GetParameter(). That
has parameters to determine whether ReplaceGeoWidth and ReplaceGeoHeight
has to be used. It needs to be used, in case the shape has property
StretchX or StretchY. That was missing. It is added now in cases where
GetParameter() returns a coordinate.
Not all cases are covered by unit tests. Further files for manual testing
are attached to the bug.
Change-Id: Idcdd081f855ed6c4e3a84dba08f8a2148ddfe54c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133463
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
The regression introduced by c79fa460fe6220051bbda2d3c0cb67fbf765e2ac
causes LibreOffice to crash while loading certain files that contain
SmartArt graphics.
By loading sample documents from tdf#148665 (docx) and also tdf#148735
(pptx) in a debug session, it became obvious that the problem happens
in these statements from TextBody::toString() in textbody.cxx:
if (!isEmpty())
return maParagraphs.front()->getRuns().front()->getText();
It is guaranteed that maParagraphs is not empty when trying to call
getRuns(), but it is not checked that there are no runs in the first
paragraph before trying to call getText(). The isEmpty() function
returns false upon finding out that there is at least 1 paragraph.
A check is added to TextBody::toString() to prevent a crash.
This is the backtrace generated from loading documents from tdf#148735
in a Qt Creator debug session:
1 __GI_raise raise.c 50 0x7ffff79ec03b
2 __GI_abort abort.c 79 0x7ffff79cb859
3 ?? 0x7ffff7846109
4 std::vector<std::shared_ptr<oox::drawingml::TextRun>>::front vector 443 0x7fffd23d1fa6
5 oox::drawingml::TextBody::toString textbody.cxx 92 0x7fffd23d0f85
6 oox::drawingml::DiagramData::secureDataFromShapeToModelAfterDiagramImport datamodel.cxx 295 0x7fffd22d3047
7 oox::drawingml::AdvancedDiagramHelper::doAnchor diagramhelper.cxx 213 0x7fffd22fb92d
8 oox::drawingml::Shape::propagateDiagramHelper shape.cxx 229 0x7fffd2372a27
9 oox::ppt::PPTShape::addShape pptshape.cxx 574 0x7fffd25b2bd4
10 oox::ppt::SlidePersist::createXShapes slidepersist.cxx 150 0x7fffd25d81ea
11 oox::ppt::PresentationFragmentHandler::importSlide presentationfragmenthandler.cxx 404 0x7fffd25c1a78
12 oox::ppt::PresentationFragmentHandler::finalizeImport presentationfragmenthandler.cxx 550 0x7fffd25c3331
13 oox::core::FragmentHandler2::endDocument fragmenthandler2.cxx 53 0x7fffd22364ab
14 sax_fastparser::FastSaxParserImpl::parseStream fastparser.cxx 907 0x7fffe18b2d2b
15 sax_fastparser::FastSaxParser::parseStream fastparser.cxx 1480 0x7fffe18b71d2
16 oox::core::FastParser::parseStream fastparser.cxx 121 0x7fffd221d85b
17 oox::core::FastParser::parseStream fastparser.cxx 129 0x7fffd221d930
18 oox::core::XmlFilterBase::importFragment xmlfilterbase.cxx 413 0x7fffd2248ba5
19 oox::core::XmlFilterBase::importFragment xmlfilterbase.cxx 343 0x7fffd2248687
20 oox::ppt::PowerPointImport::importDocument pptimport.cxx 109 0x7fffd25a89e2
... <More>
Change-Id: I3a40be33061008b93455a5926259ef5b92e4ffe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133341
Tested-by: Jenkins
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The problem which is fixed with this commit is, that the slide show ends when the presention screen has shown "Click to exit" after the last slide, and then the slide show was moved to a specific slide. e.g. via Remote App or Presenter Console. In this case the slide show should be resumed and the slide should be displayed. Instead the slide show was ended.
Instead of only handling the BLANK mode for resuming a slide show also the END mode is now inlcuded to resume the slide show.
Change-Id: I78e00dc882b2d7af8b7a6b215aaac122bbd9ead9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133337
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Many fields we are locking just because we can't trust that
what is seen in MSWord is what will be seen in LO.
Of the unlocked fields which normally should be updated
(SAVEDATE and PRINTDATE), if MS Word secretly has also
locked them (via Ctrl-F11), then we also need to lock them.
Currently, on export these will be exported as plain text,
which IMHO is perfect because them we never need to mess
with these nasty fields again.
WriterFilter import was already handling the complicated FldChar's
fldLock OK, but nothing happened with the one for fldSimple.
Proving once again that a monkey can program, I randomly made
copy-changes to model.xml until I got the result I wanted...
The unit test has one of each.
Change-Id: Ia197794f4ea7e105b67cb1805c5def5347d7690d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133087
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
In general, try/catch shouldn't be used in unittests
Follow-up of 9564747d2fd5d2c859a359dd7fa6242c6859c0d7
"tdf#53970 PPTX: fix import of linked media files"
Change-Id: Ibde31d033b0225ab47522eff01e156cbb2751f18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133468
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This button was introduced in commit 376cd2ceaeedd12a8050c5acd142cd9b9d5e731a
Author Muhammet Kara <muhammet.kara@collabora.com>
Date Wed Nov 20 15:30:01 2019 +0300
Add Edit Chart button for online's mobile view
It is shown for any kind of OLE object, including Math. So make its text
more neutral.
Possibly it could make sense to construct the name from the OLE object's
proper name in a follow-up.
Change-Id: Ied2e9b10db3bcbfab4328a1f65f812cd52f85004
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133426
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
