Bug 498590 - Badly rendered svg
Badly rendered svg
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
: FutureFeature
Depends On: 478541
  Show dependency treegraph
Reported: 2009-05-01 07:00 EDT by Caolan McNamara
Modified: 2018-04-11 13:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 478541
Last Closed: 2009-06-17 16:02:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Sample with a tiger (312.75 KB, image/png)
2009-05-08 09:26 EDT, Simon
no flags Details

  None (edit)
Description Caolan McNamara 2009-05-01 07:00:40 EDT
+++ This bug was initially created as a clone of Bug #478541 +++

Description of problem:
the openclipart package is svg only, but open office is not able to open svg’s for import them in a writer document to garnish an invitation of a sylvester party.

Version-Release number of selected component (if applicable):
Fedora 10
openclipart 0.18
openoffice.org-writer 3.0.0

How reproducible:

Steps to Reproduce:
1. Install openclipart
2. Install openoffice.org-writer
3. try to insert a clipart into a writer document via "insert -> picture -> from file"
Actual results:
it's not possible

Expected results:
it should be possible

--- Additional comment from redhat-bugzilla@linuxnetz.de on 2009-01-09 10:38:12 EDT ---

Caolan, what's the problem with "%configure --with-system-libsvg"? Okay, we
maybe need to BuildRequire libsvg2 or whatever it is. Without any explanation
this is NEVER closed upstream. Simon, please re-open the bug report again.

--- Additional comment from caolanm@redhat.com on 2009-01-09 10:50:15 EDT ---

"what's the problem with "%configure --with-system-libsvg"

there isn't any such option in vanilla

--- Additional comment from cassmodiah@fedoraproject.org on 2009-01-09 11:05:19 EDT ---

This was my mistake.

I thought this is the solution, BUT I didn't realize that the parameter --with-system-libsvg is not for the SUN openoffice, but it is for the Novell openoffice called goo. To my surprise in other distros packages it is called openoffice.org-*, too. Sven Lankes told me that, to 

so the problem is, that sun's ooo is not able to handle svg. and i don't know if the problem will be solved in next versions.

perhaps one of this three solutions would solve this problem.

1.) generate a openclipart-png package
2.) enable svg support with an openoffice extension like this: http://extensions.services.openoffice.org/project/SVGTiny2OO
3.) switch to go-oo (Novels ooo fork)

--- Additional comment from redhat-bugzilla@linuxnetz.de on 2009-01-09 11:14:34 EDT ---

Novell OpenOffice.org fork? Hopefully they maintain and drive more QA to that 
office fork than to their SLE products...otherwise I'm not amused about go-oo.

--- Additional comment from cassmodiah@fedoraproject.org on 2009-03-17 09:14:23 EDT ---

I had a talk with an ooo dev at the ooo booth on Chemnitzer Linux Days

Caolan, would you please pack this
and activate it by default? (if possible, sorry but i don't know it, i'm just a packager in training!)

This would solve this problem and would be very cool :-)

--- Additional comment from caolanm@redhat.com on 2009-03-17 11:07:26 EDT ---

Let's have another look at this, I'm not delighted by the extension as we'd have to build it from source and its got a fairly big java dependency chain.

Maybe its worth selectively importing in the ooo-build svg importer

--- Additional comment from caolanm@redhat.com on 2009-03-18 08:42:06 EDT ---

Lets try that first, will be in >= 3.1.0-6.2.f11

--- Additional comment from cassmodiah@fedoraproject.org on 2009-04-01 16:03:49 EDT ---

Created an attachment (id=337642)
ooo + svg

--- Additional comment from cassmodiah@fedoraproject.org on 2009-04-01 16:06:23 EDT ---

the svg's are broken after import, please take a look at the attachment 337642 [details]

$ rpm -q openoffice.org-writer

--- Additional comment from caolanm@redhat.com on 2009-04-01 17:50:13 EDT ---

That's then "doesn't import some svg's correctly" as opposed to "cannot import svgs", hopefully an improvement of sorts
Comment 1 Caolan McNamara 2009-05-01 07:01:34 EDT
This bug is for getting the specific attached .svg rendered correctly
Comment 2 Caolan McNamara 2009-05-06 09:53:11 EDT
Rats :-(, was about to look at this, but need the sample .svg itself to make progress
Comment 3 Simon 2009-05-08 09:26:52 EDT
Created attachment 343077 [details]
Sample with a tiger

The tiger from the go-oo site. 

The svg of the IT-AmtBw logo (the svg of the old bug entry) is from Felix Kaechele. I contacted him to make us the svg available.

I found a IT-AmtBw logo in wikipedia. 
I don't know if this file is the same as the one of Felix Kaechele.
Comment 4 Matěj Cepl 2009-05-12 16:57:07 EDT
This is nice discussion what you have here (and I am curious about the result because close character of OODraw is one of my biggest pet peeves), but this is certainly not a NEW bug.

Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.
Comment 5 Caolan McNamara 2009-05-12 17:47:44 EDT
"close character" ?

Tiger renders fine for me, though the whiskers look different that's not a svg import issue, but a generic sub-one-pixel line drawing artefact. The other one I haven't had a chance to look at yet to see if there's anything that needs fixing, hence NEW
Comment 6 Simon 2009-05-13 07:30:12 EDT
my matter was to import the openclipart svgs in ooo.
I tested some svgs of the clipart-package and it works.

the itamtbw logo seems to be broken, it doesn't work with all applications.

i tested only writer! because i don't use other ooo-applications.
Comment 7 Caolan McNamara 2009-06-09 12:36:56 EDT
The second one has a toplevel relative size, so importer needs fixing for that.

Otherwise it looks good, *if* imported into e.g. impress and go full-screen which is where the modern renderer can work on it, using the legacy renderer then there can be artefacts. Clearly we need to push moving to that new framework and ditch the old one as soon as we can.
Comment 9 Caolan McNamara 2009-06-17 16:02:58 EDT
Fixed the busted handling of 100% width/height for top level containers

Note You need to log in before you can comment on or make changes to this bug.