This change fixes a vertical text glyph metrics regression that was
introduced while migrating PDF export to use metrics from HarfBuzz. The
root cause was incorrectly caching CJK glyph heights in place of widths
for vertical text.
Change-Id: I8426fc902658d1c045b42e760028f26b09eeef93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170935
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
commit 24103bdf3f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 18 08:58:10 2024 +0200
tdf#161501 icon choice ctrl: Use tab text colors
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`).
(...)
had added code to set the font color for the different
states of a vertical tab control item, but as this
was in the `if (bSelected)` block, only the one
for selection was actually used, so the other cases
were consequently removed in
commit a4befb29f3
Author: Caolán McNamara <caolan.mcnamara@collabora.com>
Date: Sat Jul 20 19:20:13 2024 +0100
cid#1610738 Logically dead code
again.
Thanks to Chris Sherlock for pointing this out!
Reintroduce setting colors, but drop the `bSelected`
condition altogether. Drop explicitly setting a fill
color, which the implementation for the non-vertical
tab control in `TabControl::ImplDrawItem` also doesn't
do and which would e.g. result in an odd grey background
for non-selected entries when used unconditionally with
the gen VCL plugin.
I see no visual difference with or without this commit
in place on Windows or for the gen VCL plugin or the kf5 VCL
plugin with the Breeze style on Linux, but other theming/styles
could depend on according colors being set.
Change-Id: Iccf7170f2de04cead23607977ac8cf7acbc471f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170926
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
When the mouse leaves the vertical tab bar,
unset the entry to highlight as mouse-hovered,
as the previously one no longer is when the
mouse is outside the area of the tab bar.
This fixes the issue of the previously
mouse-hovered entry still being painted
with mouse-hover feedback when slowly moving the
mouse to the right away from an entry in the
"Insert" -> "Page Style" dialog with gen or kf5
at least, as shown in attachment 195467
of tdf#161501.
Change-Id: I646cab54f5031ed6a8aa88d4a162bb3a2456eec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170923
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
It is always set, so no need to have an
icon choice control specific window bit to
specify whether or not to highlight the
currently mouse-hovered entry. Just always
do it.
Change-Id: Ib259b6b1576e1968221c4f98661a3a93e600c93b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170922
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
While GetIsDummyParaAddedForTableInSection() is true
for the entire section, it should only be used
against GetIsFirstParagraphInSection()
where the dummy para exists.
make CppunitTest_sw_ooxmlexport19 CPPUNIT_TEST_NAME=testTdf138093B
Change-Id: I457c0aa25eb7bd086c5c15bd889d9cd89c51db95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170921
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes a 24.2 regression
from commit 5082d50d24
writerfilter: use content controls for text in block SDTs
which was made even worse
with 24.2 commit 7c4dba1def.
Initially, the starting mark was made as soon as SdtContent was seen.
After that, you could get a w:tbl, or a w:tc which could trigger
the start of a table, and potentially add a dummy paragraph
which needed to be jumped over (at least for the first SDT,
but not for subsequent SDTs).
In the second patch, the starting mark was made just before
the text was appended, so all of the cell/table creation
has already been completed, so there is no more need to
jump over any dummy paragraphs, even for the first table.
Affected unit tests were
- table-start-2-sdt.docx
- sdt-company-multipara.docx
- paragraph-sdt.docx
make CppunitTest_sw_ooxmlfieldexport CPPUNIT_TEST_NAME=testParagraphSdt
make CppunitTest_sw_ooxmlfieldexport \
CPPUNIT_TEST_NAME=testTdf158661_blockSDT
Change-Id: I4a8359cec27f88f6a2fc0464aa240b523a279e42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170920
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
* Update translations from branch 'master'
to d3e4d5213d29f57c45e2199822f2a68df9a884f6
- update translations for 24.8.0 rc2
and force-fix errors using pocheck
Change-Id: If72ef1ab34b88547d6caa85763242e8f2a231015
Instead of duplicating the same code in both,
`QtGraphics::GetResolution` and
`QtSvpGraphics::GetResolution`, create a static
helper method `QtGraphicsBase::ImplGetResolution`
in their base class and call that.
While at it, also move `QtGraphics::GetResolution`
to the source file where all of the other
`QtGraphics` methods are implemented.
Change-Id: I721459e8b65756f214fee77ac4d3cb8e500f0b57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170930
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Include X.509 certificates under Tools->Options->UserData
among the keys for signing.
Add a new checkbox to Save file dialog, to sign with that
selected key easily.
The checkbox is disabled if there's no matching key found.
Change-Id: I9fc16790c479819cd1f35bcad040d0ebc7c4bdef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170619
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
Don't modify the bound rect of tab items used used e.g.
for drawing the focus/selection/mouse-hover rectangles/indicators
in order to center the content horizontally and vertically.
Making the bound rect smaller in vertical direction
in `SvxIconChoiceCtrl_Impl::Center` resulted in margins
between entries for the non-native drawing path (e.g. the
gen VCL plugin on Linux) for the text-only case
(e.g. "Format" -> "Page Style" dialog in Writer).
Making sure that the content is centered should rather
happen in the drawing routine.
Horizontally centering already happens for the icon-case
anyway, as the `PAINTFLAG_VER_CENTERED` gets passed as flag
to the `PaintItem` call for the `WB_ICON` case in
`SvxIconChoiceCtrl_Impl::PaintEntry` anyway.
And for text-only mode, which was apparently the only one
for which centering vertically in `SvxIconChoiceCtrl_Impl::Center`
had an effect, vertically drawing text was implemented in the drawing
code path in
commit 180f0c1ec8
Author: Rafael Lima <rafael.palma.lima@gmail.com>
Date: Tue Jul 16 20:52:28 2024 +0200
tdf#161501 Improve visuals of selected entries in Vertical tabs
. This commit addresses the
> For the gen VCL plugin, there's still a small gap between
> text-only items (e.g. in the "Format" -> "Page Style" dialog
> which has a different cause and will be addressed in a separate
> commit.
aspect mentioned in earlier commit
Change-Id: Iac34098ef8d0f90f1ac0844df63839a6a99b83a7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jul 22 11:39:48 2024 +0200
tdf#161501 icon choice ctrl: Drop extra space between items
Change-Id: I2077efc8ce1e97d52cf078d63bb4e4b528e389eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170895
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
`SvxIconChoiceCtrlEntry` has two members for maintaining
the bound rect:
* `aRect`, used almost everywhere
* `aGridRect`, used very rarely
`SvxIconChoiceCtrl_Impl::FindBoundingRect` calculates
a new bounding rect and assigns it to `pEntry->aGridRect`,
then calls `SvxIconChoiceCtrl_Impl::Center`, which
at first assigns the same value to `pEntry->aRect`,
so both are the same there.
The other place using the `aGridRect` member is
`SvxIconChoiceCtrl_Impl::CalcMaxTextRect` where
it's used as a fallback if `aRect` has not been
assigned a proper value yet.
However, since `aGridRect` is never assigned a
useful value apart from `aRect`, there doesn't
seem to be much value in doing that, so use
`aRect` there, too, and drop the `aGridRect`
member altogether and assign directly to `aRect` in
`SvxIconChoiceCtrl_Impl::FindBoundingRect` instead.
Instead of falling back to `aGridRect` in
`SvxIconChoiceCtrl_Impl::CalcMaxTextRect`,
add an assert that `aRect` is valid instead,
which never triggered in my tests with the
"Insert" -> "Hyperlink" and "Format" -> "Page Style"
dialogs, so should presumably be fine already.
Change-Id: I99f368672523279f530b937a73c3afb655f7853e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170894
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Unused since:
Change-Id: If309f84fcd9a99337bc5896ce5c3238333427da5
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Jul 23 11:00:42 2024 +0200
tdf#161501 icon choice ctrl: Drop debug-only mode switch feature
Drop code that allows switching the text mode of
the currently selected tab item in a vertical tab
bar using Shift+F10 or Ctrl+F10, which is only
available in dbgutil builds, and was therefore
likely meant to be used for debugging purposes
only.
As related code will be changed in a follow-up
commit, this would have to be adjusted to keep
it working. Instead of spending time on that,
just drop it. Testing how using another mode is still
possible e.g. by locally changing the value assigned
to `SvxIconChoiceCtrlEntry::eTextMode` in the
`SvxIconChoiceCtrlEntry` ctor instead.
Change-Id: If309f84fcd9a99337bc5896ce5c3238333427da5
Change-Id: I418fbf862ec94b04dbcfa4e7ff30cd5a8f9100e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170893
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Drop code that allows switching the text mode of
the currently selected tab item in a vertical tab
bar using Shift+F10 or Ctrl+F10, which is only
available in dbgutil builds, and was therefore
likely meant to be used for debugging purposes
only.
As related code will be changed in a follow-up
commit, this would have to be adjusted to keep
it working. Instead of spending time on that,
just drop it. Testing how using another mode is still
possible e.g. by locally changing the value assigned
to `SvxIconChoiceCtrlEntry::eTextMode` in the
`SvxIconChoiceCtrlEntry` ctor instead.
Change-Id: If309f84fcd9a99337bc5896ce5c3238333427da5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170892
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop the extra spacing between vertical tab bar items, which
became quite noticeable as extra white area between the otherwise
light-grey entries when using the Breeze (light) style and the
kf5 VCL plugin for the "Insert" -> "Hyperlink" dialog now that
the tab items are drawn natively since
Change-Id: Ie0c8ba1b56f6bb76ece6761253b93a109bb3a3f4
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jul 22 11:05:30 2024 +0200
tdf#161501 icon choice ctrl: Draw whole entry natively
and which is also more visible for non-natively drawn items
since
Change-Id: I578755a8a82ea811765b2e0dc3815fb47f67863c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Jul 23 10:41:16 2024 +0200
tdf#161501 icon choice ctrl: Draw selection within item bounds
With this in place, the extra margin between entries
in tab items with icons in the "Insert" -> "Hyperlink"
dialog in Writer is gone for both, the gen VCL plugin
and the kf5 one (tested with the Breeze style).
For the gen VCL plugin, there's still a small gap between
text-only items (e.g. in the "Format" -> "Page Style" dialog
which has a different cause and will be addressed in a separate
commit.
Change-Id: Iac34098ef8d0f90f1ac0844df63839a6a99b83a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170850
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In the same way that the calculated focus rect of an item
is used for drawing selection and focus indicators, use
it for mouse-hover highlighting as well, instead of
drawing a rectangle that reaches beyond the bounds
of the item itself for the non-native drawing path
of vertical tab bar items.
With this in place, hovering over an entry other than
the selected/focused one now shows a rectangle of the same
size as that for the focused entry, which is more
consistent and also aligns this with the case
where the native drawing API for drawing the item is used,
e.g. on Windows or with the kf5 VCL plugin on Linux.
This also means that a small gap can now be seen
between selected item and mouse-hovered item when
hovering over an item next to the currently selected
one for the gen VCL plugin as well, just as was
already the case before for the kf5 VCL plugin.
(Dropping that extra margin will happen in a
separate commit.)
Change-Id: I578755a8a82ea811765b2e0dc3815fb47f67863c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170891
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In `SvxIconChoiceCtrl_Impl::MakeEntryVisible`, always use
the bound rect as the area to make visible.
I see no reason to not do so when an entry is clicked
(s `SvxIconChoiceCtrl_Impl::MouseButtonDown`, which is
the only case that didn't do it yet.
Drop the `bBound` param accordingly.
Change-Id: I7a96e97585521943e7171c278fbd3509037cb7d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170849
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When native drawing of tab items is supported,
natively draw the whole (vertical) tab item (except for the
text) in `SvxIconChoiceCtrl_Impl::PaintEntry`,
instead of using native drawing API only for highlighting
the mouse-hovered entry, as originally introduced in
commit 8708e8cf90
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 11 10:47:50 2024 +0200
tdf#161026 tdf#161355 tdf#161501 icon choice ctrl: Natively draw mouse-hover
... feedback.
Set the corresponding state flags for selected and
focused entry, so that the native drawing routine
can take care of drawing the selected/focused
entry accordingly instead of using the native drawing
API to draw a `ControlType::WindowBackground` for that
purpose.
With this commit in place, all entries (not just the
mouse-hovered, focused or selected) entry are now
drawn using the native drawing API.
For the kf5 VCL plugin with the Breeze style, this
makes them look similar to the entries for the
non-vertical tabbar used elsewhere in LibreOffice,
or actual native `QTabBar`s.
Due to
Change-Id: Idf1e41d3bc309d152a4a36d14e8617bd6429940c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jul 22 08:25:32 2024 +0200
tdf#161501 vcl: Make TabitemValue position-aware
, the selection indicator is drawn vertically as expected
when using the Breeze style.
Restrict manually drawing entries (including focus
and selection indicator) to the case where native drawing
is not implemented (e.g. the gen VCL plugin).
Further tweaking the visual appearance (e.g.
getting rid of extra white margins and space between the
entries for the variant where icons are used,
like the "Insert" -> "Hyperlink" dialog in Writer) can be
done in separate commits.
Change-Id: Ie0c8ba1b56f6bb76ece6761253b93a109bb3a3f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170847
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Merge `SetBoundingRect_Impl` into
`SvxIconChoiceCtrl_Impl::FindBoundingRect` as that is the
only caller.
`SvxIconChoiceCtrl_Impl::SetBoundingRect_Impl` was ignoring
the bounding size being passed.
To be sure, still call `CalcBoundingSize` at the beginning
even though the return value itself is not used,
as the call to `SvxIconChoiceCtrl_Impl::CalcBoundingHeight`
that it does can result in class members like
`nMaxBoundHeight` getting updated.
Change-Id: I53b70bb8ddbf53afd9f95c38ce3dd05922e1110c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170846
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The method doesn't do anything for `bSelected = true`,
so drop the param, and only call it for the `bSelected = false`
case in `SvxIconChoiceCtrl_Impl::PaintEntry` instead.
Change-Id: I5e180a42f2960531d16e5df35ce0a4e9c63a1f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170845
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
No need to have a `bSolidTextRect` variable here,
just do the relevant call right away.
That also means that there's no need to save
and restore the previous fill color for the
`bSelected = true` case (it never gets changed),
so move that into the if block as well.
Change-Id: I57637e570b01e2a09708fc7776c867817a131d31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170844
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Drop extra drawing of a rectangle with the background
color just for selected entries.
It's unclear why that is done, and why it's done
only for selected entries, since the background
color used here is unrelated to actual selection
(e.g. is just white when using the gen VCL plugin
or kf5 with the light Breeze theme).
Drawing of the actual selection background
happens further down.
Therefore, drop drawing that extra rectangle
to simplify code and having one place less
to care about when switching to using native
drawing for the whole entry in an upcoming
commit.
I see no visual difference with or without
this commit in place with either gen or kf5
with either the "Insert -> "Hyperlink" or the
"Format" -> "Page Style" vertical tab pages
dialogs in Writer.
Change-Id: Ia1a7275238a919d245420b5ab4abaf7b3e85bcf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170843
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`WB_NOHIDESELECTION` never gets set for `SvxIconChoiceCtrl_Impl`,
which is only used by `SvtIconChoiceCtrl` to implement
the vertical tab bar.
Therefore, drop handling for that flag to simplify code.
Change-Id: I488edf6680f25dbafae61ec0435784d693d222b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170842
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a new `TabBarPosition` enum that describes whether
a tab bar is at the top, left, right, or bottom
(relative to the tab page content) and make use of
that for the new `meTabBarPosition` member for
`TabitemValue` that gets used for drawing tab items
via the native rendering API.
Set the position accordingly for both the vertical
tab control (`TabControl`) and `SvxIconChoiceCtrl_Impl`,
which implements the tab bar for `VerticalTabControl`.
For Qt-based VCL plugins, implement mapping to
the corresponding `QTabBar::Shape`. [1]
At least the Breeze Qt style uses that shape to decide
whether on what side of the tab item to draw the
selection/focus indicator.
This change by itself doesn't yet make any visual
difference for the Breeze style, as the "Top" value/
`QTabBar::RoundedNorth` is the default anyway, and
`SvxIconChoiceCtrl_Impl` doesn't yet use the
native drawing API for drawing focus/selection, but
only for mousehover feedback.
The plan is to implement that in a follow-up change.
[1] https://doc.qt.io/qt-6/qtabbar.html#Shape-enum
Change-Id: Idf1e41d3bc309d152a4a36d14e8617bd6429940c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170841
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The original fix for tdf#49853 only looked worked in the
case when both a key shortcut was pressed and the resulting
key event was not an input method event. If either of these
conditions weren't true, tdf#49853 would still occur.
Since we know which menu item is being triggered, check if
this menu item's key equivalent has been set to one of the
edit actions.
This change basically expands the fix for tdf#49853 to
include all cases that trigger a menu item, not just simple
key events.
Also, the fix for tdf#126638 would also fail when a key
shortcut was pressed in a modal window if the resulting key
event was an input method event.
Change-Id: Iaa2e06affe0e347380a383755684568fcdc26b9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170908
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
the contents of the referenced colorspace obj disappears so it gets
rendered blank
Change-Id: Iaa76d355b5903c695e74edadc329043156bad3b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170904
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
on right-click selection of entry to show context menu for
Change-Id: I045bd02103a37c94d6eb3fc1885ab19de79685c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170885
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Context modified because the same strings are in svtools/uiconfig/ui/calendar.ui
Don't know at all if these could be merged.
Change-Id: I72e37b54b53e4717f513dd313757af7318bbc4f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170898
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
To more directly support an additional alpha channel
for BitmapPrimitive data I have done some deeper
changes to the primitive stack, in a compatible
way. Quite some more graphic types and primitives
now support an additional direct alpha value. All
that is decomposed/created/broken down in a way
that needs no changes for existing renderers, in
already described ways.
The CairoPixelProcessor2D already uses this in the
processFillGraphicPrimitive2D implementation and
thus in the FillGraphicPrimitive2D. This works since
primitive productions now all try to create that
FillGraphicPrimitive2D type including an additional
alpha value - if possible and necessary.
Change-Id: Ib1b16491a2b3aee16f14cc8196e28af30a7cf9be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170900
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
window when adding a change in the document (Track changes mode),
round 3
Done to address loss of selection when an entry is added to the
beginning of the changes list. The patch reworks round 1 and 2 to
handle any entry insert position. It also keeps the selected entry
selected after a sort by document order.
Change-Id: Icb6f6b6b80ad9ddc5d008a00d195ceb7c1d6dc3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170828
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
* Update helpcontent2 from branch 'master'
to 44f0c2b1cd054a94ff7d4b3b563bc4a8674314e1
- Fix term in TOC help page
The term "Outline" was changed to "Headings"
Change-Id: I9185775e323088a2576c76f10a8ba1eae367e6d1
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/170886
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Jenkins
avoid doing GetItemState if we don't have a wrong list (the common case)
Change-Id: I3a1a22da657835ae37e8025d8ce21ad14d4e2c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
for the common case of having no paragraphs
Change-Id: I56ad9b5069021690954730188e406c133894dbee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170889
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
ENABLE_FIREBIRD_SDBC condition was added in
9aaf21b285
"sd: function to return a presentation info in a JSON document"
for no apparent reason.
Change-Id: Ia9a68340a73b87ed51a8b9c4a7fb3e67c59e7b68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170887
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Commit [1] introduced localization of color palette names. However, the name defined in Common.xcs is not localized, so we need to make sure that the standard palette gets selected on a clear profile.
[1] 5e45351c52
Change-Id: I2f03b3ab4bdbb77327388a754e1fc6f9d7413ba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170732
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
This provides a BitmapPrimitive2D extended by a unified
transparency component. It will decompose to a
UnifiedTransparencePrimitive2D containing a
BitmapPrimitive2D and the transparence, so no primitive
processor has to support this primitive directly - but
can if feasible. I plan to use that ASAP
Change-Id: I83ec84eaadc8ba2b21f0ba0cb1fdcf43bdc455db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170852
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
