and cast to that instead of "Edit" and override the Editable controls impls to
do something suitable when called
Change-Id: I24cc02b603e9551df4e3eb39f6cb4839883db777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99709
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Follow-up for 4804d969ba:
* 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>
Otherwise the transparency is lost for the cases where mpAlphaVDev
is used.
Change-Id: Ic7b92cb69727dbe8901695ba496878f0ea381826
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99694
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If you pass an explicit JDK using --with-jdk-home, this would
always test the registry value for the 32 bit test.
Change-Id: If295964c5a594af26fa98ba9f4b302a6c8e7e45a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99686
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
If you run gbuild verbose, make climaker output verbose too.
Change-Id: I712f156bae33bfd403403675f4e2117282a7079c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99684
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
And also make sure mScanlineSize is always correct, which it seems
like it possibly might not have been the case (the delayed scaling
makes it a bit complicated, as the internal scanline size is based
on the internal bitmap size mPixelsSize, not the externally
reported bitmap size mSize).
Change-Id: I0d6cc2fca27ffa1c3accc13b38c8c01b5ffc8ba0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99680
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
<https://ci.libreoffice.org/job/lo_ubsan/1709/> still failed with
> FAIL: test_insert_hyperlink (hyperlinkdialog.HyperlinkDialog)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/tdf/lode/jenkins/workspace/lo_ubsan/sw/qa/uitest/writer_tests3/hyperlinkdialog.py", line 71, in test_insert_hyperlink
> self.assertEqual(get_state_as_dict(xindication)["Text"], "link")
> AssertionError: '' != 'link'
> + link
>
so try a fix similar to 27798238ec "uitest : Avoid
any timing issue in test_insert_hyperlink"
Change-Id: I04b1616f3c5028065aafadbd73e0e52ef220ce5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99669
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...if the specified tabstop would be ignored - for the benefit
of MS Word.
After the numbering character, the tab in Writer stops at
A.) IndentAt, or B.) a non-default tabstop.
In other words, Writer ignores default tabstops.
(Caveat, LO ignores IndentAt when numbering sets a larger tabstop.)
However, MS Word does NOT necessarily stop at IndentAt,
but it stops at default tabstops, or a specified tabstop.
It only seems to stop at IndentAt if there are only
default tabstops that are farther than IndentAt.
In other words, Word usually ignores IndentAt.
(This is true for .doc and .rtf formats. It is also true for .docx
format with MS Word 2003, but not with MS Word 2016.)
In this patch, I only try to fix Word ignoring the IndentAt.
[A basically-unsolvable edge case is when the tabstop is larger than
the first line indent, but still not behind the numbering character.]
This patch could regress if paragraph-level tabstops define the position.
In that case, we have introduced another tabstop at the indentAt
position, and so a SECOND tabstop on the FIRST line might end up
at the wrong position. This is an EXTREMELY unlikely situation,
and in fact, both LO and Word seem to tabstop there anyway,
so I no longer think it would cause a regression. Go figure.
I heavily modified an existing unit test because
although that fix "works" and was an "easy fix"
it probably ought to have calculated the IndentAt and used that
instead of zero to replace the LO default values.
It works, however, so I won't bother doing anything about it.
(Also, the paragraph used doesn't matter - it is the same list.)
Change-Id: Ia13ac880ab63c610b26c99ab77903e08ebdebe35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99529
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
It turns out this doesn't really matter in practice, since if
converting between pixel formats is where time is spent, something
higher must be already wrong. But since I've already written this...
Change-Id: I25451664d529a9226d2d81b2c424a4f4e5422ad5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99577
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This CSS key is allowed, but only the underline and line-through values
are allowed in reqif mode, according to the top of page 66 of
"01_OMG_Requirements Interchange Format (ReqIF)_Version
1.2_formal-16-07-01.pdf".
Change-Id: Ide64344f58bde4569fe499d8514dab36a055bda9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99662
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
... at start of document, part 2:
In SwUndoDelete::UndoImpl(), the m_aEndStr wasn't inserted, because the
pTextNd was a section node.
This caused asserts when trying to add the history hints that used to be
in the end text node.
thints.cxx:1295: bool SwTextNode::InsertHint(SwTextAttr*, SetAttrMode): Assertion `!pAttr->GetEnd() || (*pAttr->GetEnd() <= Len())' failed.
(regression from 57d4886605)
Change-Id: I48caa7487d2d1e6250b5aceab18f270555d3ee8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99644
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
The problem in CopyImplImpl() is that pCopyPam's end position was
updated to index 0 but text was copied into the node, which is thus not
covered by pCopyPam and thus also not by SwUndoInserts.
Then SwUndoInserts::UndoImpl() doesn't delete the bookmarks in the end
node and the bookmark positions cause ~SwIndexReg asserts.
Change-Id: I4cc03e846eae4cabd9eb4346a98c1e5c2866050d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99643
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
* Update helpcontent2 from branch 'master'
to dfa74e26624aa6ac3d3e58773d56aca4647c0aab
- Improve image attributes in Format Menu -related listings
Change-Id: I75798c8c0ecc6ce7b94b523d122c15dc37fcccd3
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/99658
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
