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
Attachment:
pgpTPWrkZph4s.pgp
Description: PGP signature