RE: [XaraXtreme-dev] Export preview & ImageMagick

["Charles Moir" <CharlesM@xxxxxxxx>]

Of course if we can't preview (i.e. because we can't load) then the user
can simply switch to preview window 2 preview, and select PNG, in order
to check that they are exporting the correct area etc. So this is in
effect doing option (b) but under user control.

So I agree we go for (c) and display 'no preview' in the window if they
select a type we can't import back to show the preview.

For now (0.7) we perhaps just get the main 'internal' types GIF, PNG and
JPEG working (which all do write the whole file and read it all in
again).

Charles



> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Neil Howe
> Sent: 20 July 2006 17:15
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Export preview & ImageMagick
> 
> > When using ImageMagick to export, there will be no way of doing an 
> > accurate preview without exporting the entire file and 
> reimporting it 
> > (i.e. writing the thing to disk). This could potentially be time 
> > consuming, and may not be possible (for instance some ImageMagick 
> > filters are write-only, and some we are only implementing in a 
> > write-only manner).
> > 
> > We thus have three options
> > a) Do not show export preview at all
> >     - Advantage: easy
> >     - Disadvantage: no preview
> > b) Show the intermediate PNG as the export preview
> >     - Advantage: you get to see the resolution, plus things like
> >                  transparency, correctly
> >                  should be easy to code (the same as the PNG
> >                  filter)
> >     - Disadvantage: it may be misleading, for instance if the
> >       filter converts the PNG to black and white, ignores the
> >       transparency, etc.
> > c) Attempt "best effort" to display an accurate preview, by
> >     saving the file out, and if the same filter also does
> >     reads, reading it in again; if not either use the PNG
> >     as a preview or disable preview totally.
> >     - Advantage: most accurate preview
> >     - Disadvantage: hardest & most time-consuming to code
> >                     highest potential of going wrong (especially
> >                     at an "interactive" stage)
> >                     may be slow in practice
> > 
> > Views?
> > 
> > I'm not planning on working on this till Luke's finished his stuff 
> > (i.e. post 0.7).
> 
> I don't like option b, so my view is that these types will 
> have to have no preview initially. So preview will only work 
> for the built in types (JPEG and PNG). For other types it 
> should show a message "No preview available" or similar, so 
> that it's clear that it's not meant to work yet for those types.
> 
> Then once Luke has preview working reliably for the built in 
> types, we can look at adding preview support for the 
> ImageMagick types (option c).
> And for the cases where preview can't be done because there 
> is no import capability, the same 'No preview available' 
> message is shown.
> 
> If we find that preview update is too slow, we'll have to add 
> an update button later when we implement option c, so that 
> the preview is only updated when the update button is pressed 
> instead of updating automatically as settings are changed. 
> But it's probably best to stick with automatic update 
> initially since that's how the Xtreme code that Luke is porting works.
> 
> Neil
>