Apache OpenOffice (incubating)
Native SVG support for Apache OpenOffice 3.4
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
Posted at 11:02AM Jan 19, 2012
by alg in General |
Comments[1]
|
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.
Some basics:
- 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.
Hagar Delest,
On the behalf of the Forum Volunteers
Posted at 12:00AM Jan 12, 2012
by robweir in Status |
Comments[2]
|
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:
(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
Posted at 03:42PM Jan 11, 2012
by alg in General |
|
