(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


_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to