#635 gm convert failure from .pgm to .eps

[andrew mackay]

when certain subsets of data are zero in a .pgm file the convertion to .eps fails - giving a blank output. Example supplied with two plain .pgm files differing only by one data entry. One converts properly, the other does not.

[andrew mackay]

Hi,
thanks for the workaround which I'll use for current application,
regards,
Andrew

---

From: Bob Friesenhahn bfriesen@users.sourceforge.net
Sent: 01 October 2020 15:52
To: [graphicsmagick:bugs] 635@bugs.graphicsmagick.p.re.sourceforge.net
Subject: [graphicsmagick:bugs] #635 gm convert failure from .pgm to .eps

• assigned_to: Bob Friesenhahn
• Comment:

It seems that the problem is that the image associated with the broken output is determined internally to be bi-level yet it also has a 256 color colormap. The EPS encoder is mis-behaving in that case.

It is likely that the issue is actually in the ASCII PGM reader which may be producing a nonsensical internal representation which confuses the EPS encoder. If I do

gm convert structure_bitmap2.pgm -type truecolor -type bilevel crap.eps

then I get a valid EPS file.

---

[bugs:#635]https://sourceforge.net/p/graphicsmagick/bugs/635/ gm convert failure from .pgm to .eps

Status: open
Group: v1.0_(example)
Created: Thu Oct 01, 2020 05:00 AM UTC by andrew mackay
Last Updated: Thu Oct 01, 2020 05:00 AM UTC
Owner: Bob Friesenhahn
Attachments:

• bug_report_gm.tar.gzhttps://sourceforge.net/p/graphicsmagick/bugs/635/attachment/bug_report_gm.tar.gz (39.7 kB; application/x-gzip)

when certain subsets of data are zero in a .pgm file the convertion to .eps fails - giving a blank output. Example supplied with two plain .pgm files differing only by one data entry. One converts properly, the other does not.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/graphicsmagick/bugs/635/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Bob Friesenhahn]

It seems that the problem is that the image associated with the broken output is determined internally to be bi-level yet it also has a 256 color colormap. The EPS encoder is mis-behaving in that case.

It is likely that the issue is actually in the ASCII PGM reader which may be producing a nonsensical internal representation which confuses the EPS encoder. If I do

gm convert structure_bitmap2.pgm -type truecolor -type bilevel crap.eps

then I get a valid EPS file.

[Bob Friesenhahn]

It seems that the problem is that the image associated with the broken output is determined to be bi-level yet it also has a 256 color colormap. The EPS encoder is mis-behaving in that case.

[Bob Friesenhahn]

This problem is fixed by Mercurial changeset 16360:e34c82fe2b99. Thanks for reporting the bug!