SVG files aren't supported in OOXML, but we can write it using the
MS OOXML extension, which is supported in the latest MSO versions.
For now this only implements the support in the exporter.
Change-Id: I688180fb5772f3999c2ee3020bc234f90d57cc2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157237
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Added Windows-ARM64 support in release 2.13, so external/lcms2/lcms2-win-arm64.patch.1
and external/lcms2/lcms2_sln are not neccesary now.
Fix external/lcms2/lcms2-2.4-windows.patch.
Change-Id: I3b1ca0e715a5f500966d58971188f95a1f232883
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157100
Tested-by: Jenkins
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
into the two entire separate cases they want to handle, there is
no reason to mix the two different cases like this.
Change-Id: I38e99e7ad6168a84e7a744f61407887825158902
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160248
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
AlphaMask has an operator=, no need for extra complication
Change-Id: Ib0f4aba4e1c9a4a594cc1cbc92f3a335dc9295a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160243
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
There is no way the format can change via the Bitmap*Access
mechanisms, and we already perform these asserts in
the constructor and operator=.
The code has been there since
commit 8ab086b6cc
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date: Mon Sep 18 16:07:07 2000 +0000
initial import
Change-Id: I75195f6fd4e29d7133e787131b6c8479a9188d1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160242
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
There's still work to do:
- retrieve privileges of each table since it's empty for the moment
- make the checkboxes editable (it seems read only)
- make the user management work (creating one doesn't work for example)
Change-Id: Ia1d9c4db7faae16ec1903c5d7aa5e679ce5e944a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160244
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
* Update helpcontent2 from branch 'master'
to a1840f2baee7b129990d6c0b218aae1b8d0304d7
- mark untranslatable code and control name in SF Dialog and DialogControl
also fixed typos caused by split paragraph
Change-Id: I6c4d3badb30629c4bf58011089b4beeb1438204a
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/160051
Tested-by: Jenkins
Reviewed-by: Alain Romedenne <alain.romedenne@libreoffice.org>
* Update helpcontent2 from branch 'master'
to a0058e57883886e2249e4fc2d03e15454f267f4b
- mark bookmarks and paragraph in SF FormDocument as translatable
Change-Id: I5867af5313ca86b11b79d59b6a042b16ce9dfee0
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/160053
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
In the document we set the mime type for the images stored, but
at import we never actually used the mime types. We always did
mime type detection from the filename extension. The problem with
this is that files stored as base64 streams don't have a filename
so it is also not possible to determine the mime type from the
file name.
The consequence of this is that we can't know which image to take
if we have multiple images (fallback images) so we always take the
last one, which could be the wrong one. This happend in the test
document.
This changes the behavior so that we always first use the document
set mime type as there is no reason to not trust that. Only if the
mime type isn't provided by the document we use other mime type
detection methods.
Change-Id: I175c509ce5f11eab2c0454d4d9901ca1fe975272
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160237
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
On first master page, move picture from page background to an object at
the background
Change-Id: I0e01ee9cad4a282c98e3678a7a45cfe13698e0e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159807
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
instead of allocating on the heap, it is small
Change-Id: I79eec6605a04c09d9a984cd1a719affb5b06dff3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160195
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to get the parent window.
SfxTabPage::GetDialogController
returns mpImpl->mpSfxDialogController
and that is set in SfxTabPage::SfxTabPage ctor with
mpImpl->mpSfxDialogController = dynamic_cast<SfxOkDialogController*>(m_pDialogController);
and GetDialogController returns that mpImpl->mpSfxDialogController
while nearly everything is derived from OKDialogController, not
everything, like this column dialog case is, so
mpImpl->mpSfxDialogController is null and it all fails.
This same page is inside format, page styles as "columns" but that's the
usual multi-page dialog derived from SfxOkDialogController, its just
this single page dialog that is different.
The original idea was to wait until this parent dialog is needed to
figure out what to use. We have this SfxTabPage::SetDialogController so
the dialog controller and page can theoretically change after the ctor,
though maybe that doesn't happen in this case.
Looking at SfxTabPage::GetFrameWeld that one always returns the current
parent (of m_pDialogController, not the dynamically casted
mpImpl->mpSfxDialogController) so in the best choice to use in general.
Change-Id: I4617212fb27fdeeb0afc41123f7bc1b73f495c32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160223
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
... and gradle to 8.2, as suggested by Android Studio.
Change-Id: I1a1df5f43b7a95d24308873b708d3d21b76aa7f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160200
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
a sample commit to test this
Change-Id: Ibc1a1f75b908e245395a05e81c26158c67e36257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160214
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
