Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gcaiod-ooo-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: ooo-dev@incubator.apache.org
From: Armin Le Grand <Armin.Le.Grand@me.com>
Subject: Ip Clearance: 1st version of Svg replacement available
Date: Mon, 19 Dec 2011 19:07:48 +0100
Lines: 99
Message-ID: <jcnuhl$hjn$1@dough.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:8.0) Gecko/20111105 Thunderbird/8.0

	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
[2] 
https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement

Sincerely,
	Armin
--
ALG