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.
The Community Forum: New Year Status
After 4 years of existence, the Community Forum has moved on the Apache Software Foundation (ASF) servers at the end of October 2011 (see details).
Here are some figures about how we are doing on the English forum. We will try to make this kind of report on a monthly basis in the forum and perhaps quarterly on the blog.
Please remember that the forum is managed by a group of users helping other users for free and on their spare time.
- The number of posts, members and topics is taken from the phpBB information bottom of main index page
- Solved topics are counted in all the forums except admin and archives sections (not visible to standard users)
- Note that the ratio solved topics vs. total topics is slightly biased since the topics in the archives and admin sections are counted (in phpBB statistics) but not the solved ones (custom search). However, there are less than 550 topics there (in more than a 40,000 grand total, so less than 1.5%). These last figures shouldn't change very much since the private sections are not very active.
Here it is (since the solved topics is a new metric, there is only one point for the moment).
The blue line (number of posts) is not that important, it just shows that the trend is consistent with the other metrics. The most interesting statistics are the red lines for the members and the topics (with triangles, giving the time when the figures have been recorded). Note that the ratio topics vs. members is 0.9 for the English forum and above 1.5 for the French and Japanese forums. We tend not to be too harsh for the rules on the English section and topics are not often split when different users ask questions (still related of course) in the same thread.
Activity has a slightly higher slope during the first 2 years. It may be linked to the building of the knowledge database. Once the main issues and common questions have been discussed, users find their answers more and more easily with a mere search, hence less topics needed.
Neither the release of LibreOffice (Oct 2010), nor the move to the ASF servers (Oct 2011) have changed anything for the activity.
The decrease in the number of members (end of 2011) is linked to the cleaning of banned users. They had just been banned until now but to keep only the "real users", their account has been deleted (nearly 1800). This was the first cleaning ever done from the launch of this forum 4 years ago. 1550 of them had been identified as spammers because of their post(s). 250 were passive spam (link in signature or interest field of the profile, without any post).
The ratio of the solved topics is rather good: 14,000 solved (green triangle) in 41,000 (red triangles), that makes more than 1 in 3 (all users don't bother to tag their topic as solved).
For the record, last quarter has been in line with the rest: 2100 new users from Oct 1st to end of this year, meaning 1800 new topics.
As for the spam, we have had 1800 users in 1500 days, it makes 1.21 spammer a day, still rather low, thanks to the registration process (hard to cheat for bots).
Last figures: 2011 has shown an increase in the max number of online users along the months. Peak reached 232 beginning of October. The counter has been reset on Jan 1st 2012 and is already at 214, proving the audience is still there.
Some words about the team. Let's not forget Terry Ellison who was the main maintainer of the forum until the move to Apache Software Foundation servers. His huge involvement has made it possible for both a clean running of the forum during 4 years, making it a great place for those needing/providing help, and contributing to the transfer of the forum to the ASF servers with a minimal impact for the users.
On the behalf of the Forum Volunteers
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...
(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.
Posted at 03:42PM Jan 11, 2012 by alg in General | |