(gimpwin-users readers can largely ignore this message... just keeping this thread there, too, as it started there) Manish Singh writes: > It looks to be trio's fault, there is a bug similar to this opened already: > > http://bugzilla.gnome.org/show_bug.cgi?id=101874 > > Perhaps special case this on windows to use the native snprintf (I assume it > exists there). This isn't an issue in GIMP 1.3, since we don't transmit > doubles as text over the wire anymore. Perhaps the simplest solution for GIMP 1.2 would be to change wire_write_double(): diff -u -2 -r1.14 gimpwire.c --- gimpwire.c 30 May 2000 23:38:46 -0000 1.14 +++ gimpwire.c 16 Feb 2003 01:20:28 -0000 @@ -437,5 +437,5 @@ for (i = 0; i < count; i++) { - g_snprintf (buf, sizeof (buf), "%0.50e", data[i]); + g_snprintf (buf, sizeof (buf), "%0.*e", DBL_DIG, data[i]); if (!wire_write_string (channel, &t, 1)) return FALSE; I.e. don't use more digits than necessary, especially as some printf implementations (like Trio) might misbehave. (When asked for precision DBL_DIG, Trio does print 14 as "1.400000000000000e+01".) This might also improve speed a bit on all platforms, no need for the printf implementation to generate 50 digits... BTW, what has been the rationale behind using floating-point for pixel coordinates in the PDB in the first place, for instance for gimp_rect_select? --tml
