Well done! Thank Armin, this is really great stuff. On Mon, Dec 19, 2011 at 1:07 PM, Armin Le Grand <armin.le.gr...@me.com>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<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<https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement> > > Sincerely, > Armin > -- > ALG > >
