ODF standard handle 'textarea-vertical-align' as a
'graphic-property' which "specifies formatting
properties for chart, draw, graphic, and frame elements".
So this change fit to the standard.
Change-Id: I956f512953380983c2c882e943178335fd4dbfeb
and draw:glue-point it is necessary to move the GluePoints from the last
draw:image where they were automatically imported to the surviving one if these
are different
(cherry picked from commit c011af1087411a9bacd29cd479c807e698b2e92c)
Conflicts:
xmloff/inc/xmloff/xmlictxt.hxx
xmloff/source/core/xmlmultiimagehelper.cxx
xmloff/source/draw/ximpshap.cxx
xmloff/source/draw/ximpshap.hxx
Change-Id: I8f6c875767e9cbfee74838742401356df002b051
Set to true for export, false for import. If export true, an
XMLPropertyMapEntry with mbImportOnly==true is not added to the
mappings. This to be able to have more than one mappings for import
(for example a current extension namespace and the future namespace
proposed to the ODF-TC, or corrected typos in element or attribute
names), but map only to one entry on export, of course.
Change-Id: Ia01ea949c88eda2f8a6c10f51c59e35e7abdcaf3
For now, this checks for a trusted referer (if the BlockUntrustedRefererLinks
configuration prop is set) in utl::MediaDescriptor::impl_openStreamWithURL and
SvxBrushItem::GetGraphicObject. Checking in additional places will probably be
necessary to block /all/ unwanted communication. Also, some places marked
/*TODO?*/ currently pass in an empty referer (which is always considered
trusted) and will probably need to be adapted.
Ideally, Referer URIs would never be empty (and consistently use something like
<private:user> for cases where access is explicitly initiated by the user and
should never be blocked), but that's a very daunting task, so start small by
identifying the places that potentially need blocking and adding appropriate
Referer URIs there. Also, Referer information should always be computed as
freshly as possible from the context in which an access attempt is made, but,
again, always carrying the information from the context all the way to the
relevant functions is a very daunting task, so for now store the information
upon object instantiation in some cases (SvxBrushItem, SdrGrafObj, ...).
The Referer URI (css.document.MediaDescriptor property; SID_REFERER) was already
used to track macro execution, and there is one place in
SfxApplication::OpenDocExec_Impl where opening of hyperlinks (explicitly clicked
by the user) is done that needs the current document's URI as Referer to check
execution of macro URIs but needs an empty (or <private:user>, see above)
Referer to not block non-macro URIs. Special code has been added there to
handle that.
Change-Id: Iafbdc07a9fe925d9ee580d4f5778448f18f2ebd9
...where multiple parallel calls to xmloff::token::ResetTokens or
xmloff::token::GetXMLToken can see dangling pOUString pointers. There is no
point in releasing this (bounded) amount of memory referenced from global
aTokenList, anyway.
There is still a race when parallel calls to xmloff::token::GetXMLToken write to
a pOUString pointer in parallel, but that's more harmless, and maybe calls to
GetXMLToken are synchronized by Solar Mutex? Calls to ResetTokens (e.g., via
URP remote release request -> ~ScXMLExport -> ~SvXMLExport) were definitely
/not/ synchronized via any mutex.
The xmloff::token::Inc/DecRescheduleCount functions are now pointless and have
been removed, too.
Change-Id: I85905d4de1f042ed5c9a37589f942910d8ef80fd
When multiple image child elements are inside a frame, each one is
imported and gets unique name via SwDoc::SetFlyName(). But the
retained one is not necessarily the first one, which is the only one
that may have the original name.
Also the solveMultipleImages needs to return a smart pointer, as nothing
else keeps the image contexts alive.
(regression from 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70)
Change-Id: I28a8a752f3eed176cc2ebb4c9af11a0dd4d18ea6
The attribute is only exported for ODF versions > 1.2; use the new
loext (LO_EXT) namespace.
Change-Id: Ie44e4b851c4adf52d8cc4fc2cbe37d6c3a9941d8
Reviewed-on: https://gerrit.libreoffice.org/4830
Reviewed-by: Thorsten Behrens <tbehrens@suse.com>
Tested-by: Thorsten Behrens <tbehrens@suse.com>
XML_NAMESPACE_LO_EXT can be used for elements and attributes that are
not yet specified by OpenDocument.
Change-Id: Id29392533d46f6592d964ce79c05ffefa4d69ebc
Reviewed-on: https://gerrit.libreoffice.org/5419
Tested-by: Thorsten Behrens <tbehrens@suse.com>
Reviewed-by: Thorsten Behrens <tbehrens@suse.com>
b40bcde076f9fabf24810d2520e878d604d99637 made writing .odp use style:font-name
and office:font-face-decls, instead of using fo:font-family . But the reading
back was broken, as xFontDecls is not set
in XMLTextImportPropertyMapper::handleSpecialItem(), so the font data was
ignored. And xFontDecls was not set because it's set while reading
office:font-face-decls, which is at the top of the xml document, but even
before the xml is parsed, the call to SdXMLImport::setTargetDocument() calls
GetShapeImport(), which creates XMLShapeImportHelper instance, which calls
XMLTextImportHelper::CreateParaExtPropMapper(), and XMLTextImportPropertyMapper
is created with rImport.GetFontDecls() still being NULL at that point.
And it actually doesn't seem to make any sense to just pass around all
the pointers to XMLFontStylesContext, as eventually it's always just the one
from SvXMLImport. So simply dump all that and make the one single place
that actually uses it (i.e. XMLTextImportPropertyMapper::handleSpecialItem())
refer directly to SvXMLImport::GetFontDecls().
Change-Id: Ib1b3e4b1bcaf87ca3e4703d1cc1563ad6b3f9ce7
This prepares to be able to read/write the attributes, it does not
enable proper handling of unknown language tags yet. An unknown tag
usually falls back to SYSTEM locale.
Change-Id: I4a78e8fd37deae188c69570157bc4589a712bc7a
