|Age||Commit message (Collapse)||Author||Files||Lines|
vector-7.0 has bitmap import filters which set both the preferred size
and the preferred pixel size on a BitmapEx. This means that when
ImpGraphic::ImplGetGDIMetaFile() gets the bitmap size, it can use
Interestingly, the "fall back to pixel size from logic size" logic is
still there at other places, e.g. at ImpGraphic::ImplGetPrefSize().
However, on this branch, the bitmap import filters (e.g. PNG import)
only sets the preferred pixel size and set the map mode to pixel. This
means that directly getting the preferred size results in a zero size,
so exporting such a bitmap to WMF/EMF will result in a white rectangle.
Fix the problem by using ImplGetPrefSize() (which has the fallback
logic) instead of maEx.GetPrefSize() directly -- both for the metafile
action and for the preferred size of the metafile.
Bootstrap variables have multiple sources, so the environment variable
way continues to work. This also allows disabling EMF+ using the
-env:EMF_PLUS_DISABLE=1 cmdline parameter, which is useful when soffice
is not started in a shell.
(cherry picked from commit 71a1ea29b8793a8db012dd3452ef0dd87f1be36a)
Regression from commit 5868745db74ae930edb0058490076d82aaeafbe9
(emfplus: make VectorFormats Emf/Wmf/Svg work, 2017-06-12), we used to
export graphic data as-is when the requested format is WMF and the
source format is EMF or WMF.
Restrict the as-is copying to the WMF source format only.
(cherry picked from commit 24deea41f820399593210c8806edd68940f77c20)
This was already working on master since commit
5868745db74ae930edb0058490076d82aaeafbe9 (emfplus: make VectorFormats
Emf/Wmf/Svg work, 2017-06-12), but a matching testcase was missing.
[ And on this branch, fix the actual problem by picking the small
relevant subset of the above commit. ]
(cherry picked from commit 6bb0e09e2423ae00e06e6b7ae2c5a0af6ca100a1)
This builds on top of commit c123bfff501229f398a1b679fc7434b82d53685c
(Bin overly eager early return that stops replacement image creation,
2020-08-20), and handles a similar case, when
SwView::ReadUserDataSequence() is not called at all.
The result is the same: no shell is selected on the command dispatcher
stack, so .uno:UpdateAll is ignored and the replacement images are not
(cherry picked from commit 693f12ad57912c2356a197d9a794e6108ce79ef2)
All these new test suites are named in a way, so that in case the fix is
in sw/source/foo/bar/, then the matching test suite is sw_foo_bar.
Rename to this schema, so next time a bug is fixed in that directory, we
don't need to add a new suite.
(cherry picked from commit 0be6168c5a7b1493a22222dc0967b5e8a0153386)
Unlike the c123bf commit, this commit does not cause the crash that
was caught by the crash-testing system.
(The crash could be reproduced by:
wget -O ooo38104-1.sxw https://bz.apache.org/ooo/attachment.cgi?id=19889
./instdir/program/soffice.bin --headless --convert-to docx ./ooo38104-1.sxw
In this commit, I reinstate the "early return" in
SwView::ReadUserDataSequence() that I dropped in the c123bf commit,
but instead move the SelectShell() call earlier, so that it will be
executed before the potential early return.
The problem that we try to fix here is the one that the fresh
CppunitTest_sw_updateall_object_replacements checks, so to reproduce
that problem, revert both this commit and c123bf, and then run that
(cherry picked from commit 6e0bb3fc4e89ddb85ddf40889b11a0c0bd4ab607)
(cherry picked from commit 3f291bb285335efbc2f21a08bdcb23d92911940c)
Commit 1392fd6a7eaf9f507639096984c2a0108f254795 (sw reqif-xhtml export,
embedded objects: handle Ole10Native stream, 2020-04-30) added support
for handling an OLE1 stream which contains something other than OLE2
However, that assumed a fixed class name ("Package") and a matching
class id. Fix this, similar to how the import side was fixed with commit
247b247dadc8f0133a8eb94f1423a29315cf998a (sw reqif-xhtml import,
embedded objects: handle non-package Ole10Native stream, 2020-10-16).
(cherry picked from commit 326c8d06070a4a41a666db919702f7c423dc7a18)
Commit 800085d4fb0831f2065e86bfd99164cd89998fcd (sw reqif-xhtml import,
embedded objects: handle Ole10Native stream, 2020-05-04) added support
for handling an OLE1 stream which contained something else than OLE2
However, that assumed a fixed class name ("Package") and a matching
class id. Improve this, so that the class id is created dynamically,
based on the OLE1 class name.
The class id can be figured out by putting the OLE1 data in an RTF file
and converting that RTF file to DOC using Word.
(cherry picked from commit 247b247dadc8f0133a8eb94f1423a29315cf998a)
Next to the native data of an embedded object, the presentation data /
replacement is included at several layers:
- the OLE2 container may have it
- the OLE1 container may have it
- the RTF container may have it
- the PNG file next to the RTF container may have it
Given that various consumers pick one of the above, we try to provide
presentation data in all layers.
We already had code to generate the OLE1 presentation data from the OLE2
container, but we gave up for OLE1 in case the OLE2 container didn't
have it. This means that in case the RTF container is wrapped in a
proper RTF file, Word refuses the edit the embedded object.
Fix the problem by taking the presentation data from RTF for OLE1
purposes, in case it's missing from the OLE2 container.
(cherry picked from commit 0d027abbc5609b096d2a954e77aa7354a55928ab)
If an embedded object has some native data, we provide presentation data
(replacement graphic) for it in the OLE1 container. We usually take this
from the OLE2 container, but it's OK to omit the presentation data
So refactor to have the presentation data available from the OLE node
(already used for RTF purposes) earlier, that'll allow taking the OLE1
presentation data from RTF if it's missing from OLE2.
(cherry picked from commit 4d33262b1b652b57f222c9f1cce7d976725399d4)
and improve the WriteOString method, we can avoid the strlen here, we
already have the length
One change in behaviour to be noted - if the string contains
trailing zero bytes, which ARE INCLUDED IN THE STRING LENGTH,
i.e. I'm not talking about the normal terminating zero, then this
patch changes behaviour because we will now write those zeros to
[ Just the sw/source/filter/html/htmlreqifreader.cxx part. ]
(cherry picked from commit 241bee7e4be6a205fae0d3f5508e084462c7ca55)
[ Just the sw/source/filter/html/htmlreqifreader.cxx part. ]
(cherry picked from commit 7075ce2fee860daa6affde92b256838aaa3d7d87)
The skipping causes a customer's Java code that handles some .odt
document to unexpectedly not create object replacement images in the
The problem is that in the bad case, the SwTextShell is created later
than .uno:UpdateAll is dispatched, so the dispatch does nothing.
SwBaseShell::Execute() for FN_UPDATE_ALL is not called. And this is
required, becase that calls setUserAllowsLinkUpdate(true), so that on
save, when EmbeddedObjectContainer::StoreAsChildren() in comphelper/
hits the 'if ( !xStream.is() && getUserAllowsLinkUpdate() )'
condition, then we create a replacement image.
This is a Basic script that demonstrates the same issue:
desktop = CreateUnoService("com.sun.star.frame.Desktop")
Dim props(0) as new com.sun.star.beans.PropertyValue
props(0).Name = "Hidden"
props(0).Value = true
component = desktop.loadComponentFromURL("file:///.../test.odt", "_default", 0, props)
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
frame = component.CurrentController.Frame
dispatcher.executeDispatch(frame, ".uno:UpdateAll", "", 0, Array())
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
(cherry picked from commit d19a21a81bea24cdcfc8618ed3d37b825e638f65)
Extend SVGTextWriter::setTextPosition(), so when it looks for a text
action in a metafile, it recurses into transparency groups, so the text
is not lost.
Extract part of SVGActionWriter::ImplWriteMask() into a new StartMask(),
so we can detect the case when the transparency group has a constant
alpha, i.e. no complex mask is needed, just an opacity value.
When looking for text, remember if we saw a request for text opacity and
make the transparency group writing in SVGActionWriter::ImplWriteMask()
conditional to avoid duplication. This is needed because once we're
inside <text>, we don't want to write an invalid transparency group via
<g>, rather we want a fill-opacity on the existing <tspan>.
With this, the SVG export is on par with PDF export for semi-transparent
(cherry picked from commit 666f252457bdb4371d15380a0289e107b2dfbe84)
This prepares the test for semi-transparent text, but the assert
is not yet enabled until the bug gets fixed.
(cherry picked from commit ebb7cd91ec2bbbba3e4d2ce106b24933b23f4d14)
Regression from commit 74844277cc2194c9e43f5bd7a6f78a9603da32f3 (disable
generation of ole previews in ODF format until after load, 2016-09-13),
if the document has charts without previews, it's loaded, fields are
updated and saved, we no longer generate those previews.
Given that Tools -> Update -> Update all is always an explicit user
action, restore the permission to update OLE previews / links before
performing the actual update.
With this, comphelper::EmbeddedObjectContainer::StoreAsChildren() will
generate those missing previews inside the getUserAllowsLinkUpdate()
(cherry picked from commit 2aad85f84235f362604b5fd385bb77de839d2014)
Writer just has a list of text nodes, but ODF and HTML can have multiple
paragraphs inside <li>, in case the non-first text nodes have their
RES_PARATR_LIST_ISCOUNTED set to false.
Improve b6f7a4908d1c3fc610440a1cbbbc1673a53da8b6 (sw XHTML export:
properly write <li>...</li> around paragraphs, 2018-04-11) to make the
decision around when to write </li> based on not only the current but
also the next text node. This way we omit </li> for non-first paragraphs
inside <li>, but keep writing it in other cases.
(cherry picked from commit 119b6876c92e4cdae44583c4b1b1419d3533e3ee)
This is the import side of commit
1392fd6a7eaf9f507639096984c2a0108f254795 (sw reqif-xhtml export,
embedded objects: handle Ole10Native stream, 2020-04-30).
(cherry picked from commit 800085d4fb0831f2065e86bfd99164cd89998fcd)
and didn't stop copying at the size limit arg
(cherry picked from commit bcdaaf62d41728eb757ff2b9cb95c2df2791e2f4)
Normally the embedded object has some OLE2 native data, and we insert
our OLE1 header before that. But in case the OLE2 data already has an
Ole10Native stream, then don't create an OLE1-in-OLE2-in-OLE1 output:
it's pointless and some consumers have trouble parsing that.
(cherry picked from commit 1392fd6a7eaf9f507639096984c2a0108f254795)
When including a PDF as an image, it's represented internally as
a Bitmap with additional PDF data. On SwapIn, LibreOffice just
imported the PDF data missing the PDF preview. The Graphic also
gad the wrong image type, which results in a busy loop on master,
with a strange / unhelpful STR_COMCORE_READERROR generated by
This is a workaround to generate the Bitmap on SwapIn, which
will really slow down LibreOffice when importing many PDFs.
I guess the job of generating the PDF previews should probably
be deferred to a thread or a low priority Scheduler task, just
like the general image loading is handled.
(cherry picked from commit 3a88795c1211c62277dc646e61c2ba8306febe37)
The problem was that the <p align="..."> markup was used, while XHTML
prefers the <p style="text-align: ..."> markup. Note that
OutHTML_SvxAdjust() is a special case: other paragraph-level pool items
would just call the equivalent of OutCSS1_SvxAdjust().
Fix the problem by bringing the paragraph alignment case close to e.g.
SvxULSpace handling, which is the m_bNoAlign == true case.
On top of this the reqif-xhtml output is then valid out of the box,
since IgnorePropertyForReqIF() already filters out not allowed CSS
(cherry picked from commit 9d38360e2ed06b2083d56b637f009411d41f36eb)
The value of these coordinates are not allowed to be larger than 14 400,
and Adobe Reader complains about them.
Use UserUnit to declare in case we won't work with points anymore, but
with a larger unit. This will mean UserUnit=2 in practice, since e.g.
Draw has is page size limited to 600x600cm, so larger values won't
happen, at least not for now.
(cherry picked from commit 4830592b780833cf5eee2aef30bc9c5d444dfb24)
The line shape itself didn't really have a height, rather it had a
stroke. For some reason, the SVG mask then decides that nothing has to
be painted there, so unless the line is entirely opaque, the line shape
gets lost on export.
Fix the problem by handling transparency similar to the PDF export,
which detects if the whole purpose of the transparency gradient is to
pass around a transparency percentage. We don't need a mask in that
case, we can just use opacity as described at e.g.
(cherry picked from commit ea52d24b5a19bb54f91cd679a977332ec330880d)
Start Draw, draw a rectangle, export it to a SVG document.
Open the SVG document with a browser or Inkscape: instead of a
rectangle, you will see a self-crossing polygon.
This issue is due to a clean up commit
(9d8c206ee4a5c130e11a4e786b4286f3362f9ca1) about string concatenation
which has not taken into account that operations are performed from
right to left.
Reviewed-by: Jan Holesovsky <firstname.lastname@example.org>
Tested-by: Jan Holesovsky <email@example.com>
(cherry picked from commit 877b605bf519f20179e5de1beb5bb16cd431aa89)
(cherry picked from commit 643a1492bd648fbd803ca86aca600cc2bdaf5819)
Regression from commit e4da634b983052f300cd0e9b2bbaa60eb02c1b28 (sw: fix
moving more than 20 table frames to a previous page, 2020-03-30), asan
found a heap-use-after-free during CppunitTest_sw_ooxmlexport5
CPPUNIT_TEST_NAME=testOldComplexMergeTableInTable, the follow frame is
deleted like this:
#1 in SwTabFrame::~SwTabFrame() at sw/source/core/layout/tabfrm.cxx:145:1 (instdir/program/libswlo.so +0xec98ba5)
#2 in SwFrame::DestroyFrame(SwFrame*) at sw/source/core/layout/ssfrm.cxx:389:9 (instdir/program/libswlo.so +0xec8495f)
#3 in SwTabFrame::Join() at sw/source/core/layout/tabfrm.cxx:1390:9 (instdir/program/libswlo.so +0xecb6088)
#4 in SwTabFrame::MakeAll(OutputDevice*) at sw/source/core/layout/tabfrm.cxx:1865:9 (instdir/program/libswlo.so +0xecbc1f6)
#5 in SwFrame::PrepareMake(OutputDevice*) at sw/source/core/layout/calcmove.cxx:370:5 (instdir/program/libswlo.so +0xe519919)
#6 in SwFrame::Calc(OutputDevice*) const at sw/source/core/layout/trvlfrm.cxx:1789:37 (instdir/program/libswlo.so +0xed8424e)
#7 in SwLayAction::FormatLayoutTab(SwTabFrame*, bool) at sw/source/core/layout/layact.cxx:1485:15 (instdir/program/libswlo.so +0xe897ea9)
Fix the problem by not moving multiple tables to a previous page in one
iteration when the table is a follow one.
(cherry picked from commit 10036bd52e094b5c9b02ff5142829f0825a20571)
Steps to reproduce the problem:
- have some content on page1
- have more than 20 tables on page 2
- delete all content on page 1
The first 20 tables are moved to page 1 then the layout process stops as
the layout loop control aborts it:
warn:legacy.osl:8282:8282:sw/source/core/layout/layact.cxx:544: LoopControl_1 in SwLayAction::InternalAction
and the remaining tables stay on page 2, even if page 1 would have space
There are various other ways to trigger the same problem, e.g. have a
ToC, add lots of headings, update the ToC, undo.
Fix the problem by doing more work in SwLayAction::FormatLayout in a
single iteration: if a table frame is moved to a different parent we can
still format the table's next frame in the same iteration with a bit of
(cherry picked from commit e4da634b983052f300cd0e9b2bbaa60eb02c1b28)
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
(cherry picked from commit 4fb7390956a193e00c1b599129b89933c41f98ae)
This fails with:
cppunittester: svx/source/dialog/charmap.cxx:1648: void SubsetMap::InitList(): Assertion `eBlockStart == eBlockEnd && eBlockStart == eBlock' failed.
And probably ~always did, just I ran the tests in an assert-disabled
Disable the test so other test failures can be noticed fast. (Especially
that the test is not too relevant on this branch, it's for Online.)
[ The test works on master, so just disable this on this branch only. ]
The value 'fontAttribute' is optional and may be null,
results in missing characters.
The case of 'metafile' was missing and leads to
low resolution rendering.
(cherry picked from commit 52a2a0101f71b21876f17d5419132ffa27f6e35d)
(cherry picked from commit e3ccc09417731e61d3d35ed4cc1a7436e05f5325)
Regions are specified as a binary tree of region nodes, and each node must
either be a terminal node or specify one or two child nodes.
Nodes contains two child nodes:
RegionNodeDataTypeAnd = 0x00000001,
RegionNodeDataTypeOr = 0x00000002,
RegionNodeDataTypeXor = 0x00000003,
RegionNodeDataTypeExclude = 0x00000004,
RegionNodeDataTypeComplement = 0x00000005,
RegionNodeDataTypeRect = 0x10000000,
RegionNodeDataTypePath = 0x10000001,
RegionNodeDataTypeEmpty = 0x10000002,
RegionNodeDataTypeInfinite = 0x10000003
RegionNode must contain at least one element.
(cherry picked from commit d0c4cee7e5ad00363d264aec0011a4b07983b19d)
Thanks to Antti Levomäki and Christian Jalio from Forcepoint.
(cherry picked from commit 3686a3fc1b2eaee53b1ab32f33455b2b37aa8c6e)
Steps to reproduce the problem: select an image in Word on Windows,
copy, paste into Writer -> nothing happens. A workaround is to use paste
special, and select the metafile paste, not the bitmap one.
The root cause was that clipboard contents on Windows can have different
handle types and we only supported the memory and the metafile cases.
An alternative fix would be to handle this at a higher level, e.g.
TransferableDataHelper::GetBitmapEx() in vcl could fall back to EMF when
the bitmap formats fail, but that would not work for other applications
that only offer bitmap formats with a stream handle type.
(cherry picked from commit 5d1a540963d1c5b952655414fc77367f67db968d)
The data was given to the PDF filter, but then we stopped iterating
right after finding our output stream. Seems this was always like this,
ever since commit 4111b430a0a7954416ff95794a8ffb8fbc4472e3 (#101570#:
added pdf filter, 2002-08-13).
(cherry picked from commit 3b9797671ce49f53b2c583c9201c348b55b10c96)
[ Testcase not backported, pdfium is too old on this branch. ]
Regression from commit b6588bd7c831ce88a29131ca7ea8d3f3e082564e (Reduce
image resolution by default in PDF Export, 2014-03-02) the problem is
that in case you have small enough bitmaps, then these used to look
OK at reasonable zoom levels, but now we intentionally scale down
bitmaps by default.
That makes little sense for tiny images, do this only for large ones.
(cherry picked from commit b894ec7fadb8ca6bf0b33fa9eee4b9303e8161d4)
[ Testcase not backported, pdfium is too old on this branch. ]
The only reason commit 4cd3c436923bfba281b1bf16d9785208a2119cea (sw
reqif-xhtml export: limit values of the style attribute, 2018-04-11)
missed these is because they write their css properties directly, not
going via SwHTMLWriter::OutCSS1_Property().
Also adapt testReqIfWellFormed: its intention was to make sure that in
case these properties are written, then inline CSS is used: that is true
for XHTML, but not for ReqIF-XHTML.
(cherry picked from commit 1655819c8914efad28f218f56d8d89d4e4bd9488)
In general, all "foo" elements should be started as "<reqif-xhtml:foo"
in the reqif case, but not for comments, which stay as "<!--".
(cherry picked from commit a73483817faac173b2b9d4e970d2a05bfedc6798)
And also search for the '"<" OOO_something' pattern, and fix up all
cases where we forgot to call GetNamespace() when opening an element.
(cherry picked from commit 186ef501a305d452da1f36aa51106dba181dc324)
This is similar to commit e0f20211a8048a87b078aa4cf0f28c0c847487ad (sw
reqif-xhtml import: add a new AllowedRTFOLEMimeTypes parameter,
2019-12-16), except that was for the import and this is for the import.
The situation was similar, SfxBaseModel::impl_store() still had the
custom store parameters, but later functions lost it, so at the end
OutHTML_FrameFormatOLENodeGrf() in the sw HTML export could not respect
Fix the problem in a similar way, so the SfxMedium instance created for
the duration of the export provides the custom options via
(cherry picked from commit 037cd13af81f8a1169d01e95036ed942f261f9a6)
The HTML import is an old-style filter, so it has no XFilter
implementation where filter() would get custom parameters out of the
box. One way would be to fix by adding one more entry to the aFormalArgs
table under sfx2/, but doing that with a random parameter of a random
import filter feels dirty.
So instead make SfxMedium store all arguments as-is, this way accessing
other keys is as easy to accessing the already available FilterOptions
Regarding the actual filter change, don't require "text/rtf" as a mime
type for embedded objects in the reqif XHTML import, so that in case the
file has e.g. application/rtf, then that works as well.
In case an (UNO) client wants to still limit the accepted set of MIME
types, that's possible via the new parameter.
(cherry picked from commit e0f20211a8048a87b078aa4cf0f28c0c847487ad)
[ Backport note: master uses std::set for m_aAllowedRTFOLEMimeTypes,
here we use std::vector, as comphelper::sequenceToContainer() can't
handle sets on this branch. And given that the elements in this
container will be small, it does not matter in practice. ]
- Make font color only work with the RGB color, otherwise the preview
would be white for e.g. half-transparent red.
- Add label and widget to see already set transparency.
- Add a flag to show these only for Draw/Impress and leave Writer/Calc
- Update returned item set to contain transparency in case the widget
And start a drawingml test suite in oox, so the test and the tested code
is close to each other (just like how it's done in chart2/ already).
(cherry picked from commit 1e64d9ebaa231caef5fb062009b8f76465e415f4)
Test this from sd, so that SdModelTestBase::saveAndReload() calls
BootstrapFixture::validate() for us.
(cherry picked from commit 4dbb33a1c21948bebcf890c2f8ceb56b15a87936)
The color's alpha is normally lost when we roundtrip SvxColorItem's
tools Color via TextSimplePortionPrimitive2D's basegfx::BColor.
One way would be to add an extra transparency member to the primitive,
like BackgroundColorPrimitive2D does that.
However, a much easier way is to go via UnifiedTransparencePrimitive2D,
that way we handle transparency in
drawinglayer::impBufferDevice::paint(), rather than platform-specific
code like CairoTextRender::DrawTextLayout() in the Linux case.
(cherry picked from commit 81b0d5393ca4cf2ff0954e53b05928cde047c2e0)
Keep the type internally as sal_uInt8, to be used as an alpha channel.
Keep the type externally as sal_Int16, so it's consistent with the fill
(cherry picked from commit 6fafae4d109f5768621a11deb394b1b0c4dc5606)