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 jogischmidt@googlemail.com
 designates 209.85.215.175 as permitted sender)
Message-ID: <4EEF8279.4020105@googlemail.com>
Date: Mon, 19 Dec 2011 19:29:13 +0100
From: =?ISO-8859-1?Q?J=FCrgen_Schmidt?= <jogischmidt@googlemail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Ip Clearance: 1st version of Svg replacement available
References: <jcnuhl$hjn$1@dough.gmane.org>
In-Reply-To: <jcnuhl$hjn$1@dough.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 12/19/11 7:07 PM, Armin Le Grand 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
>
> [2]
> https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement

big applause Armin because i know how concentrated you have worked on 
this. And it allows us to implement further improvements in this area in 
the future.

Especially how you have addressed the interoperability issue from the 
beginning shows how important this is for us and for the overall ODF story.

I bet that we will see this great improvement in LibreOffice 3.6 ;-) And 
yes it would be good because in the end ODF and our users would benefit 
from it.

Great work, well done

Juergen


>
> Sincerely,
> Armin
> --
> ALG
>