Bug 498590

Summary: Badly rendered svg
Product: [Fedora] Fedora Reporter: Caolan McNamara <caolanm>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: caolanm, cassmodiah, lkundrak, mcepl, mcepl, redhat-bugzilla
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 478541 Environment:
Last Closed: 2009-06-17 20:02:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 478541    
Bug Blocks:    
Attachments:
Description Flags
Sample with a tiger none

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