The problem was that in case a paragraph is empty, and it has both a
character style and direct formatting, then the doc model created by the
ODT and DOCX import is like this:
<text>
<attrset>
<item whichId="8" which="character font size" value="nHeight: 240, nProp: 100"/>
</attrset>
<hints>
<hint end="0" whichId="52" which="character format" value="name: hello"/>
</hints>
</text>
I.e. the direct formatting is stored in the attribute set of the text
node directly, while the character style is stored as a hint.
MSWordExportBase::OutputTextNode() tried to read the hints and if there
were not any, then tried to read the attribute set, while in this
situation we need both.
Change-Id: I71fd10f6d00246348e77fee5431cb4e2a7c9b349
The SdrObject returned from SvxMSDffManager::GetShape() is owned by the
caller; since it's not inserted anywhere it has to be deleted.
Change-Id: Iaac6467592ec4151173a586a6dc71f9bc44b44f0
See 8c677716c4707ccd86b152ae504841affb393cc0 (DOCX drawingML export: if
shape has textbox, export its contents as shape text, 2014-06-06).
Change-Id: I5b1afae4d1b80c9b225096677f7d7ae77ff90f5b
Apparently xmloff supports at least one value that has no equivalent in
OOXML; just use "none" for now.
Change-Id: I76d2802c7c91ea756125e66c229ec5fdb2e7ec3b
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>,
changed from a macro- to a template-based solution. (Unfortunately MSVC 2012
does not support explicit conversion operators. Worked around that with
explicit #ifs rather than some HAVE_EXPLICIT_CONVERSION_OPERATORS and
SAL_EXPLICIT_CONVERSION_OPERATOR ainticipating we hopefully soon move to a
baseline that requires unconditional support for them.)
Change-Id: I4a89643b218d247e8e4a861faba458ec6dfe1396
The real news here is that "comma" and "dot" was swapped on export, the
rest is just a fixup of recent breakage.
Change-Id: I54045f5837652dc38a30361e21ced25aeaf58257
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Scenario is that the original document has a table style, which sets
borders around the table, so A1 cell gets top and left borders (and none
for right/bottom). Then on export, if we write A1 as table default, then
this overwrites the table style, so the real right / bottom borders from
the table style are lost, as on export we think that they are available
from the table style already, so we don't write them.
Regression from commit ae61569eea0719a882010cfbb260a1a0d690d974 (oox: Do
not overwrite table style properties, 2014-04-03).
Change-Id: I54c10ffc2ade65260693b769274b1311efc086f9
Put the TOOLS PolyPolygon class in the tools namespace. Avoids clash with the Windows
PolyPolygon typedef.
Change-Id: I811ecbb3d55ba4ce66e4555a8586f60fcd57fb66
