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

On Fri, 10 Jun 2011 14:22:16 +0200, Thorsten Behrens  
<thb@documentfoundation.org> wrote:

> 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_.

Ah so my guess was wrong. Anyhow I think that for a presentation the
usual semantic is not so useful.
In any case I want to point out that when the export of a subset of
slides will work for the Left Impress Pane too, there will not be
anymore the possibility to utilize the "empty selection" case to
export all slides because at least one slide will be always selected
in the Left Impress Pane (that is the one showed).
Obviously we can always select all slides.


skip


> > 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.

Ah you are right! My fault!

Cheers,
   Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/