EMF File looks wrong

Bug Description

If I open an emf-File in inkscape 0.91 (32 bit) with german gui on a german Windows 7 64 bit with all patches applied the emf-Files textboxes are placed at the wrong position.

The preview of the file looks okay.

On OS X 10.7.5 with Inkscape 0.91 r13725:
- not reproduced with en_US locale
- reproduced when launching inkscape with a different locale (e.g. de_DE.UTF-8 or fr_FR.UTF-8)

Screenshot Inkscape 0.91 on OS X with locale fr_FR.UTF-8

@David - could you take a look at what seems to be a locale-related issue with text in the imported EMF file?

Also reproduced with Inkscape 0.91+devel r13937 on OS X 10.7.5 (import of text of the provided testcase (EMF file) depends on locale used by Inkscape: works as expected e.g. with en_US and en_GB, breaks with de_DE and de_FR)

Will try to get to it tomorrow. Hard to imagine why it did that since it looks like x,y offsets are all set to 0, and those are in numeric fields in the TEXT related EMF records -not the sort of thing one would expect to be affected by a locale change.

suv, how did you set the locale, was that within Inkscape itself or in the OS?

On 2015年02月25日 01:11 (+0100), David Mathog wrote:
> suv, how did you set the locale, was that within Inkscape itself or
> in the OS?

Via terminal, by launching inkscape like this:

$ LC_ALL=de_DE.UTF-8 inkscape 1425317-sample.emf
$ LC_ALL=fr_FR.UTF-8 inkscape 1425317-sample.emf
$ LC_ALL=en_GB.UTF-8 inkscape 1425317-sample.emf

The shell uses the default locale setting en_US.UTF-8 if not specified otherwise.

Ah, I see it. The problem is that when floats are written to strings to be passed as an SVG file into the main program this
happens, where the top one is de_DE and the lower en_US:

< transform="matrix(1,000000,-0,000000,0,000000,1,000000,68,699489,260,398065)"
---
> transform="matrix(1.000000,-0.000000,0.000000,1.000000,68.699489,260.398065)"

The matrix code handling code later in inkscape is pulling the 5th and 6th values out of that matrix, and they are both zero, so that explains what we are seeing.

Those sorts of conversions are all over the place, but only this one causes problems. Which suggests that pretty much everywhere else it accepts the comma separator form. It looks like all the conversions that do not cause problems occur as single values, like:

dx="0,0000"

it is only the transform matrix that cannot be parsed. Any other comma delimited float lists would do this too.

Which makes me wonder, is this a bug in the EMF handling or in the matrix handling? That would depend I guess about the SVG standard says about locales. Before I change anything let's let Tav weigh in.

Tav, please weigh in on how SVG is supposed to handle locales. Are comma delimited floats OK, or should any SVG be written always use decimal point delimiters? Thanks.

SVG syntax dictates the decimal point be written as '.'

See: http://www.w3.org/TR/SVG/types.html#BasicDataTypes

OK, thanks. Fix committed as revision 13947.

trunk r13947 backported in 0.91.x r13755