i18n problem with gimp vs plugin communication over the wire

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hola.

I've spent a few hours trying to track down why I get got opacity 0.8 in
when I'm loading some images (like postscript and gif).
Actually, it should be 1.00 after this bug, but double-conversion
to/from 100 vs 256-based system rounds down to 0.8..

Anyhow.

The problem is when writing the double over the wire.
wire_write_double() sprintf's "%0.50e" to a buffer and sends it away
from the plugin.. Then gimp stands on the other side armed with a
sscanf(.."%le"..)..

The problem is.. sprintf is locale-enabled, and sprintf/sscanf doesn't
seem to both be running the same locale when talking plugin/gimp,
because sscanf interprets "1,000{lotsazeroes}000e+02" as "1" (nice
rounding ;P)

If I disable i18n stuff in the gif-plugin for instance, it starts
working.
Maybe it's best to set to C locale temporarily when sending/reading
stuff over the wire, instead of relying on that _all_ plugins are
i18n'd.

Anyone more familiar with the code that can attack this? (need to change
at least LC_NUMERIC (maybe LC_ALL) to C before doing wire stuff I guess)

How to reproduce: set LANG or LC_CTYPE to sv_SE, start gimp and load a
gif.. then check the opacity in the L&C&P dialog... (hotkey ^L if you
don't understand swedish 8)

/Tomas - tired! Zzz..
-- 
Tomas Ögren, stric@xxxxxxxxxx, http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux