Dan Nicholson wrote: > On 12/7/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: >> >> There is a ticket in Trac for an issue with GSView-4.7. >> http://wiki.linuxfromscratch.org/blfs/ticket/2175 >> >> The issue is valid. The new EPS Ghostscript internal versioning >> scheme breaks GSView. I found that simply modifying src/gvcver.h >> in the GSView sources fixes the issue. I simply substituted >> 81502 for 999 for the "max version number" and compiled, and all >> worked fine. > > Nice job, Randy. That fix seems fine to me, but I don't use gsview. > It'd be nice if we could get the reporter to test it, but it may be > too far out. Hopefully, he'll see the comments in the ticket and try > it out. > > Possibly for future-proofing, the "max version number" should be > increased? It would kind of stink to have to change the gsview page > each time a new ESP ghostscript version was released. Or, we could > change the sed to grab the version number from the gs header. I'm > having trouble getting onto my system through ssh right now, so I > can't see what the headers look like.
I took a look at the code and GS_REVISION_MAX is used in two places: src/gvcmisc.c src/cdll.c I'd just suggest using a value of 99999 for GS_REVISION_MAX. I remember why I don't use gsview much. It does not show the table of contents that are in many pdf files. I do need it for ps files though. Side comment: It appears that the author of this package is really a windows programmer. The paradigms/terminology seem to be primarily windows and they have not incorporated the patch David Jensen made a year and a half ago. I wouldn't be too concerned about making patches or seds to this package. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
