On Wed, Aug 07, 2013 at 05:31:30PM +0300, Adam Fyne
wrote:
> We've managed to get to a state where the charts are now *imported* by
> Writer, but they are still not rendered \ exported correctly.
Hard to judge a patch without a reproducer document; do you have a
bugreport for this, where a test doc is attached? If all your problem is
that colors are missing, make sure either the chart uses direct colors
or oox also parsed the theme XML, writerfilter doesn't pass over that
information to oox.
> *We'd be happy to know if you think we are on the right track.*
[...]
> +case XML_chart:
> + mpShape.reset(new
> Shape("com.sun.star.drawing.GraphicObjectShape" ));
> + mxGraphicShapeContext.set
> + (new ChartGraphicDataContext(*rFragmentHandler,
> mpShape, true));
> +
> + break;
Not sure if com.sun.star.drawing.GraphicObjectShape is right here.
> +// As mentioned in above changes that ChartGraphicDataContext is
> created for chart element, now it is used to
> +// call addShape() funtion which calls the import for elements
> availble in chart.xml file. for details look at the
> +// "finalizeXShape()" function of 'oox/source/drawingml/shape.cxx'
> +// if you look at the code of
> 'core/oox/source/drawingml/chart/chartspacefragment.cxx' files
> ChartSpaceFragment::onCreateContext
> +// function it gets hit after our changes. 'c:chartSpace' is the
> root of chart.xml files.
Nitpick: I'm not sure it makes sense to mention filenames in such
comments, with id-utils/ctags they are redundant and nobody will update
these comments when the methods are moved to some other file.
> --- a/sw/source/ui/uno/unotxdoc.cxx
> +++ b/sw/source/ui/uno/unotxdoc.cxx
> @@ -1702,8 +1702,9 @@ Reference< XInterface >
> SwXTextDocument::createInstance(const OUString& rServic
> //! adding the shapes to the draw page).
> //! For inserting OLE objects the proper way is to use
> //! "com.sun.star.text.TextEmbeddedObject"!
> -if (rServiceName.lastIndexOf( ".OLE2Shape" ) =3D=3D
> rServiceName.getLength() - 10)
> -throw ServiceNotRegisteredException(); // declare
> service to be not registered with this factory
> + // following lines were resulting in crash after our changes
> for just commited them for now.
> +//if (rServiceName.lastIndexOf( ".OLE2Shape" ) =3D=3D
> rServiceName.getLength() - 10)
> +//throw ServiceNotRegisteredException(); // declare
> service to be not registered with this factory
>
> //
> // the XML import is allowed to create instances of
> com.sun.star.drawing.OLE2Shape.
Check how the ODF import filter imports a chart; if that manages to
import the chart without triggering this exception (and that's the
case), then the DOCX import filter should be able to do so as well, I
guess.
> diff --git a/writerfilter/source/ooxml/model.xml
> b/writerfilter/source/ooxml/model.xml
> index 64126ce..2b3aaa6 100644
> --- a/writerfilter/source/ooxml/model.xml
> +++ b/writerfilter/source/ooxml/model.xml
> @@ -27,6 +27,12 @@
> name=3D"http://schemas.openxmlformats.org/drawingml/2006/picture";
> alias=3D"picture" id=3D"dmlPicture"/>
> name=3D"http://schemas.openxmlformats.org/drawingml/2006/diagram";
> alias=3D"diagram" id=3D"dmlDiagram"/>
> name=3D"http://schemas.openxmlformats.org/drawingml/2006/lockedCanvas";
> alias=3D"lockedCanvas" id=3D"dmlLockedCanvas"/>
> +
> + name=3D"http://schemas.openxmlformats.org/drawingml/2006/chart";
> alias=3D"chart" id=3D"dmlChart"/>
Hmm, such general comment should go into the header of the file,
shouldn't it? And again, referencing the filename in the file itself
sounds a bit redundant.
The rest of the model.xml changes look OK, after all all you need is to
make the first XML tag picked up by writerfilter, oox will do the rest.
I think extensive comments where don't make too much sense, if you want,
I would rather suggest extending
writerfilter/documentation/ooxml/model.xml, as you already discovered
that file.
So, in short looks like you're on track. :-)
signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
