a2ps output incompatible with Adobe distiller
Hi, as described on http://article.gmane.org/gmane.comp.printing.a2ps.bugs/2583, there is a bug in a2ps that makes its postscript output incompatible with Adobe's distiller (and therefore OS X's Preview.app and its printing system). e.g. do: $ sudo port install a2ps $ echo "Test text" >> test.txt $ a2ps -o test.ps test.txt Then either open test.ps in Preview.app or run $ pstopdf test.ps Which results in the error: %%[ Error: undefined; OffendingCommand: iso1dict; ErrorInfo: CharOffsets %%[ Flushing: rest of job (to end-of-file) will be ignored ]%% %%[ Warning: PostScript error. No PDF file produced. ] %% pstopdf failed on file test.ps with error code -31000 Shorter, less useful errors with the same origin result if you open test.ps in Preview.app or send a2ps's output straight to printer (omit -o test.ps). That post includes a fix, which I've applied (post-installation) to my MacPorts a2ps installation and confirmed working. a2ps itself is currently without a maintainer, so it seems unlikely that the proposed fix (or any other) will be picked up for inclusion in the gnu tree any time soon. The a2ps port is also without a maintainer. Since this is a bug which makes a2ps of extremely limited use on OS X, is the fix worth including in MacPorts? I am completely new to MacPorts (migrated from Fink a week ago), so I am certain that someone more experienced could add this patch to the a2ps Portfile in five minutes. If no one has the time, I'd be happy to take a look at what's involved myself (pointers welcome). -- Mike
Michael Williams <williams@astro.ox.ac.uk> on Tuesday, February 27, 2007 at 4:20 AM -0800 wrote:
as described on http://article.gmane.org/gmane.comp.printing.a2ps.bugs/2583, there is a bug in a2ps that makes its postscript output incompatible with Adobe's distiller (and therefore OS X's Preview.app and its printing system).
e.g. do:
$ sudo port install a2ps $ echo "Test text" >> test.txt $ a2ps -o test.ps test.txt
Then either open test.ps in Preview.app or run
$ pstopdf test.ps
Which results in the error:
%%[ Error: undefined; OffendingCommand: iso1dict; ErrorInfo: CharOffsets %%[ Flushing: rest of job (to end-of-file) will be ignored ]%% %%[ Warning: PostScript error. No PDF file produced. ] %% pstopdf failed on file test.ps with error code -31000
Shorter, less useful errors with the same origin result if you open test.ps in Preview.app or send a2ps's output straight to printer (omit -o test.ps).
That post includes a fix, which I've applied (post-installation) to my MacPorts a2ps installation and confirmed working.
a2ps itself is currently without a maintainer, so it seems unlikely that the proposed fix (or any other) will be picked up for inclusion in the gnu tree any time soon.
The a2ps port is also without a maintainer. Since this is a bug which makes a2ps of extremely limited use on OS X, is the fix worth including in MacPorts? I am completely new to MacPorts (migrated from Fink a week ago), so I am certain that someone more experienced could add this patch to the a2ps Portfile in five minutes. If no one has the time, I'd be happy to take a look at what's involved myself (pointers welcome).
Michael, It would be great if you could create the patch and pick up maintainership. Making a patch is easy, Just download manaully the tarball the port uses, make a backup copy of the file to be changed, make the changes, and diff the old against the new. cd ap2s-x.xx cp file file.org edit file diff -u file.org file >patch-file Now you've got a patch. Now add the line: patchfiles patch-file to the portfile, and make your address the maintainer if you wish, and then do the same to the portfile. diff -u Portfile.org Portfile >Portfile.diff Now make a trac ticket and submit both patch files and that's it. If no one notices it you could ping the list. Mark
On Tue, Feb 27, 2007 at 07:15:41PM -0800, Mark Duling wrote:
It would be great if you could create the patch and pick up maintainership. Making a patch is easy, Just download manaully the tarball the port uses, make a backup copy of the file to be changed, make the changes, and diff the old against the new.
Thanks very much. I think I've done this OK. I elected to pick up maintainership, but I'm not sure how much use I'll be! One thing: I wasn't sure whether to create the diff in the subdirectory of the source tree in which the problem file resides, or the root of the source tree (plumbed for the former in the end). Also, if the fix is accepted, I assume the patch-file will reside somewhere on the MacPorts website, which is how a "port install a2ps" will find it. Before then, while I'm testing my own fixes, how do I persuade MacPorts to look for the patch on the local machine? Is there a convention for giving such patch-files a more descriptive name than just patch-file?
Now make a trac ticket and submit both patch files and that's it. If no one notices it you could ping the list.
ping! http://trac.macports.org/projects/macports/ticket/11455 Thanks for your help. Universal diffs and patching are one of those things I'd never gotten around to. You learn something new every day! -- Mike
On Feb 28, 2007, at 06:22, Michael Williams wrote:
One thing: I wasn't sure whether to create the diff in the subdirectory of the source tree in which the problem file resides, or the root of the source tree (plumbed for the former in the end).
Create the diff from the directory where the Portfile exists. The old documentation talks about this: http://darwinports.opendarwin.org/docs/ch15.html#id1033934 Hmm.. it doesn't explicitly state to do it from the Portfile directory. There must be another page where I read that before.
Also, if the fix is accepted, I assume the patch-file will reside somewhere on the MacPorts website, which is how a "port install a2ps" will find it. Before then, while I'm testing my own fixes, how do I persuade MacPorts to look for the patch on the local machine? Is there a convention for giving such patch-files a more descriptive name than just patch-file?
If you have a file foo.c that you're submitting a patch for, the recommendation is to name the patchfile "patch-foo.c.diff" as per the old documentation: http://darwinports.opendarwin.org/docs/ch04s07.html "The standard convention is to name the patch file 'patch- <filename>.diff, with one diff file per file altered in the source. If the filename is ambiguous because there are multiple files with that name in the distribution, supply the path components to uniquely identify the file being patched. Diffs should be created from the top level of worksrcdir, the working source directory where the port was extracted [...]" Ok, oh, so that's where it talked about how to create a diff from the root directory. I was misremembering it.
On Mar 2, 2007, at 18:59, Ryan Schmidt wrote:
On Feb 28, 2007, at 06:22, Michael Williams wrote:
Also, if the fix is accepted, I assume the patch-file will reside somewhere on the MacPorts website, which is how a "port install a2ps" will find it. Before then, while I'm testing my own fixes, how do I persuade MacPorts to look for the patch on the local machine? Is there a convention for giving such patch-files a more descriptive name than just patch-file?
If you have a file foo.c that you're submitting a patch for, the recommendation is to name the patchfile "patch-foo.c.diff" as per the old documentation:
http://darwinports.opendarwin.org/docs/ch04s07.html
"The standard convention is to name the patch file 'patch- <filename>.diff, with one diff file per file altered in the source. If the filename is ambiguous because there are multiple files with that name in the distribution, supply the path components to uniquely identify the file being patched. Diffs should be created from the top level of worksrcdir, the working source directory where the port was extracted [...]"
Sorry, I forgot to say: the patchfile itself gets stored in the MacPorts repository (it goes into the "files" directory at the same level as the Portfile), which gets automatically downloaded to all users' machines when they "port sync". No need for the patchfile to be on any web site. You can create the "files" directory in your local tree and put your patchfiles there while developing. Then just make sure you submit the patchfiles in addition to a diff to your Portfile when you finally submit your changes in a Trac ticket.
participants (3)
-
Mark Duling
-
Michael Williams
-
Ryan Schmidt