incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: Ip Clearance: 1st version of Svg replacement available
Date Mon, 19 Dec 2011 19:22:17 GMT
+1

Big kudos to Armin ...

I hadn't said it before so let me say this is really,
REALLY cool!!

Pedro.

--- Lun 19/12/11, J├╝rgen Schmidt <jogischmidt@googlemail.com> ha scritto:
...
> On 12/19/11 7:07 PM, Armin Le Grand
> wrote:
> > Hi *,
> >
> > as mentioned in [1] I have now finished and
> reintegrated the first
> > version of the Svg replacement from the branch [2] to
> trunk after
> > uptating and building Mac and Win versions. It is
> stable and works well
> > and is also pretty complete from an Svg point of view.
> Main
> > features/differences to the version which was in
> OOo3.4beta are:
> >
> > - IP clearance: This change allowed to remove six
> Gpl/Lgpl libs, namely
> > librsvg, libcroco, libgsf, gdk-pixbuf, glib, and pango
> gettext. These
> > were used as an external renderer. The new Svg uses an
> internal
> > interpreter in a new library and some services.
> >
> > - File Format: In Odf, Svg is now embedded to the
> Pictures folder as one
> > would expect and can be easily extracted. There is
> also a Png file
> > written there as replacement image. The draw:frame is
> now multi-image
> > capable (as the spec allows). In the case of a Svg it
> writes a good
> > quality Png and the original Svg as draw:image
> elements. Since older
> > (and other) office versions are only capable of
> loading a single (and
> > thus the first) image, the Png is written first. This
> allows file
> > exchange with other and older offices. At load time,
> multi-image support
> > will choose the best quality graphic available for
> further work, e.g.
> > preferring vector format over pixel format, pixel
> format with
> > transparency over non-transparent and loss less
> formats over those with
> > losing info (you get the idea). Other Odf
> implementations (e.g. a
> > viewer) may just use the pixel graphic available.
> Multi-image support is
> > independent from Svg in principle and will work with
> all image file
> > formats. This is implemented for the Drawinglayer
> graphic object (used
> > in Draw/Impress/Calc) and the Writer graphic object
> (used in Writer).
> >
> > - Interpretation: Svg is no longer interpreted each
> time it needs to be
> > rendered (as by an extrenal renderer), but only once
> transformed to a
> > sequence of primitives. That sequence is then used for
> all outputs,
> > transformed to the graphic object form and viewport
> (resolution). The
> > sequence itself is completely view-independent.
> Internally, it is reused
> > and thus it makes no difference if you have your Svg
> graphic added once
> > or multiple times to your document. The same is true
> for the replacement
> > Png image used. Both, the sequence of primitives and
> the replacement
> > image are created using new Uno Api services. One is
> capable of
> > converting an io::XInputStream to a sequence of
> primitives, the other is
> > able to convert every sequence of primitives to a
> rendering::XBitmap
> > with given Dpi and discrete sizes (pixels, with
> automatic resolution
> > reduction to a given maximum square pixel count). This
> will be useful
> > for other purposes, too, since it creates a fully
> alpha-capable
> > representation of anything in primitive format to use
> as e.g. sprite.
> >
> > - Quality: For all graphic processing the created
> vector graphic in form
> > of sequence of primitives is used. This means that You
> will get best
> > quality in all zoom situations and all resolutions.
> This is also true
> > for all exports, e.g. printing or Pdf export which
> also use the vector
> > format. With an external renderer, it is unavoidable
> to use bitmaps with
> > discrete solution here, not only looking bad in high
> resolutions, but
> > also needing more space in most cases. There is one
> caveat since not all
> > paths here already use primitives; some will use the
> internal MetaFile
> > format in-between (One more reason for more reworks to
> primitive usages
> > in the future).
> >
> > - Completeness: I implemented most Svg features from
> Svg1.1, but not yet
> > using animations or interactions (but possible in the
> future due to an
> > own interpreter, impossible with an extern Svg
> renderer). It supports
> > all geometric Svg forms. It supports Gradients (using
> a new primitive
> > for this which can be reused when we want to add Svg
> gradients to
> > SdrObjects one day), these have a resolution-dependent
> low-level format
> > to not waste runtime on low resolutions. It supports
> Masks, clipPath,
> > Markers, linked content, embedded graphics and Svg
> (intern, extern,
> > base64), Use nodes, Text, Text on curve and patterns.
> It does not yet
> > support filters, color profiles, embedded scripts,
> interactions and
> > linking. These can be added when needed, most of them
> will need to
> > implement new basic primitives (e.g. filtering) which
> would be useful
> > anyways.
> >
> > - Side effects: I had to fix cropping (unified with
> new primitive) which
> > works now also for mirrored graphics (vecer worked)
> and quite some other
> > stuff. We are prepared for Svg gradients as possible
> future feature (we
> > can already render them now). You can work with an
> added Svg as with an
> > graphic object; crop it, Break it (To SdrObjects,
> limited to the
> > transfer over the old MetaFile format, though). You
> can convert an
> > inserted Tux to 3D, You can bend the Svg in vector
> quality in Draw. It
> > is possible to directly export the original Svg again
> by selecting the
> > object and using 'Save as Picture...'. You can add
> Text, Border, fill
> > style, pretty much the same as most other graphic
> objects. You can add
> > shadow which casts shadow as expected (also never
> possible with an
> > external renderer).
> >
> > - Caveats: This is a bigger change, but most stuff is
> isolated in the
> > two mentioned services. There will be errors (I'm too
> long a programmer
> > to deny that :-)), but I tried to be as careful as
> possible. To find
> > them, Your help will be needed. Please feel free to
> play around with any
> > Svg You can find and report problems early.
> >
> > [1]
> > http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201112.mbox/%3Cjcamku$fep$1@dough.gmane.org%3E
> >
> > [2]
> > https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement
> 
> big applause Armin because i know how concentrated you have
> worked on 
> this. And it allows us to implement further improvements in
> this area in 
> the future.
> 
> Especially how you have addressed the interoperability
> issue from the 
> beginning shows how important this is for us and for the
> overall ODF story.
> 
> I bet that we will see this great improvement in
> LibreOffice 3.6 ;-) And 
> yes it would be good because in the end ODF and our users
> would benefit 
> from it.
> 
> Great work, well done
> 
> Juergen
> 
> 
> >
> > Sincerely,
> > Armin
> > --
> > ALG
> >
> 
> 

Mime
View raw message