Dear Maintainer, /usr/share/ghostscript/9.05/lib/ps2epsi.ps contains '\r', which causes error in the outputs from /usr/bin/ps2epsi . The BoundingBox and HiResBoundingBox headers are corrupted. When I manually replaced '\r' with '\n', /usr/bin/ps2epsi started to produce correct BoundingBox and HiResBoundingBox headers (See Debian bug #681843). I'm attaching a patch, but I'm not familiar with patching and am not sure my patch file is usable as is. In any case, there are only two instances of '\r' . . . . Regards, Ryo ------------------- --- /usr/share/ghostscript/9.05/lib/ps2epsi.ps-2014-01-22 2014-01-22 13:03:18.000000000 -1000 +++ /usr/share/ghostscript/9.05/lib/ps2epsi.ps 2014-01-22 12:11:01.000000000 -1000 @@ -191,8 +191,8 @@ epsifile (\n) writestring epsifile flushfile - epsifile BBoxString writestring epsifile (\r) writestring - epsifile HiresBBoxString writestring epsifile (\r) writestring + epsifile BBoxString writestring epsifile (\n) writestring + epsifile HiresBBoxString writestring epsifile (\n) writestring % Define character and bit widths for the output line buffer: /cwidth rm lm sub 1 add def
That's arguably a bug in gv, I think. \r and \n are both white spaces and AFAIK treated as equivalent in most ps circumstances/usage. In fact I think postscript generated on Macintosh traditionally uses \r as line endings (as does "text files" on that platform) on every line. So gv possibly also have problems with any postscript files generated by say, an older copy of Photoshop running on a Macintosh.
Hi, Thanks for the response. > That's arguably a bug in gv, I think. \r and \n are both white spaces and AFAIK > treated as equivalent in most ps circumstances/usage. That's a good point. I'll pursue that line. Even then, there is no reason that mixing \r and \n in a single PostScript file is better than sticking to \n only. So, I hope the file (ps2epsi.ps) will be fixed, unless there is a reason not to do so. (You know, both \r and \n are currently used in ps2epsi.ps .) Regards, Ryo
I did a git blame and the \r were from Ken. So I'll let Ken explain why he did what he did... commit a4e46e1f7f9048e8cc465395ea4d83f73922ac60 Author: Ken Sharp <ken.sharp@artifex.com> Date: Tue Apr 7 10:20:02 2009 +0000 Fix (ps2epsi): rounding problems calculating bbox. Details: Bug #688500 "ps2epsi produces too-narrow bounding box (2)". OTOH, at least one viewer on linux - evince - displays the resulting epsi file with the intended boundingbox, so it is IMHO an issue of the viewer, not gs.
> the \r were from Ken. So I'll let Ken explain why he did what he did Sorry if I'm wrong, but I thought Ken would have achieves his goal either with \r or with \n. Currently, the "offending" part of ps2epsi.ps is epsifile BBoxString writestring epsifile (\r) writestring epsifile HiresBBoxString writestring epsifile (\r) writestring If these '\r' were replaced with '\n', would that cause some other problems? Note that all the other newlines in the file are '\n'. > an issue of the viewer, not gs I agree. But, I'm not convinced that \r in ps2epsi.ps should stay. If I'm wrong, what am I missing? Cheers, Ryo
(In reply to comment #4) > > the \r were from Ken. So I'll let Ken explain why he did what he did > > Sorry if I'm wrong, but I thought Ken would have achieves his goal either > with \r or with \n. In PostScript line endings are any of \r, \n, \r\n, so any combination is valid. > I agree. But, I'm not convinced that \r in ps2epsi.ps should stay. If I'm > wrong, what am I missing? Its perfectly valid, there is no problem here. If gv doesn't like \r then its gv that's incorrect.
I've made this change, but I believe this is a bug in the consuming application, you should probably report it there. commit e46be795d1a682259ebcca3df2ad581150414adf
(In reply to comment #6) > I've made this change, Thank you for your very quick response! That would solve the problem I've had for these several months. > but I believe this is a bug in the consuming > application, you should probably report it there. Thanks! I've actually done that. They say that although they don't know whether mixing newline characters in a single PostScript file is okay or not, they will fix gv. I guess this is a happy ending. Before signing off, I'd like to emphasize that I've come here NOT to argue that ghostscript is wrong. No! All I argue is that not mixing \r and \n is BETTER IN PRACTICE. Thank you again. Regards, Ryo