[gs-devel] Re: [till.kamppeter@gmx.net: Re: [Gimp-print-devel] GIMP-Print IJS driver and paper sizes]

Till Kamppeter till.kamppeter at gmx.net
Tue Aug 6 17:36:05 PDT 2002

Yes, specifying paper size and borders in points or even better 
micrometers seems to be the best solution for me, too.

But there is really something strange. The

    sprintf (buf, "%gx%g", ...)

which gives always a decimal point in GhostScript, gives a point or a 
comma, depending on the locale, in ijsgimpprint (when one does not force 
the locale to "C"). So can it be that in GhostScript or IJS the locale 
is forced to "C". When that would be the case, my patch would be 
correct. Or GhostScript/IJS is broken because they force the locale to "C".


Robert L Krawitz wrote:
> Till Kamppeter noticed that the PaperSize specification was being
> parsed incorrectly in the Gimp-Print IJS driver.  Upon further
> investigation, it turned out that this was due to his European locale,
> as described below.
> The code in Ghostscript that generates the paper size argument looks
> like this:
>     if (code == 0) {
> 	sprintf (buf, "%gx%g", ijsdev->MediaSize[0] * (1.0 / 72),
> 		 ijsdev->MediaSize[1] * (1.0 / 72));
> 	code = ijs_client_set_param(ijsdev->ctx, 0, "PaperSize",
> 				    buf, strlen(buf));
>     }
> Apparently this always uses `.' as the decimal point; the GNU man page
> says that the decimal point is locale dependent, but that isn't what's
> happening.  So it's unclear to me if this is a bug in the GNU libc or
> what.
> In any event, specifying the paper size this way seems error-prone to
> me, but perhaps we're doing something wrong?  I'd certainly prefer to
> receive these values as points rather than inches.
> ------- Start of forwarded message -------
> Date: Tue, 06 Aug 2002 19:27:28 +0200
> From: Till Kamppeter <till.kamppeter at gmx.net>
> To: Robert L Krawitz <rlk at alum.mit.edu>
> CC: gimp-print-devel at sourceforge.net
> Subject: Re: [Gimp-print-devel] GIMP-Print IJS driver and paper sizes
> The problem is in fact the locale, on the machine where it work fine US 
> english is set, on the machine where it is broken french is set. So I 
> edited the GhostScript command in the PPD file, adding "export 
> LC_ALL=C;" before the GhostScript command and it worked fine on both 
> machines. With "export LC_ALL=fr;" it broke on both machines. To avoid 
> having the ugly fix of adding "export LC_ALL=C;" to the GhostScript 
> command line of the Foomatic driver entry gimp-print.xml I have tried to 
> fix the C code of ijsgimpprint.c using "setlocale" to set the locale to "C".
> First I have put one
>     setlocale(LC_ALL, "C");
> in the beginning of the "main" function, which didn't lead to any 
> change, looking at the numbers put out when the "STP_DEBUG" variable is 
> set it is set back by some function in the libgimpprint.
> So I enclosed the contents of the functions "get_float" and 
> "gimp_parse_wxh" with
>     setlocale(LC_ALL, "C");
> and
>     setlocale(LC_ALL, "");
> also putting a
>     setlocale(LC_ALL, "");
> before the "return (0);" in "get_float". This gave me an output with 
> exactly 8x11 inches of size, still a little to small. Then I removed all
>     setlocale(LC_ALL, "");
> so that "get_float" and "gimp_parse_wxh" det the locale to "C" but do 
> not set it back. This did the trick, the output came out correctly, but 
> this is extremely ugly, because now we would make use of a side effect 
> of a function.
> Somewhere an additional fix is needed.
>     Till
> Robert L Krawitz wrote:
>>This is really strange.  It looks like something's going wrong with
>>the parsing:
>>gimp_set_cb: PaperSize=8.26389x11.6944
>>paper size 576,000000 792,000000 8.26389x11.6944
>>No matching paper size found
>>As it happens, 576 is exactly 8 * 72, while 792 is 11 * 72.  So it
>>looks like the parsing function in ijsgimpprint.c (gimp_parse_wxh) is
>>going wrong somehow, or the strtod is going wrong (that's my guess,
>>since it looks like it was able to find both the 8 and the 11).  You
>>might want to poke some debugging into that.  Perhaps this is an i18n
>>problem of some kind, and the decimal point (the standard American
>>usage, but not the European one) is causing it to do the wrong thing.
>>It would certainly explain why my testing revealed no problems, but
>>that you're having some problems.
>>   In a third test I took the original testprint.ps without inserted paper 
>>   size command again and replaced the "-dDEVICEWIDTHPOINTS=595 
>>   -dDEVICEHEIGHTPOINTS=842" in the GhostScript command line by a simple 
>>   "-sPAPERSIZE=a4" and got again the same result of a printout with a size 
>>   of exactly 7x10 inches. The logfile in the tarball is named 
>>   "logfile-sPAPERSIZEa4".
>>That's because it all goes through the same code path in IJS; IJS
>>creates the lxw string (yes, it creates a string!), which ijsgimpprint
>>   All log files say that the paper size is unknown.
>>That in itself isn't a problem (it's only a warning that's printed in
>>debug mode, and it won't cause any problem within Gimp-print, at least
>>with Epson printers, which don't have a fixed list of paper sizes).
>>The problem is why the 8.26389 isn't being parsed correctly in the
>>first place.  Perhaps we cannot rely on strtod.
> ------- End of forwarded message -------
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gimp-print-devel mailing list
> Gimp-print-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

More information about the gs-devel mailing list