Entries tagged [draw]

Thursday Jan 19, 2012

Native SVG support for Apache OpenOffice 3.4 (Incubating)

Apache OpenOffice 3.4 supports embedding SVG graphics using a newly created native SVG interpreter implementation. I want to talk about the advantages and some internals of this solution and the necessary changes done.

One reason to do this was IP clearance. It allowed removal of six GPL/LGPL libraries, namely librsvg, libcroco, libgsf, gdk-pixbuf, glib, and pango gettext. These were used as an external pixel-based renderer. The new SVG uses an own internal interpreter in a new library and some new UNO API services. IP clearance was no interesting task to do, but it leaded to effects like here with SVG; the install sets get smaller (less libraries to deliver), the app needs less libraries (startup, memory, runtime) and the internal handling of SVG vector data is completely vector-graphic oriented.

There were also ODF-compatible File Format adaptions needed, more concrete the in ODF already contained and described multi-image support. In ODF, the original SVG is now embedded to the 'Pictures' folder inside the ODF file as one would expect from such a feature and can be easily extracted (unzip the ODF file and there you are). There is also a Png file written 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 without breaking backward compatibility and/or ODF file exchange. 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 alpha over non-alpha and lossless 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).

SVG is no longer interpreted each time it needs to be rendered (unavoidable by an external renderer), but only once transformed to a sequence of primitives (UNO API graphic atoms). That sequence is then used for all outputs, transformed to the graphic object's form and viewport. 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. This is also true for saving, so always only one copy of your added SVG will be written (the same is true for the replacement Png image). Both, the sequence of primitives and the replacement image, are created using new UNO API services. One is capable of converting an io::XInputStream with SVG content 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 to be on the safe side). 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.

For all graphic processing the created vector graphic in form of a 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 uses the vector format. With an external renderer, it is unavoidable to use bitmaps with discrete solution in those cases, looking bad when zooming and needing more space in most cases as vector data. There is one caveat since not all program paths already use primitives; some will use the internal MetaFile format in-between (One more reason for more reworks to primitive usages in the future).

I implemented most SVG features from SVG 1.1, but not yet using animations or interactions (but possible in the future due to an own interpreter, impossible with an external SVG renderer). It supports all geometric SVG forms. It supports SVG gradients (using a new primitive for this which will be reused when we 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 or SVG (intern, extern, base64), SVG 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 primitive types (e.g. filtering) which would be useful for the future anyways. Especially interesting is the possibility to later add SVG animation import to GraphicObjects for Impress.

Some side effects: I had to fix cropping (unified with new primitive) which works now also for mirrored graphics (never 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 a normal GraphicObject; crop it, break it (to SdrObjects, currently 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...' from the context menu. You can add text, line style, fill style, pretty much the same as most other graphic objects. You can add shadow which casts shadow for the SVG graphic itself as expected (also not possible with an external renderer).

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. I already got some help from other community members and fixed some reported bugs (kudos to all testers and bug writers), but to find the rest, your help is appreciated. Please feel free to play around with any SVG you can find in current AOO 3.4 builds and report problems early in the Apache bugtracker!

Here is another blog entry about an early version of this feature.
And here are some developer snapshots of AOO 3.4 when you want to check it out. Be aware that these are AOO 3.4 Unofficial Developer Snapshots; these are intended to be used for early testing by other community volunteers. They have no release quality and should not be installed in a production environment. Developer snapshots can be unstable and are expected to have bugs.

Regards,
        Armin

Wednesday Jan 11, 2012

Features for GraphicObjects and OLEObjects

I just wanted to send some notes about added features which are part of AOO3.4 version. This one is actually the result of fixing tasks #118558#, #118485#, #108221# and #67705# which are all about GraphicObjects, OLEObjects (OLE means Object Linking and Embedding) and their geometrical attributes and properties. You may take a look at the tasks if you are interested in details, here I want to describe the benefits.

GraphicObjects are used when you insert a picture (pixel and vector data) or convert something to it. They already supported the full attribute set, so line style, fill style, text and shadow are possible. Geometrically, they could be transformed widely, but could not be sheared. Because now the content of GraphicObjects is displayed using primitives (and these are fully transformable) it is possible to also use shear and thus now completely support all geometrical transformations used in the office.

More interesting is that this is also true for OLEObjects, thus I added all these possibilities to OLEObjects of any kind, not only to our own internal OLEObjects (e.g. Chart, mathematical formula), but all possible external OLEObjects. These can now have line styles, fill styles, text and shadow and can be fully transformed. It is also possible to convert them to GraphicObjects which is the base for converting them to something else. Thus, you may now slant or distort OLEObjects, convert them to GraphicObjects, make geometrical modifications like merge/subtract/intersect with other objects or even convert them to 3D objects.

Some of the possible changes may lead too far for daily use, but some are pretty useful. It is now e.g. possible to add a mathematical formula and position it somewhere vertically by rotating it 90 degrees. It is possible to rotate chart OLEObjects themselves to get chart displays which the chart itself does not directly support. It is also useful to add a frame to a chart. With using the text offset it is also possible e.g. to add text to the OLEObject and move the text outside the object to get a caption. I leave more possibilities to your imagination...

Some examples:

example.jpg

(a) Math OLEObject rotated 90 degrees, blue filled and with border
(b) Chart OLEObject with gradient fill, border and object text as caption
(c) Same chart without fill, 90 degree rotation and shadow
(d) Chart bend in 2D, converted to GraphicObject (no longer an OLEObject)
(e) Chart OLEObject converted to 3D (only for demonstration, not too nice to view...)
(f) The math OLEObject, converted and bent, fill removed

I hope you got an impression; I'm not the designer guy, so excuse the examples.

Regards,
      Armin

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation