Re: [Libreoffice] libvisio: how can I help?

On 09/01/12 11:12, Fridrich Strba wrote:
> Hello,
>
> On 09/01/12 11:24, Michael Meeks wrote:
> > >   I would like to start tackling some of them but as I'm not familiar
> > > with the code base, I would welcome suggestions as to which ones are
> > > likely to be reasonably easy hacks.
> >         I'm not an expert on this - so treat this with a pinch of salt, until
> > Fridrich arrives ;-) From what I recall, most of Fridrich's filters
> > essentially generate SAX style events and these are rendered onto the
> > libwpg::WPGPaintInterface 'painter' - which in turn generates ODF.
> >         So - to extend it; I'd save your broken document as flat ODF: a.fodg,
> > then tweak it to be the document it should be and re-save as b.fodg.
> > When you diff -u these two files you should see the elements and
> > attributes that have changed.
> >         Armed with that, I'd poke at the libvisio code and the
> > WPGPaintInterface to see how it converts that good stuff, and the
> > attributes / elements associated with that&  extend the code to handle
> > your cases.
> Reasonably accurate account, given that Michael is a real novice in this
> realm of spirit.
>
> But, let me give a quick overview of libvisio architecture:
>
> 1) Two main api fuctions principally in VisioDocument.h:
>         a) isSupported
>         b) parse
>     One convenience function in the same header:
>         c) generateSVG
>
> 2) VSDXParser class is the base class for reading the documents.
> VSD6Parser and VSD11Parser are derived classes that cater for
> differences between the two formats.
>
> 3) Document is read twice and the reader classes call functions of the
> VSDXCollector interface, first using the VSDXStylesCollector and second
> time using the VSDXContentCollector to receive the information.
>
> 4) VSDXContentCollector is processing information received from parser
> along with information collected by the VSDXStylesCollector and calling
> the callbacks from the libwpg::WPGPaintInterface.
>
> 5) Some complications given the need to first store some elements of a
> shape into memory and then output them using the information about in
> which order they should be painted.

Thanks for the explanations, that's really useful!

> Now, if you have cases of shapes that are not correctly converted, the
> best is to take the document, copy it and try to create a minumum
> document that still exhibits the problem. Then we can together
> introspect it and try to find the reasons of that misbehaviour. Like
> that I can help you to get into the logic of the file-format.

Thanks. Minimal examples will be useful anyway so I'll try to produce some.

> Any chance you can be on IRC during CET day?

I wish but no. The job that pays the bills keeps me busy during the day, 
UK time, and doesn't let me use any software that's not part of the 
organisation's standard build.

I'll try to find my way and will drop you a note if I struggle. Worst 
case scenario, I hope I'll see you at FOSDEM in a few weeks so I may 
take the opportunity to ask a few questions then.

Bruno