+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 <[email protected]> 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/%[email protected]%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 > > > >
