[Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

[Thorsten Behrens]

Marco wrote:
> (2) I see that the Export Dialog has a "Selection" check box.
> I guess that its role is to let the user choose if he/she wants
> to export the whole presentation or only the selected slides.
> However I don't know yet, if/how the state of such check box is
> passed to the svg export filter, and in case it isn't, how to get
> that state.
> 
That should be the "SelectionOnly" property - e.g. look into
svtools/source/filter/SvFilterOptionsDialog.cxx - then again, that
so far has the rather different semantics of exporting the selection
_on a slide_.

> (3) The present svg export filter class is designed to export one
> or all slides. So adapting it to export a generic subset of slides
> will require a not so small effort as I thought (but surely doable :)).
> 
Cool! :)

> (4) In the present implementation I see that in the "single slide
> to export" case, once the slide/page to export has been retrieved,
> instead of taking a reference to that page as a data member, what is
> performed is to get the page number property, then to append it to
> the descriptor object as a "PagePos" property. This information is
> retrieved later by the implExport method and then forwarded to
> the other export methods as needed. What is the rationale for such
> a solution ? I am asking/pointing out that, because the selection
> object I get is of type Sequence< Reference < XInterface > >, but
> the actual type is Sequence< Reference < presentation::XDrawPage > >,
> so imo the simple solution would be to have a data member with such
> a type. Is this sensible ? Or, on the contrary, should I add an
> array data member containing the page numbers of all selected slides
> and then access a given slide through the rxDrawPages->getByIndex
> method ?
> 
I like your proposal better (i.e. holding a sequence of page refs).

> A side issue, while I was making some test I noticed that the
> following code produced some unexpected result:
> 
> OUString s1 = xObj1->getName();
> OUString s2 = xObj2->getName();
> 
> const char* ps1
> 	= OUStringToOString( s1, RTL_TEXTENCODING_UTF8 ).getStr();
> const char* ps2
> 	= OUStringToOString( s2, RTL_TEXTENCODING_UTF8 ).getStr();
> 
> OSL_TRACE( "s1= '%s'", ps1);
> OSL_TRACE( "s2= '%s'", ps2);
> 
> 
> From some code similar to the fragment above, and put inside
> a for loop, come out that the char const* pointer doesn't point
> to what it should. Is it normal that creating some new instance of
> a OUString invalidate the exported pointers to the internal
> data ? I am used to std container where an iterator is invalidated
> in some circumstances but only if you modify the container.
> 
Yes, this is to be expected - note that you create two temporaries,
via "OUStringToOString( sN, RTL_TEXTENCODING_UTF8 )", retrieve some
internal parts from it - and then those temporaries go out of scope
again.

Cheers,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110610/de0b0633/attachment.pgp>