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

Robert L Krawitz rlk at alum.mit.edu
Tue Aug 6 17:18:51 PDT 2002


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
> misparses.
> 
>    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 -------



More information about the gs-devel mailing list