Re: Preview - more haggling

[Martin Sevior <msevior mccubbin ph unimelb edu au>]

HI folks,
	I completely agree with Lauris about using SVG as a meta-file
format and a preview format. Apart from the MAJOR speedup of not having to
invode gumeric or GUPPI or GtkMathView to render components other
considerations, this solution has the nice consequence that a gnome user
can embed a gnumeric spreadsheet into AbiWord and have it read by a
windows user running also AbiWord :-)

Of course this pre-supposes that AbiWord will one day get bonobo support.

Cheers

Martin


On Fri, 14 Dec 2001, Lauris Kaplinski wrote:

> Hello!
> 
> I'll jump in with some probably quite unrelated comments...
> If generic intra-file vector preview format will ever be considered, it 
> should be SVG ;)
> 
> On Tue, 2001-12-11 at 09:07, Michael Meeks wrote:
> >         Possibly we should have two aspect ratios, portrait and landscape
> > - just to make life difficult for you :-)
> 
> I would say whatever aspect ratio with full viewport attribute set ;)
> 
> >         As background - Windows saves a 'wfm' file - a Word Meta file,
> > essentialy an API dump of the rendering primatives. Thus if you have a
> > complex document - it can take forever to render, and is somewhat of a
> > pain.
> 
> This is the problem, that makes Nautilus (more) unusable for me (than
> for many others). It can be done - use out-of-process rendering lalala,
> but makes things much more complex.
> 
> >         _But_ - this does have some advantages - namely, that when the
> > document loads; it's not neccessary for eg. Word to fire up Excel - it can
> > just use the wmf stream to render it. This can equate to quite a large
> > saving I imagine.
> 
> It is.
> Plus some extra sugar - say, you have complex doc generated by someone,
> but do not have all components installed (in proprietary world you may
> have financial reasons for that). Having generic preview format in
> everywhere gives you at minimum knowledge about what is there, only
> activation (i.e. editing) is missing.
> Or, if document has some standardized viewport/pagination specification,
> you can embed it even without having component available - just like
> embedding (set of) image(s) - with the extra sugar, that someone having
> that comp. installed will be available to edit it.
> 
> >         So - yes a png is a very nice way to do the serialization - but
> > it's possible that we want to store a gnome print meta-file in there
> > instead :-) - either way - we would want to generate the image with
> > gnome-print almost certainly in the first place.
> 
> Gnome-print-metafile as it currently is, is more a joke. For external 
> image format I see 3 possibilities:
> a) Standardize gnome-print-metafile and make it extensible.
> b) Use SVG
> c) use PDF
> I'd prefer (b), as most document formats are xml-based anyways,
> and SVG fits nicely into those. Plus that makes documents viewable
> not only be some-yet-to-be-written gnome preview library/component,
> but (if done correctly) many more programs (imagine they being
> automatically previewable by web-browsers ;)
> SVG disadvantages are:
> a) No standard CMYK color system (but the same stands for current 
>    gnome-print as well
> b) Complexity (but it is still more logical and easier to parse than 
>    PDF)
> c) Ambiguity - but this can be reduced at least to PDF level by
>    careful image construction.
> 
> Best wishes,
> Lauris Kaplinski
> 
> 
> _______________________________________________
> gnome-components-list mailing list
> gnome-components-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-components-list
>