As it is wrong (says Thorsten) to override the methods from
XFastContextHandler in ContextHandler2 in its derived classes, mark them with
SAL_FINAL to catch that (when compiling with a compiler thaty supports
"final").
Do corresponding changes then; change createFastChildContext() methods to
onCreateContext() ones instead.
Now the unit tests work, and a sample PPTX that uses embedded OLE thingies
loads without crash, but unfortunately it looks like crap...
Change-Id: Ie30022f37418ba9caf8ce59fe4003b808fa900f3
Reviewed-on: https://gerrit.libreoffice.org/4578
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
Change many classes in oox to be based on ContextHandler2 instead of
ContextHandler. That supposedly adds MCE support.
This is a minimal initial effort. It compiles and links but doesn't work
(CppunitTest_chart2_export fails). Follow-up coming...
Change-Id: If89117abd48cfead468633fd7fce1ea785f6f420
Reviewed-on: https://gerrit.libreoffice.org/4577
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
nParamsCount was set to the double of the expected value, but the code
handling the command only took the first set of parameters. Removing
this 2* in nParamsCount.
(cherry picked from commit 442ad6eef9d6e1588e4985e97ec3eafd6289f9ae)
Conflicts:
oox/source/vml/vmlformatting.cxx
Change-Id: I2a4bb07fc9167e056a52c7adfbee9e1ef8e2636c
see origin f1ecd5ff46a217ee9f4323a08f03e59a53ef551e, f9d08dd5c9af8f8128371540e
& follow up 0a686a9bb54b5c1b3a45810e2601a098c0272c33
Change-Id: I1a10de6984f7ed78efdf6f32bfca14b433b24405
There's a document which has coordsize="6094,0" path="m444,424r6094,e" ,
where the 0 is somewhat questionable (and the spec doesn't seem to say
anything about it), but given it's a horizontal line, vertical coordinate
space size shouldn't matter, so treat it as 1, making the space visible
and avoiding division by 0 in our code.
Change-Id: I53725cd73a699b8e6d3c96e8fc39c276d082bc0c
a) make sure backcolor is skipped when libreoffice backcolor
is default. Libreoffice default is 0 ( but if we write that out mso
reads it as black )
b) don't take the label default backcolor in exchange for the
libreoffice default. Libreoffice default backcolor for label is white,
mso's default is rather different ( and never seems to be used )
c) re-enable compObj export ( seemed this was disabled unintentionally
except for buttons )
Change-Id: Ie68267809cee2e92bd06e88e698f17a10eeeb6ad
If that canvas contains a single shape, the result looks OK. If it
contains a groupshape, we also import something, but then the position /
size is still to be improved.
Change-Id: Ic4e4c08016a05a5e3acb005c3a642981ba4fb16d
The plan is that once these are here, the writerfilter ooxml tokenizer
can refer to them. And then the writerfilter will call back to oox to do
the real drawingml import.
Change-Id: Ibc0d9838f3db717004a3bc8b80a408a39c8f0886
The problem is that we wrote the size of the shape itself, while VML wants the
bounding box here. The WW8 export ignores the rectangle given in
EscherEx::Commit(), uses SdrObject::GetSnapRect() instead and later refines the
position by using the point got in WW8AttributeOutput::OutputFlyFrame_Impl(),
see PlcDrawObj::WritePlc().
Do the same in the VML export, i.e. ignore the Rectangle we get in
VMLExport::Commit() and use SdrObject::GetSnapRect() + the point given
in DocxAttributeOutput::OutputFlyFrame_Impl() instead.
Change-Id: I5adbdf205792c87f92c1ddf1cf674f87e11eb54e
* subversion/main/oox/source/drawingml/textparagraphpropertiescontext.cxx
[]WritingMode2 is used to numerous explicit writing directions, so use WritingMode2 to instead WritingMode.
Patch by: Ma Bingbing <jiazema@gmail.com>
Suggested by: Wang Zhe <kingwisemmx@gmai.com>
Found by: Wang Lifeng <phoenix.wanglf@gmail.com>
Review by: Wang Zhe <kingwisemmx@gmai.com>(cherry picked from commit 4545d293b1cf5009b075cdc82d43916909b77347)
Change-Id: Ic621ce6107bdc0b83c511f055175ae7b629f1503
mso-position-horizontal, mso-position-horizontal-relative,
mso-position-vertical and mso-position-vertical-relative
With this, the watermark in the bugdoc is almost in place, if you ignore
the missing rotation.
Change-Id: I8d3d834089e734654fcbbb0fb6166b4d7e01f80f
...which has become necessary since bd60d41176da540b01d7583cfe00637431967f39
"Handle oveflow in O(U)String::toInt() functions" reduces values in the range
(SAL_MAX_INT32 .. SAL_MAX_UINT32] to zero, but some calls of toInt32(16) relied
on getting a correct (unsigned) value for the whole input range ["0" ..
"FFFFFFFF"] (see libreoffice-4-1 commit 9bf6c83367cedb7be81bf67f30d2147d26c7a8c3
"Revert overflow checks in O[U]String::toInt{32,64} again").
Audited all uses of toInt32/64 with non-decimal radix. (There is still a TODO
comment in oox/source/helper/attributelist.cxx, and
stoc/source/typeconv/convert.cxx will still need some love and test code.)
Change-Id: Iadaca1c0e41dab553687d0ce41c20c10cd657a95
This reverts commit 5fe65c0c5e5a8d815d9d15ef192e7652726662e6.
Unfortunately this causes a regression elsewhere.
This also disables the unit test for this bug - will re-enable when I find
a fix that both fixes this, and does not regress other stuff :-)
Change-Id: Iad334e3c59c928edb78f25c0f36a33a26a7e6125
seems that writing property values that same as file defaults can cause
problems ( this behaviour doesn't seem to be consistent but... ) Fix
up some instances of properties that I've seen make Excel complain
Change-Id: Iacf6789906f07dc35aa5dbe3e7b62f4d2090e20a
some attributes should not be exported for some controls, their
very presence triggers the dreaded nag dialog ( promising doom
& death if you open the file )
Change-Id: I974ac94f75ee95ab54ca19bd5cd31952a66b20e5
new ole export used WriteOCXExcelKludgeStream but that function dissapeared when
msocximex was stripped of ocx control import ( now we use the new filters in oox )
When that stuff was moved WriteOCXExcelKludgeStream was #ifdef'ed out
Change-Id: I370983efa5e8c4ba2b210dfb7535ea211d13a8c1
just set the Anchor to Alignment_TOP_RIGHT
Found by: Shan Zhu
Patch by: zhaoshzh
Review by: zhangjf
(cherry picked from commit 8de6941efffd22214da577ff637b2522e46c7fa5)
Conflicts:
oox/inc/oox/drawingml/chart/converterbase.hxx
oox/source/drawingml/chart/titleconverter.cxx
Change-Id: Iad1fe1af8f93e6904759c10a9c9206fd1f1aebbb
A number of fixes needed here
a) make sure convert properties of control model is done before inserting
control model into formcontainer, need to do that to ensure that
GenerateVBAEvents is set ( so the fake VBA event generation can be
triggered )
b) remove the IsAlieanExcel check in servuno.cxx ( it's too strict and
additionally seems there is confusion over the media type to check )
c) split the vba import so that we can ensure the VBA mode is set (if
we have modules to import ) before sheets are imported and defer further
processing ( actual assigning of the modules and associated objects )
until later
Change-Id: I8fdbe788b400d7e41d4cc4b51b15f692bd7b0ecc
This reverts commit 02021163dbbcc8904da0b2138c8b53684dcc8ab4. The filter
appears to be split in two (com.sun.star.comp.oox.ppt.PowerPointImport
implementation oox::ppt::PowerPointImport from include/oox/ppt/pptimport.hxx for
im-/export, for export calling com.sun.star.comp.Impress.oox.PowerPointExport
implementation PowerPointExport from sd/source/filter/eppt/epptooxml.hxx) for no
good reason, so the com.sun.star.oox.PowerPointExport new-style service is
supporting a hack that should rather be cleaned up.
Conflicts:
offapi/UnoApi_offapi.mk
Change-Id: I875192a68a8e3458dbfd74b4981a6a2e86ce44d7
