Makes this warning/suggestion disappear in Android Studio:
> Field can be converted to a local variable
Change-Id: I710cd83c19fe1f83b756b035f05560974b349d22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170709
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
I thought about this functionality again and decided
to change doing it in a way that will support more
alpha more directly in existing primitives - that will
be better for also supporting e.g. PolyPolys with alpha,
etc. Will need checking of existing usages of e.g.
FillGradientPrimitive2D, but it's worth it.
Note that when your primitive processor (usually a
renderer) does *not* support alpha in gradients
directly it is now requuired to continue using the
decomposition (what renderers do automatically when
calling 'BaseProcessor2D::process' in the default
case. Checked that for existing processors.
Change-Id: I840c9feb8c98549b790ef16285a309b42c4b1b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170687
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Instead of using the generic window or highlight
text color, use the specific text colors for tabs
when painting entries of the vertical tab control,
similar to how it's done for the non-vertical
tab control (see `TabControl::ImplDrawItem`).
This is also in preparation for changes to make more
use of the system colors for the entries.
It e.g. ensures that black text color is used for the
text of the focused entry with Breeze (light) in my Debian
testing KDE Plasma 5 setup with Rafael's pending change [1],
preventing the issue of too low contrast mentioned in [2]
that is otherwise seen in my setup, but not Rafael's for some
reason.
[1] https://gerrit.libreoffice.org/c/core/+/170554
[2] https://gerrit.libreoffice.org/c/core/+/170554/comments/f9d0f988_6a0f5eec
Change-Id: I718d08f717bd896b7fca9fc39eedae68fba4bd25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170677
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
Tested-by: Jenkins
A line spacing difference of 1.07 and 1.06 is significant for layout.
Use rounding to get better round-trippability.
This patch was created based on a code read, finding a DOUBLES unit test
and having related coding attempts noticing integer precision loss.
make CppunitTest_sw_ooxmlexport13 \
CPPUNIT_TEST_NAME=testTdf118947_tableStyle
The export change is a blind fix
(but older LO now opens ooxmlexport13's RT as 1.07% (256.8)
because we now write w:line="257" (1.07083) instead of 256 (1.066).
The import change is confirmed by ooxmlexport13 (matching Word 2010).
Change-Id: I196af783b80688839c59058feb82bf00d40d9088
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170669
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
When vmiklos added support for negative auto -> FIX,
he indicated that there was no documentation for it.
commit f575f70b83
Author: Miklos Vajna on Thu Jun 22 13:41:30 2017 +0200
tdf#108682 DOCX import: fix <w:spacing w:line=...> for negative
I didn't find UI in Word to create
In working on bug 125469, I hand-crafted a nasty example document
which had negative exact and atLeast examples,
and this patch matches what I saw happening in Word 2010.
Too bad MS isn't completely consistent...
Change-Id: Iaab32aa3f0bbe90dfd0ef8973f9aefd2d6ca3fcc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170671
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes the problem where a programmatically generated document
didn't specify a w:lineRule, and thus the w:line size
was treated as a FIXed spacing of 12pt instead of as single spacing.
------------------------------------------------------------
lineRule (Spacing Between Lines)
Specifies how the spacing between lines is calculated
as stored in the line attribute.
If this attribute is omitted, then it shall be assumed to be
of a value "auto" if a w:line attribute value is present.
------------------------------------------------------------
However, our implementation (wisely) defaulted to ::FIX
instead of ::PROP (which keeps precision in w:line sizes
since PROP is a integer percentage instead of a float
and thus loses precision when switching between FIX and PROP).
Note of course that if neither w:line nor w:lineRule is provided,
then we go with the LO default of mode=0, height=0 (aka AUTO).
This gets tricky because the lineRule can be inherited,
so just because it is missing in a pPr doesn't necessarily mean
we can just substitute "auto".
It is also tricky because w:spacing
deals with more than just line spacing.
Not surprisingly, no existing unit tests matched this case.
However, the unit tests were VERY helpful in pointing out
limitations as I attempted to code the fix.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf125469_singleSpacing
Change-Id: Id5e95f2983f4fb435810d5a1f3fd25ded5118ddc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170670
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
I didn't make any logic changes to the function yet,
just moved it to a shared location so it can be called elsewhere.
This is preparation for fixing bug 125469,
and I want to keep the fixing patch clean to show the real changes.
Change-Id: I50a9ad1c61c7e885f40defc38554e0cb2ca51a9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170668
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
since:
commit 6a54d08e6e
Date: Fri Jul 5 15:19:23 2024 -0600
tdf#56408 Writer always breaks lines at text direction change
Change-Id: If4627f4d65d2c44b65653c689ee00a2e0cb4456a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170154
Assertion occurs when underflowing a bidi portion after a field portion.
When attempting to reproduce the issue in GUI, this was accompanied by
an infinite loop. This change fixes both issues.
Change-Id: I85f6fa769756138fe000681a4663925ddfc7ed83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170705
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
so we can get rid of TestAutoCorrDoc, only used for
test purposes
Change-Id: I0931fa76550358d071ebdec364fd6b55485bb3b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170680
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Open the bugdoc, it has two paragraphs: first with a sans font, second
with a serif font. These fonts are missing, but their metadata clearly
state that they are sans vs serif. Still, Writer renders both as sans.
Investigating a bit, the ODT case imports the "font-family-generic" of
these fonts fine, but in the Linux case the fontconfig code ignored this
info when building the search pattern for the font fallback.
Fix the problem by extending vcl's PrintFontManager::Substitute() to
also take the vcl-level "family type" into account, which is about sans
vs serif (roman vs swiss). Note that FC_FAMILY is a string list, so once
the actual font name is added to the pattern, the next "add" will append
to this list, not drop the already added font name.
The same problem is still there with the DOCX equivalent.
Change-Id: I61f31ae73e524471a5261ac9426e5b566454a09c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170681
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Changed <aboveWord> from 'over' to 'ovenfor', and <belowWord> from 'under' to 'nedenfor'.
In Danish, 'over' is a correct translation if 'above' is followed by an object, for instance 'the caption is above[over] the table'. But <aboveWord> is used for cross-references where no object is following: 'see the figure above[ovenfor].'
Likewise for <belowWord>: one object is below[under] another object, but 'see below[nedenfor]'
Change-Id: Ib428342acf83c5961234aebbd50cb6a4a5d28d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170563
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(regression from commit 290c8f6e04)
Change-Id: I85f3dd2a719d13f35cf7246e0787604ddb9f47fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170685
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...that is resolved from within C++ Desktop::InitApplicationServiceManager once
UNO is fully initialized, so client code can trigger on
Module.uno_init.then(...)
Change-Id: I2d4c542d9729d09f434502e3f966e9ee474e926c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
... via the Table->AutoFormat Styles... dialog:
add a "None" option like already exists in Table->Insert Table...
Change-Id: I41d5cb0a7dcd1bfe3e93fe56f0f42765149ff42b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170641
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
This patch draws a white line around the AutoFill handle for better contrast.
It also adds an internal white outline to the cursor overlay.
See bug ticket for screenshots.
Change-Id: I1567d272fd5a2835192c50973e84cb8c269fb04e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170354
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
the classic linker will be removed in upcoming versions of XCode and is
deprecated
XCode 15.0 has a bug that would cause runtime crashes on macOS 11, but
that bug has been fixed with XCode 15.1 and all users of XCode 15.0
could update to 15.1 or 15.2 (15.3 or later requires newer version of
macOS) - so remove the workaround of using the old linker and instead
require a fixed version of Xcode (or a different minimum deployment
target)
Change-Id: If516ac85539da83f54b1792450cf43ea55d0d808
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170640
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
For that, use a minimal oxt file with no funtionality
Change-Id: I5f72e0d0362451a7d0069ad3f9d0626c43ff9d7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170665
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
This is an NFC-ish patch.
SetFormatAttr immediately calls a ClientNotify
about the single property that it has changed.
So if this was a direct property change,
or the set included only one property,
then there is no need to re-notify about this parent change.
The problem with the logic so far has been a failure
to notify about changes. In this patch, we had the opposite
problem of notifying unnecessarily, which isn't terrible.
The main benefit will be seen in a follow-up patch
which allows a single bContinue assignment per property.
Change-Id: I51d961f03910f0b8f50c6402894c5269f15bf00d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169897
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
because I spent a couple of hours on a compile failure trying to figure
out what was calling what, because of the implicit construction that
happens here
Change-Id: I974ec06325c518d47f40c497786b9d6d8a1f1924
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170628
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Implement `accessibilityIdentifier` [1] for
macOS/NSAccessibility by retrieving the accessible ID
via `XAccessibleContext2::getAccessibleId` if that
interface is implemented.
This is the macOS equivalent of
commit c64b823b74
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Jul 16 13:57:41 2024 +0200
tdf#155447 qt a11y: Report accessible ID
[1] https://developer.apple.com/documentation/appkit/nsaccessibilityprotocol/1527792-accessibilityidentifier
Change-Id: I43c40f5309467ddb00911297fadb6716500c2dcb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170624
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
