Bug#632031: convert: gray colorspace creates broken postscript

June 29th, 2011 - 05:00 am ET by Christoph Nodes | Report spam

Package: imagemagick
Version: 8:6.6.9.7-5
Severity: normal

the use of gray colorspace creates broken postscript code:

$ convert rose: -colorspace Gray ps:test.ps && gs test.ps
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusRomNo9L-Regu font from
/usr/share/fonts/type1/gsfonts/n021003l.pfb... 2532596 1218034 4015460 2730016
1 done.
Error: /typecheck in --idiv--
Operand stack:
grays 560.0 8
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval--
1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3
%oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval--
Dictionary stack:
Current allocation mode is local
Current file position is 5868
GPL Ghostscript 8.71: Unrecoverable error, exit code 1

Debian Release: wheezy/sid
APT prefers testing
APT policy: (550, 'testing'), (500, 'oldstable'), (500, 'stable'), (200, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.0.0-rc5-64+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages imagemagick depends on:
ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co
ii libc6 2.13-7bfw1 Embedded GNU C Library: Shared lib
ii libfontconfig1 2.8.0-2.2+b0 generic font configuration library
ii libfreetype6 2.4.4-1 FreeType 2 font engine, shared lib
ii libglib2.0-0 2.28.6-1 The GLib library of C routines
ii libgomp1 4.6.0-10bfw1 GCC OpenMP (GOMP) support library
ii libice6 2:1.0.7-2 X11 Inter-Client Exchange library
ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG
ii liblcms1 1.18.dfsg-1.2+b4 Color management library
ii liblqr-1-0 0.4.1-1 converts plain array images into m
ii libltdl7 2.4-2 A system independent dlopen wrappe
ii libmagickcore4 8:6.6.9.7-5 low-level image manipulation libra
ii libmagickwand4 8:6.6.9.7-5 image manipulation library
ii libsm6 2:1.2.0-2 X11 Session Management library
ii libtiff4 3.9.5-1 Tag Image File Format (TIFF) libra
ii libx11-6 2:1.4.3-2 X11 client-side library
ii libxext6 2:1.3.0-3 X11 miscellaneous extension librar
ii libxt6 1:1.1.1-2 X11 toolkit intrinsics library
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages imagemagick recommends:
ii ghostscript 8.71~dfsg2-9bfw1 The GPL Ghostscript PostScript/PDF
ii libmagickcore4-extra 8:6.6.9.7-5 low-level image manipulation libra
ii netpbm 2:10.0-12.2+b1 Graphics conversion tools between
ii ufraw-batch 0.18-1 batch importer for raw camera imag

Versions of packages imagemagick suggests:
pn autotrace <none> (no description available)
ii curl 7.21.6-2 Get a file from an HTTP, HTTPS or
ii enscript 1.6.5.2-1 converts text to Postscript, HTML
pn ffmpeg <none> (no description available)
ii gimp 2.6.11-3 The GNU Image Manipulation Program
ii gnuplot 4.4.0-1.1 A command-line driven interactive
pn grads <none> (no description available)
ii groff-base 1.21-6 GNU troff text-formatting system (
pn hp2xx <none> (no description available)
pn html2ps <none> (no description available)
pn imagemagick-doc <none> (no description available)
ii libwmf-bin 0.2.8.4-8 Windows metafile conversion tools
ii lprng [lpr] 3.8.B-1+b1 lpr/lpd printer spooling system
pn mplayer <none> (no description available)
pn povray <none> (no description available)
pn radiance <none> (no description available)
ii sane-utils 1.0.22-3 API library for scanners -- utilit
ii texlive-binaries [texlive-ba 2009-8 Binaries for TeX Live
ii transfig 1:3.2.5.d-1 Utilities for converting XFig figu
ii xdg-utils 1.1.0~rc1-2 desktop integration utilities from

To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Follow the discussion Replies

16 replies Replies

Make a reply

Replies

#6 Christoph Nodes

June 29th, 2011 - 11:00 am ET | Report spam

On Wed, 29 Jun 2011 15:37:08 +0200
Bastien ROUCARIES wrote:

Could you post also the printf patch and the rational for this patch ?

The reason for this patch is to deal better (for our concerns, i.e.
printing of amounts) with the rounded printing of non-representable
floating point numbers.

You would expect

$ printf '%.2f' 0.355

to print 0.36 but it does print 0.35. This is because 0.355 is not
representable as IEEE 754 floating point number and is rounded to the
next representable number (0.3549999...) before passing it as parameter
to printf.

The patch causes printf to take the next greater representable
floating point number of every passed floating point parameter and use
that for the output. This has proven to produce better results for us.

Best regards,
Christoph

diff --git a/stdio-common/printf_fp.c b/stdio-common/printf_fp.c
index 403636a..5a9d66d 100644
a/stdio-common/printf_fp.c
+++ b/stdio-common/printf_fp.c
@@ -466,6 +466,24 @@ ___printf_fp (FILE *fp,
return done;
}

+ /* Account for non-representable decimal numbers. "Critical" numbers
+ that are just below a non-representable decimal number will bei rounded
+ better. Most conversions will not change by adding a small amount to
+ the mantissa. */
+ if (fpnum.dbl != 0.0)
+ {
+ mp_limb_t cy = __mpn_add_1 (fp_input, fp_input, fracsize, 1);
+
+ if (to_shift == 1? cy:
+ fp_input[fracsize - 1]
+ & (((mp_limb_t) 1) << (1 + BITS_PER_MP_LIMB - to_shift)))
+ {
+ ++exponent;
+ (void) __mpn_rshift (fp_input, fp_input, fracsize, 1);
+ fp_input[fracsize - 1]
+ |= ((mp_limb_t) 1) << (BITS_PER_MP_LIMB - to_shift);
+ }
+ }

/* We need three multiprecision variables. Now that we have the exponent
of the number we can allocate the needed memory. It would be more

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Reply to this message

#7 Bastien ROUCARIES

June 29th, 2011 - 11:30 am ET | Report spam

On Wed, Jun 29, 2011 at 4:51 PM, Christoph Nodes wrote:

On Wed, 29 Jun 2011 15:37:08 +0200
Bastien ROUCARIES wrote:

Could you post also the printf patch and the rational for this patch ?

Do you know this bug?
http://sourceware.org/bugzilla/show_bug.cgi?idP44

You could get the correct version without using your hack by doing
fesetround(mode)
and after using directly printf

Ok so the imagemagick method ok getting integer will not work if you
use fesetround

Bastien

The reason for this patch is to deal better (for our concerns, i.e.
printing of amounts) with the rounded printing of non-representable
floating point numbers.

You would expect

$ printf '%.2f' 0.355

to print 0.36 but it does print 0.35. This is because 0.355 is not
representable as IEEE 754 floating point number and is rounded to the
next representable number (0.3549999...) before passing it as parameter
to printf.

The patch causes printf to take the next greater representable
floating point number of every passed floating point parameter and use
that for the output. This has proven to produce better results for us.

Best regards,
Christoph

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Reply to this message

#8 Christoph Nodes

June 30th, 2011 - 03:40 am ET | Report spam

On Wed, 29 Jun 2011 17:18:17 +0200
Bastien ROUCARIES wrote:

On Wed, Jun 29, 2011 at 4:51 PM, Christoph Nodes
wrote:
> On Wed, 29 Jun 2011 15:37:08 +0200
> Bastien ROUCARIES wrote:
>
>> Could you post also the printf patch and the rational for this
>> patch ?

Do you know this bug?
http://sourceware.org/bugzilla/show_bug.cgi?idP44

You could get the correct version without using your hack by doing
fesetround(mode)
and after using directly printf

Thanks for the hint, but fesetround affects the rounding of
the result of floating-point calculations not the rounding of printf.
We only want to affect the printing.

Best regards,
Christoph

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Reply to this message

#9 Bastien ROUCARIES

June 30th, 2011 - 05:30 am ET | Report spam

On Thu, Jun 30, 2011 at 9:36 AM, Christoph Nodes wrote:

On Wed, 29 Jun 2011 17:18:17 +0200
Bastien ROUCARIES wrote:

On Wed, Jun 29, 2011 at 4:51 PM, Christoph Nodes
wrote:
> On Wed, 29 Jun 2011 15:37:08 +0200
> Bastien ROUCARIES wrote:
>
>> Could you post also the printf patch and the rational for this
>> patch ?

Do you know this bug?
http://sourceware.org/bugzilla/show_bug.cgi?idP44

You could get the correct version without using your hack by doing
fesetround(mode)
and after using directly printf

Thanks for the hint, but fesetround affects the rounding of
the result of floating-point calculations not the rounding of printf.
We only want to affect the printing.

The patch affect it during printf also.

You could save round before printf, set rounding than restore it.

With your patch even exact double like 1.0e0 are rounded up !

Bastien

Best regards,
Christoph

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Reply to this message

#10 Bastien ROUCARIES

June 30th, 2011 - 05:40 am ET | Report spam

Could you send me the result of:
$ printf '%.20f' 1.0 with your patch ?

Bastien

On Thu, Jun 30, 2011 at 11:21 AM, Bastien ROUCARIES
wrote:

On Thu, Jun 30, 2011 at 9:36 AM, Christoph Nodes wrote:

On Wed, 29 Jun 2011 17:18:17 +0200
Bastien ROUCARIES wrote:

On Wed, Jun 29, 2011 at 4:51 PM, Christoph Nodes
wrote:
> On Wed, 29 Jun 2011 15:37:08 +0200
> Bastien ROUCARIES wrote:
>
>> Could you post also the printf patch and the rational for this
>> patch ?

Do you know this bug?
http://sourceware.org/bugzilla/show_bug.cgi?idP44

You could get the correct version without using your hack by doing
fesetround(mode)
and after using directly printf

Thanks for the hint, but fesetround affects the rounding of
the result of floating-point calculations not the rounding of printf.
We only want to affect the printing.

The patch affect it during printf also.

You could save round before printf, set rounding than restore it.

With your patch even exact double like 1.0e0 are rounded up !

Bastien

Best regards,
Christoph