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
pgpbaVwQeLojo.pgp
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
