incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Harbison <>
Subject Re: Ip Clearance: 1st version of Svg replacement available
Date Tue, 20 Dec 2011 01:19:53 GMT
Well done! Thank Armin, this is really great stuff.

On Mon, Dec 19, 2011 at 1: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$**<$fep$>
> [2]**asf/incubator/ooo/branches/**
> alg/svgreplacement<>
> Sincerely,
>        Armin
> --

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message