bruce.dubbs at gmail.com
Thu Dec 7 19:58:30 PST 2006
Dan Nicholson wrote:
> On 12/7/06, Randy McMurchy <randy at linuxfromscratch.org> wrote:
>> There is a ticket in Trac for an issue with GSView-4.7.
>> 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:
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.
More information about the blfs-dev