so the createInstance throws, so the element doesn't get inserted into
the documents.
regression since f0cd6fe9075cd0aa00162474784ad804a07ed138
Change-Id: Ie6cef7a4f0d5ac8a34d41139c3439fc04e9c7f20
as used in the spec
Patch by: Regina
Review by: alg
(cherry picked from commit af6ada82a4634e4b64faf811eaf527c167c334bf)
Conflicts:
xmloff/source/draw/shapeexport4.cxx
Change-Id: I2fe339ba35cf589a9d4034446c671d4f09b0c0f0
Also found an error in SdrObjCustomShape::TRGetBaseGeometry when MirrorY was used
(cherry picked from commit 4116c33b12d3787c406f0348f89efcb1cf409507)
Conflicts:
xmloff/source/draw/ximpshap.cxx
xmloff/source/draw/ximpshap.hxx
Change-Id: Id85ae4c4f5e26d53d501c72b84fc0e1b5cfe23b2
For a new document the default is already effectively "false" due to
SwDocShell::InitNew() and the ODF and WW8 filters set it explicitly to
false... which is also the appropriate value for RTF and DOCX.
But only OOoXML and (perhaps) HTML (not sure) want "true" as the
default.
It is also mysteriously reset to "true" in
SwDoc::RemoveAllFmtLanguageDependencies() (which is called after loading
a template) for no apparent reason.
Change-Id: If5ad33c99f97412cb3ad4f9cec32f47825ed6f6b
It is not quite obvious what that commit attempts to do... especially
since the bugdoc attachment does not actually exercise the code that was
added in the commit, which changes the handling of the
"IsFollowingTextFlow" property.
The corresponding ODF attribute is style:flow-with-text, which has been
added in OOo 2.0. Investigation revels that MSO's ODF filter does not
support this attribute and acts as if it always had value "false".
The code in FillBaseProperties effectively acts as a default if the
value is not set; the ODF spec does not specify what the default should
be. But when an ODF document was written by MSO, "false" makes more
sense than the previous "true" default. Except when the document is not
ODF but OOoXML format, which indicates it's likely written by OOo 1.x
which did not support the attribute and acts as if it always had value
"true".
The Writer UNO API implementation is however not the right place for
format specific handling, so replace that with an addition to the
function reading the default graphic style that sets the
"IsFollowingTextFlow" property to false as a default, which should
have the same effect because all styles inherit from it.
Note: MSO 2010 Word always writes a default graphic style into ODF docs.
This has a side effect for loaded ODF documents: various newly
inserted objects have the property turned off then. But it turns out
this is actually an advantage, since the same behavior already exists
for _new_ documents (see SwDocShell::InitNew) so it is more consistent
now.
Change-Id: Iba6444a0515fd583398ff052fc5018254da31c30
Fixes a regression from the pick-best-image from draw:frame in ODF,
where before sometimes the XShape got deleted that the
UnoInterfaceToUniqueIdentifierMapper::registerReference stored.
For that, added a
UnoInterfaceToUniqueIdentifierMapper::registerReferenceAlways
function, which overwrites potentially existing earlier entries
with the same identifier string.
This fix was originally much more messy, but then dtardon committed
30b248dfe5bfb8a0649e36f22c943b3feb2f1385 which also fixes this here
bug. Now only sneaking in slightly less involved interface map
handling and a safeguard in ximpshap.cxx.
Change-Id: I87501e43518a5fc2fee166c45a4e2f01718f5228
This problem arises when there is a connector attached to draw:frame
element with multiple draw:image elements in it. The import code expects
that they are different representations of the same image (I have not
found if this is specified in ODF), so it only selects the most
"suitable" for import. To do that, it imports them all and then removes
all but the selected one. The image import context,
SdXMLGraphicObjectShapeContext, shares the parent frame's attributes,
which means that all the images in a frame have got the same ID. in
SdXMLGraphicObjectShapeContext::AddShape, the created css::draw::XShape
is registered with its ID... That means that anything that refers to the
frame's ID, like a draw:connector, will always get the _first_ image in
the frame.
Solution is to extend comphelper::UnoInterfaceToUniqueIdentifierMapper
to allow reserving an identifier and setting an interface for it later.
That way, SdXMLFrameShapeContext can reserve its own ID before it starts
importing the first draw:image, and then set the selected XShape at the
end.
Change-Id: I2e11cfd38e1e3534df2b3c01d85da0d755a266c3
- nanosecond precision
- signed (allowed negative) year
Also: assorted improvements / bugfixes in date/time handling code.
Some factorisation of copy/pasted code.
Change-Id: I761a1b0b8731c82f19a0c37acbcf43d3c06d6cd6
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
The slave SvXMLImportContext object for SdXMLNumberFormatMemberImportContext is
always leaked
Found by: zhangjf
Patch by: zhangjf
(cherry picked from commit e440770de29e96ce3e45792c0e94f133ade83680)
Change-Id: Ic0585bbb8e0e315548586ea1e49f55d0cc7ed2c4
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
