Mailing-List: contact ooo-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-issues@incubator.apache.org
From: bugzilla@apache.org
To: ooo-issues@incubator.apache.org
Subject: [Bug 119735] SVG Export: missing implementation for
 com.sun.star.svg.SVGWriter when using GraphicProvider
Date: Fri, 08 Jun 2012 16:09:25 +0000
Message-ID: <bug-119735-248469-wH6hO0ezQa@https.issues.apache.org/ooo/>
In-Reply-To: <bug-119735-248469@https.issues.apache.org/ooo/>
References: <bug-119735-248469@https.issues.apache.org/ooo/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Auto-Submitted: auto-generated
MIME-Version: 1.0

https://issues.apache.org/ooo/show_bug.cgi?id=119735

--- Comment #5 from Armin Le Grand <Armin.Le.Grand@me.com> ---
ALG: Works as expected, should be used. Also needs not much memory since the
BitmapAction in the Metafile also uses the original, ref-counted bitmap.

When looking at the export another problem arises: In
SVGActionWriter::ImplWriteBmp nearly a minute is used (and assertions thrown as
crazy) in the following line:

::rtl::OUString aImageData( (sal_Char*) aOStm.GetData(), aOStm.Tell(),
RTL_TEXTENCODING_ASCII_US );

No wonder; the Bitmap, exported as PNG (in aOStm which is a SvMemoryStream) is
copied to a rtl::OUString (!) and encoded as RTL_TEXTENCODING_ASCII_US (!). Of
course a lot of non-ascii characters will be in an exported PNG.

That data is then used to create the Base64 encoded string data (of course
locally, how many Base64 encoders might we have?). This can of course be done
on the original memory stream data, avoiding this unicode conversion and the
needed memory. Testing this...

-- 
You are receiving this mail because:
You are the assignee for the bug.