Bug 498590 - Badly rendered svg
Summary: Badly rendered svg
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 478541
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-01 11:00 UTC by Caolan McNamara
Modified: 2018-04-11 17:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 478541
Environment:
Last Closed: 2009-06-17 20:02:58 UTC
Type: ---
Embargoed:


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

Description Caolan McNamara 2009-05-01 11:00:40 UTC
+++ 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:
always

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 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 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 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 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 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
http://extensions.services.openoffice.org/project/svgimport
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 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 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 on 2009-04-01 16:03:49 EDT ---

Created an attachment (id=337642)
ooo + svg

--- Additional comment from cassmodiah 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
openoffice.org-writer-3.1.0-8.1.fc11.x86_64

--- Additional comment from caolanm 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 11:01:34 UTC
This bug is for getting the specific attached .svg rendered correctly

Comment 2 Caolan McNamara 2009-05-06 13:53:11 UTC
Rats :-(, was about to look at this, but need the sample .svg itself to make progress

Comment 3 Simon 2009-05-08 13:26:52 UTC
Created attachment 343077 [details]
Sample with a tiger

The tiger from the go-oo site. 
http://go-oo.org/discover/tiger.svg

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. 
http://upload.wikimedia.org/wikipedia/commons/1/13/IT-AmtBw_Wappen.svg
I don't know if this file is the same as the one of Felix Kaechele.

Comment 4 Matěj Cepl 2009-05-12 20:57:07 UTC
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 21:47:44 UTC
"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 11:30:12 UTC
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 16:36:56 UTC
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 20:02:58 UTC
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.