Age | Commit message (Collapse) | Author |
|
This fixes regression from commit db5a78c8ab1eae30e442151f07b0dc4dcd017550
lok: notebookbar: don't recreate toolbars too often
When we had 2 sessions with notebookbar and one of them switched
to compact mode - other session's notebookbar didn't work.
Before previous change we recreated notebookbar and its welded wrapper
on every StateMethod call for LOK case. So when it become destroyed
we made it working again. But now we need to introduce better management
and not rely on single instence we get from SystemWindow.
Also it's bad idea to rely 100% on SfxNotebookBar::IsActive in LOK
case as when other view will turn notebookbar off, but QueryState
will be trigerred in our session - we will think that it should be
destroyed (it reads config state which is shared between views).
So trust only "true" value (it happens after calling SID_TOOLBAR_MODE),
but destroy notebookbar only after explicit call of
SfxNotebookBar::CloseMethod. It seems to have good result when tested
with multiple views in Online. Maybe we can track Notebookbar state
per view later to make things simpler in LOK case.
Change-Id: Ie739c6441ca05884b0ef20bff23751467706b562
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158936
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Introduces new configuration options PasswordPolicy and
PasswordPolicyErrorMessage.
PasswordPolicy takes a regular expression. When set, it only
accepts passwords that match that regular expression.
PasswordPolicyErrorMessage is the label displayed when the
password does not meet the PasswordPolicy.
In the ideal case, it should contain an explainer of the
PasswordPolicy, so the user is aware of the requirements.
Save with password dialog had maximum password length enforcing
bits depending on the requirements of the saved file format.
These are still applicable in combination with the password
policy.
Also introduces a visual password meter under the password
entries. If the password policy isn't satisfied the password
strength meter is capped at 70%.
The entropy bits to password quality is taken as a linear range.
Where the range of [0, 112] entropy bits is mapped to percentage
[0, 100]. Entropy bits ≥ 112 are mapped to 100% since, according
to KeePass' info page, ≥ 112 entropy bits correspond to a strong
password: <https://keepass.info/help/kb/pw_quality_est.html>
Change-Id: I2e70adacf271916661219f702dfc217292a1b59f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158453
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
Change-Id: I005257e458351285b1b35ffe49c8b42834a6db68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156990
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
for Languages Page.
Change-Id: I3f4cf27980dd6d06da13f554feaca192ebd0b671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158882
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Change-Id: I2fa6ef12d5035aaa21ab464a105085f38ce43423
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158914
Tested-by: Jenkins
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
|
|
Change-Id: Id900a5eef248731d1184c1df501a2cf7a2de7eb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158910
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
<https://lists.freedesktop.org/archives/libreoffice/2023-November/091151.html>
"CppunitTest_stoc_uriproc failed on Windows" reports that
translateToExternal("file:///abc/%feef") produces an empty string (indicating
failure) instead of "file:///abc/%FEef" (as expected in
stoc/test/uriproc/test_uriproc.cxx) when osl_getThreadTextEncoding() is Shift
JIS.
This was due to how the call to rtl::Uri::encode in
Translator::translateToExternal (in
stoc/source/uriproc/ExternalUriReferenceTranslator.cxx) behaved: It internally
interpreted its input "%FE" as the single-byte Shift JIS character 0xFE. Which
gets mapped to U+2122 as an extension (see "APPLE additions over SJIS, we
convert this like Apple, because I think, this gives better result, then [sic]
we take a replacement char" in sal/textenc/tcvtjp6.tab) in readUcs4, but which
in turn doesn't get mapped back to any Shift JIS character in writeEscapeChar.
Translator::translateToExternal is the only user of
rtl_UriEncodeStrictKeepEscapes, as introduced by
6ff5d3341dbc5df3f0cb5368ccb0e1089338916c "INTEGRATION: CWS c07v013_SRC680
(1.4.40); FILE MERGED: 2007/06/21 13:00:56 sb 1.4.40.1: #b6550116# Made
XExternalUriReferenceTranslator.translateToExternal more robust when the input
URL contains spurious non--UTF-8 octets like %FE (which are now copied verbatim,
instead of signalling error)."
To make the claim true that such "spurious non--UTF-8 octets like %FE" are
always "copied verbatim", regardless of text encoding being used, repurpose
rtl_UriEncodeStrictKeepEscapes to always treat any escape sequences that are
present as (potentially broken) UTF-8.
Change-Id: I0fa0b14d3e3d44e4b5514e1b73c84c407a947ce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158888
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I88b25dd676fc57303978e3d5e875af129240b676
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157762
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I682e30cfb4fd63a4f906bfb875cafdf77ae9cfe3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158805
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
as it is just now a simple wrapper over officecfg
Change-Id: If41c7c9db191af7ebede9072fd995d015056bf1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158779
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I33fe8afcbba1d461bee98c92507c878e4e5d41d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158756
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Exponent in scientific number may use '?' as blank like in format "0.00E+?0"
This change:
- adds interpreatation of '0' and '?' in exponent
- adds "blank-exponent-digits" attribute to scientific number for import
and export to ODF
- prevents using exponent with only '?'. There must be at least one '0'
in exponent
- adds QA test of such format and test import/export/import to ODF and OOXML
- corrects one basic test
Change-Id: If52edc632a161f842270bb2fd77af535e2b978d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154986
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
|
|
In scientific format, user may want to have clearer format such as:
0.000" "000" "e+" "0
This change
- adds "exponent-lowercase" boolean attribute to scientific-number format to preserve "e" or "E" char
- includes all positions up to exponent for embedded text of scientific number
Add QA test
Change-Id: Ie263f4ecf30a1a8dcd8046e1e048767020e54dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153824
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
|
|
Import all master slides.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: Ieac68bacf15c75e4c23ec692aadcb16033cdd092
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157701
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158716
Tested-by: Jenkins
|
|
because it reduces the noise in an upcoming patch
Change-Id: I67d7b719609271f626e38596416eb511fbd40b07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158714
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so push the CreateObjectSpecificProperties implementation down to the
concrete subclasses.
Change-Id: If2c9545aada3e9f2c2f2a0140b6d880bdfef111d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158711
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie1b01d3d17f453ae1aa3d53c17e52cd4106e222e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158687
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This commit enables exporting the following STYLEREF flags with ODF
- Search from bottom to top
- Hide non numerical
After this commit, the following steps have been implemented
- The document model (I7d8f455ffe90cface4f3b1acf6b9bef6a045ed19)
- The layout (I7d8f455ffe90cface4f3b1acf6b9bef6a045ed19)
- The UI (I7d8f455ffe90cface4f3b1acf6b9bef6a045ed19)
- UNO (Ib664fec059aa1f7f130acc76c253d5d298fa59f7)
- DOCX/ODF filters (here and Ib664fec059aa1f7f130acc76c253d5d298fa59f7)
Change-Id: Iad8e8001807f5ceeaedc9665838672695174a936
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158351
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This reverts commit ae3b97a69688553e6c40ef4b64655db09d5a0f5e.
Change-Id: I39fd84b5efbff0a2cafe090f4f866c801cef19b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158357
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Introduces LevelBar that shares implementation with
Progress(Bar).
LevelBar is to be as a level indicator, e.g. password strength
level. Currently with native backends for gtk and Windows.
Currently, except on gtk - the colors of the bar at different
levels are hardcoded and not dependent on any kind of themeing.
On Windows it follows the styling of progress bar of type "Meter"
according to the uxguide:
https://learn.microsoft.com/en-us/windows/win32/uxguide/progress-bars#meters
Change-Id: Id772cda23615e9582463bf589e4674fd4588c864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157826
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
Made accept/reject handle move redlines other pair, (moveto-movefrom)
and handle the whole move redline, even if it is split into small pieces
that separated from each other.
Added unique ID to every move redline to help find their other parts.
This move ID is generated in case of:
move recognition
moveing a paragraph. (directly create move redline with unique id without
calling the recognition it is faster and more stable)
(there are other cases that could be improved to not use recognition,
but generate ID directly, like moveing selected partial text with mouse)
Implemented the odt export/import of this move ID.
it is a tag like this: "<loext:move-id>4</loext:move-id>"
next to creator/date
Improved the docx import to generate this move ID, so move redlines can
find their other parts
(Not changed Docx export... it works a bit, but far from perfect)
Improved move reckognition:
It can find them even if they are split into multiple parts differently.
(like "ab"+"cd" == "a"+"bcd")
Disabled this because of probably performance issue.
made a complex unit test for it.
Note: Left the move recognition on every place, to avoid as much
regressions as possible.. but in the future, we may can disable it
in some cases.
Note2: We will have to keep move recognitnion, because there are documents
from past, saved without any move informations in the file, and users
expect to see move redlines there. (generated by the recognition.)
Change-Id: If968d4235b676c5e538cfaf4187a4482a86eae9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157740
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158611
Tested-by: Jenkins
|
|
ErrorMessageType removed in favor of an infobar-like label
Accessibility notification added for the quickfind bar
Change-Id: Iec2498d04152392b3e181146005bdb0c9db8ec50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156943
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
with lots of images, we seem to spend lots of time calculating
CRC. Replace the vcl checksum/CRC with rtl_crc32 in sal/, which
forwards to the zlib implementation, which has all kinds of
nice SIMD code for performance.
Change-Id: I295e2ee91b3450fa558b06e67aac0fbb20b85f52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158529
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Refactored LOKDocumentFocusListener::notifyEvent.
Implemented 2 new callbacks:
- LOK_CALLBACK_A11Y_EDITING_IN_SELECTION_STATE: it says the client if
editing in a shape or cell is active or it isn't.
- LOK_CALLBACK_A11Y_SELECTION_CHANGED: it says if a shape has been
selected/unselected, the name of the shape and text content are sent
too for being reported by a screen reader.
(cherry picked from commit 76899152ec3d1924cc72d2b869e197a1e34a0a1a)
Conflicts:
sfx2/source/view/viewsh.cxx
Change-Id: I644bcc7daeb8772805688a9bccdabd0631ce0a22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158562
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
see 8ae3ae4bf75fdd0aaa132c956d9da029baa3adc6 "Step 1 of removing cargo-cult
pragma pack around rtl_[u]String"
Change-Id: Ie9140b92da8895c4991a7f449359bb1747fdb23d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158553
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8ebc2473884ad991a704c7e0955f262bccbf6dec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Revert "Revert "tdf#118133 DOCX import: disable lazy-loading of tiff images""
This reverts commit c6bf16909db054ec5467ebdc0ea0c9dc07307048.
Lazy-loading doesn't work with cropped TIFF images, because in case of Lazy-load TIFF images
we are using MapUnit::MapPixel, but in case of cropped images we are using MapUnit::Map100thMM
and the crop values are relative to original bitmap size.
Change-Id: I2dbf6caf08d7899ec2eae683996d997809d62b89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158509
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
...which is apparently used by Android builds, so
<https://gerrit.libreoffice.org/c/core/+/158513> "Directly use std::cmp_*, drop
o3tl::cmp_*" cannot go in, yet
Change-Id: If8b3ef1e647b6e33c43d0fe5737daf63eda0b761
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158524
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to wait until the Idle inside sw/ has done populating the navigator
tree.
Which required
(*) moving the code down from test/ to vcl/ to avoid circular dependency
issues.
(*) adding a call SolarMutexGuard before Application::Yield inside
IdleTask::waitUntilIdleDispatched
(*) exposing the function to python by adding a method to the
XToolkitExperimental UNO API
Change-Id: Iee418f7a0beb1f5b53addb7fe25823d61720eb3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158495
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
These need to generate multiple elements in
SwTextPainter::PaintMultiPortion() and it's not altogether obvious.
Change-Id: Ib5fd36c3ea8e15dff93a87bb231c3cc4f78b0089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158398
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
nUpdateInterval (sal_uLong --> sal_uInt64) because it is passed as
argument to Timer::SetTimeout function that takes a sal_uInt64
func CalcUpdateInterval (sal_uLong --> sal_uInt64 return type) because
this function is only being called once, and in that call, the
return value is passed to a function which takes sal_uInt64 type
int. line 412
(https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/select.cxx?r=b6b26421#412)
two lines after which it is passed to a function ...
and the function changed in vcl/source/window/seleng.cxx is the one to
which the value of nUpdateInterval is being passed as explained in
the lines above.
Change-Id: I73441c2d3520a222ddb39b8c0c205b4dd61d4751
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156015
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
...which, unlike std::is_signed, also requires that T is an integer type, not
just any arithmetic type, but which appears to fit well here anyway.
But LLVM 12 libc++, which is apparently used by Android builds, only provides a
bare-bones <concepts> that lacks std::signed_integral (among others), so for now
introduce o3tl/concepts.hxx providing what's missing (incl. std::integral and
std::unsigned_integral, for some kind of consistency).
Change-Id: I1c37d37fa1b57b5e3bf24c9e44f3973003905cb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Do not store a raw pointer to an object that go away.
Consequently we can remove the various sleep() hacks
Change-Id: I3200c26b3a2a4eb7592cb2e5c6af64d6b739d1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158390
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1d7bb4183c45f752cddf118411259695a294b2cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158371
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Hossein <hossein@libreoffice.org>
|
|
The document had overlapping text on load since commit
05425f73bfa41d3f7591461e2ad0beb4fafc39b4 (sw floatable: teach the RTF
import about SwFormatFlySplit, 2023-04-21).
Interestingly the DOCX equivalent was fine, there the inline table is
shifted down, below the floating table, so the overlap doesn't happen.
Fix the problem by moving the AddVerticalFrameOffsets=true code from the
DOCX filter to the shared dmapper, because RTF needs the same.
See commit 50223ea6e212b60b7d33839c2753c5601fb50f95 (tdf#98987 sw: add
AddVerticalFrameOffsets compat mode, 2016-03-31) for more details about
this compat flag. It was already enabled for DOC, too.
Change-Id: I948b179c9ec5fa24377014b0e86826568c417b6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158372
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
See tdf#94879 for motivation.
Change-Id: Ibac67e7f8535b231f63a01b7e572595f5b91a996
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158368
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
for Print Page.
Change-Id: I724dcbaf8e3ed479aaf053965d2d0e64381e53fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158269
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
This option changes how HTML/ReqIF export handles paragraphs with
leading/trailing spaces, or multiple sequential spaces. Normally
export may insert newlines every ~256 characters, in place of
normal space characters; this relies on default processing of
spaces, where leading/trailing spaces are trimmed, and runs of
spaces are reduced to a single space.
When PreserveSpaces is true, HTML/ReqIF export takes care to not
alter spaces inside paragraphs. For that, it checks if paragraphs
contain sequences of spaces that normally would be reduced; and
for those paragraphs, it adds "white-space: pre-wrap" to style
(in HTML), or 'xml::space="preserve"' attribute (in ReqIF).
Import of 'xml::space' attribute and "white-space: pre-wrap" style
is implemented; when paragraph has these, it keeps the spaces read
from HTML/ReqIF intact.
Import does not currently support this attribute/style in elements
other than 'p'.
Change-Id: I62dba5eaf313b965bf37d8fa5e3f5bbb8f5e8357
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158362
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I2c491629f52fe0b90517c563f221d7d0345b6ee9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156452
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
OutputDevice is not where text layout should be done. There are a number
of text layout functions that are used across the text layout classes,
so I have moved them into TextLayoutHelper and made the text layout
classes rely on this. I have made TextLayoutHelper implement the
ITextLayout interface because this is still useful to new classes that
need to implement new text layout functionality.
Change-Id: Ic137a938576e7a6a64db0e5780bbbdd8342ef421
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157362
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Locales needs to be read again
in the Preferences/Writing Aids section and since
this is a network operation it can cause a problem.
Better to list all the supported locales in the xcu
and load it right away.
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135598
Tested-by: Jenkins
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153959
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 84bdf9e81a63a8bd308709c86b51bf3900a23c50)
Change-Id: Iad9201101aa167ad33f479c67f72649786e1f2cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158330
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Implemented getListPrefixSize function which relies on
UNO_NAME_NUMBERING_LEVEL, UNO_NAME_NUMBERING character attributes.
The former provides the list item level, the latter is a boolean that
says if a prefix (bullet/number) is present or not for the list item.
It has been needed to modify
SwAccessibleParagraph::_getSupplementalAttributesImpl so that it
returns such properties for list item only and not for simple
paragraph too. In fact for a simple paragraph the default value for
the level property was returned which is 0 exactly the same value for
top list item.
Change-Id: Ia651af4d4b2372eed42c90b0752e16fd47a4fdec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156816
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Gökay ŞATIR <gokaysatir@collabora.com>
(cherry picked from commit 038903d2e066de9525a3baffdd232484ef44ff51)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157780
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I4266832365533330e2a1e2f3a8fdd8abf1a99443
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158321
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
According to the IAccessible2 specification, some
of the attributes that LibreOffice handles as text
attributes are mapped to IAccessible2 text attributes
as well [1], but others should be reported as object
attributes [2], e.g. text alignment
is reported via the "text-align" object attribute on
the paragraph object.
So far, `AccessibleTextAttributeHelper` was only handling
attributes that are mapped to IAccessible2 text attributes.
Prepare for reporting object attributes as well, which
will be required to report text alignment on Windows
in a compliant way (s. tdf#135922).
On the other hand, Qt also expects
`QAccessibleTextInterface::attributes` to return
text formatting using the attributes specified in the
IAccessible2 attribute specifications and maps that to the
platform-specific attributes (AT-SPI text attributes
on Linux), but currently does not provide any way
to report object attributes in addition to text
attributes. It however supports e.g. the
"text-align" attribute mentioned in the
IAccessible2 object attribute specification
when it's reported as a text attribute [3].
Therefore, add a new `IA2AttributeType` enum
that can be used to specify what kind of
IAccessible2 attributes (text attributes,
object attributes) to report.
Only request IA2 text attributes on Windows
when text attributes are requested, but
both types for Qt.
So far, support for none of the object attributes
has been implemented, but an upcoming change
will do that.
[1] https://wiki.linuxfoundation.org/accessibility/iaccessible2/textattributes
[2] https://wiki.linuxfoundation.org/accessibility/iaccessible2/objectattributes
[3] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/accessible/linux/atspiadaptor.cpp?id=546208f0ff23819d216cbb5bf0b5daded79b454e#n2193
Change-Id: Ief7c840d3c5274714a914ca0e56df0c5eaffb06d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158255
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
STYLEREF is a field type in Word which changes its content based on
nearby paragraphs. For example, upon creating a styleref referencing
"Heading 1" you will see the text of the nearest "Heading 1"-styled
paragraph that is above the field.
This patch implements STYLEREF in Writer as a cross-reference. By using
"insert>cross-reference>styles" you'll be presented with a list of
styles. Selecting one and clicking "insert" will create a field which
has text from the "most relevant" instance of the style. To find the
most relevant instance we first search up for paragraphs with the style,
and if there are any we take the closest. If there weren't any, we
search down for paragraphs with the style.
This patch also updates our use of STYLEREF for chapters exported to
docx by using it for all chapters not only those in headers and footers.
This allows us to approximate more chapter field functionality even when
moving between Writer and Word.
Finally, this patch adds some tests for STYLEREF:
- testTdf86790 tests that the "sample file with STYLEREF" document from
tdf#86790 has the correct fields
- testStyleRefSearchUp tests that the STYLEREF searches up when there
are bits of text both above and below it
- testStyleRefSearchDown tests that the STYLEREF searches down when
there are bits of text below it only
- testMarginalStyleRef tests that the STYLEREF searches from the page
top when it is placed in a footer
- testFootnotetyleRef tests that the STYLEREF searches from the
reference mark when it is placed in a footnote
Still TODO:
- [ ] Update documentation
- [ ] Implement reverse-searching (\l) and nondelimiter
suppression (\t)
- Probably these 2 will be in a followup patch
Change-Id: I25dd7a6940abee5651a784b9059fe23b32547d6c
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157456
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I8baece4349683c7a83a283b85e24f33874b47ba3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158177
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
or removed upon save.
With the new options button we can keep the security infos upon save
such as (even if we set the remove personal infos):
- RedLine Info
- Document User Info
- Author and date of notes
- Document version infos
Also on the infobar, if we have a warning, clicking on the infobar button
the security option dialog will open where we can set/modify these options.
follow-up of: 1f440348eb0892fd2c9597806d87b5fe9d60d49a
(tdf#157482 UI: Turn Security Warnings popup windows into infobars)
Change-Id: I8d5d944d76dbdd31653401246113de097ca6d57b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158112
Tested-by: Jenkins
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
|
|
Change-Id: Ie54bc5f012d2de46363da9d19278736a732a1a25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158125
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I362a2e12492391338b63708e4b329fc77ac363c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158113
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|