ghostscript - OS2

This is a discussion on ghostscript - OS2 ; Paul Smedley wrote: > > Please try http://download.smedley.info/gs861os2.zip > now I am getting a number of errors in unzip. Here is the relevant part of the output of unzip -t gs861os2.zip: ...... testing: gs8.61/bin/gsdj500 OK gs8.61/bin/gsdll2.def: mismatching "local" filename (gs8.61/bin/gsdll2.dll), ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: ghostscript

  1. Re: ghostscript

    Paul Smedley wrote:
    >
    > Please try http://download.smedley.info/gs861os2.zip
    >


    now I am getting a number of errors in unzip.

    Here is the relevant part of the output of unzip -t gs861os2.zip:

    ......

    testing: gs8.61/bin/gsdj500 OK
    gs8.61/bin/gsdll2.def: mismatching "local" filename
    (gs8.61/bin/gsdll2.dll),
    continuing with "central" filename version
    testing: gs8.61/bin/gsdll2.def OK
    file #110: bad zipfile offset (local header sig): 3752566
    file #111: bad zipfile offset (local header sig): 5219097
    file #111: bad zipfile offset (local header sig): 5219097
    file #112: bad zipfile offset (local header sig): 5219539
    etc...


    Piersante

  2. Re: ghostscript

    Aha!

    Paul Smedley wrote:

    > Hi Mike,


    > Try copying the libcups.dll from D:\GS\gs8.61\bin to somewhere in the
    > libpath....
    >


    Copied it into the C:\OS2\DLL directory which is my boot drive. That works.
    Which seems to mean for some reason, as released, even though the special setup
    instructions or the install was properly followed, the application still cannot
    see the proper path for the .DLL somehow.

    Hmmmmm

    Note that I'm not running this in the C:\ boot drive here. I've got the
    application installed on the D:\ drive. I really don't want this on the boot
    drive as I try to maintain application operations off the boot drive for what
    seems realistic for stability reasons.


    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  3. Re: ghostscript

    Hi Mike,

    On Sat, 29 Dec 2007 14:20:06 UTC, Mike Luther
    wrote:

    > Aha!
    >
    > Paul Smedley wrote:
    >
    > > Hi Mike,

    >
    > > Try copying the libcups.dll from D:\GS\gs8.61\bin to somewhere in the
    > > libpath....
    > >

    >
    > Copied it into the C:\OS2\DLL directory which is my boot drive. That works.
    > Which seems to mean for some reason, as released, even though the special setup
    > instructions or the install was properly followed, the application still cannot
    > see the proper path for the .DLL somehow.
    >
    > Hmmmmm
    >
    > Note that I'm not running this in the C:\ boot drive here. I've got the
    > application installed on the D:\ drive. I really don't want this on the boot
    > drive as I try to maintain application operations off the boot drive for what
    > seems realistic for stability reasons.


    I refreshed http://download.smedley.info/gs861os2.zip to remove the
    dependency on libcups.dll

    --
    Cheers,

    Paul.

  4. Re: ghostscript

    Wish I could bring good news, but no ..

    Paul Smedley wrote:

    > Hi Mike,


    > I refreshed http://download.smedley.info/gs861os2.zip to remove the
    > dependency on libcups.dll
    >


    I went after the download from the URL above. Interestingly, even on a POTS
    dial up with about an hour download time, the download with Peter's SMK 1.7.1
    latest showed 100% completion in just a few seconds! Interestingly this is
    the 'updated' file I got.

    In theory, it is exactly the same file which I got a couple days ago as to file
    size and so on, but I can't get to the original at the moment to do a precise
    content comparison on the archives with GCF for OS/2 on my laptop which was
    provided with the original file before I left.

    12-30-07 2:15p 13867165 62 gs861os2.zip

    I tried that. It smashes the install up into the unzip routine where for a
    hundred files in it up in the 600# range I see the 'error' something like
    'improper zip file pointer' over and over again in the install window.

    OK .. there may be an issue here with the browser download game that's been an
    object of my note for years. If a given 'file' has the same name, the same
    date and time for it, yet is actually different inside it though it might even
    be the same size, the browser thinks that it has already downloaded that file
    and finishes it .. corruptly. For that reason, I kept the above copy of the
    'file' in a separate directory, removed the original, and cleared the complete
    cache directory in SMK and downloaded the file again from your URL above. Here
    is what we get an hour or so later:

    12-30-07 3:38p 13867165 62 gs861os2.zip

    I did the complete re-install test all over again. I get the same corrupt
    unzip pile of errors. Further, during the configuration section of the install
    the only script suggested version that shows up is the 7.04 or whatever. Even
    if you try the hand correction as to the font directory and version, of which
    the directory itself is there in the proper place, the install cannot finish
    correctly at all due to the corruption I have here.

    Running unzip -t on either file produces errors - the summary of which is:

    Beginning in that archive at the below:

    file #109: bad zipfile offset (local header sig): 3752566
    file #110: bad zipfile offset (local header sig): 5219097
    file #111: bad zipfile offset (local header sig): 5219539

    and continuing all the way to:

    file #725: bad zipfile offset (local header sig): 12505782
    file #726: bad zipfile offset (local header sig): 12506792
    file #727: bad zipfile offset (local header sig): 12584410
    file #728: bad zipfile offset (local header sig): 12585388

    Even a raw unzip -t test run knows the archive is corrupt, just as the install
    routine shows as we run it.

    Running the OS/2 GFC graphics file compare program on both these files shows
    them to be exactly the same .. and exactly the same corruption..

    Thoughts?

    Mike Luther - off in telephone land at the moment.

  5. Re: ghostscript

    On Sun, 30 Dec 2007 08:53:07 UTC, "Paul Smedley" wrote:

    > I refreshed http://download.smedley.info/gs861os2.zip to remove the
    > dependency on libcups.dll


    I see the same corruption that Mike found, but at least gsdll2.dll is
    good. :-) Replaced the previous file with this one new one and
    everything seems to work. Thanks!
    --
    Greetings, | My From: address is valid as is the version without "spam"
    Peter. | I try to find real messages among the spam once a week

  6. Re: ghostscript

    Mike Luther wrote:
    >
    > I tried that. It smashes the install up into the unzip routine where
    > for a hundred files in it up in the 600# range I see the 'error'
    > something like 'improper zip file pointer' over and over again in the
    > install window.
    >


    I had the same problem.

    However, running "zip -FF gs861os2.zip" fixed the archive.
    After that, I was able to extract it and it works!

    Thanks to Paul once again!

    Piersante

  7. Re: ghostscript

    Fixes the file but ..

    piesse wrote:
    > Mike Luther wrote:
    >>
    >> I tried that. It smashes the install up into the unzip routine where
    >> for a hundred files in it up in the 600# range I see the 'error'
    >> something like 'improper zip file pointer' over and over again in the
    >> install window.
    >>

    >
    > I had the same problem.
    >
    > However, running "zip -FF gs861os2.zip" fixed the archive.
    > After that, I was able to extract it and it works!
    >
    > Thanks to Paul once again!
    >
    > Piersante


    The install still will not load a document until I place the libcups.dll
    somewhere in the lIBPATH just like the initial one did ..

    Once I do that GSview works but not as 'installed'.

    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  8. Re: ghostscript

    OK -- your suggestion works totally now *BUT* read the rest please!

    piesse wrote:
    > Mike Luther wrote:
    >>
    >> I tried that. It smashes the install up into the unzip routine where
    >> for a hundred files in it up in the 600# range I see the 'error'
    >> something like 'improper zip file pointer' over and over again in the
    >> install window.
    >>

    >
    > I had the same problem.
    >
    > However, running "zip -FF gs861os2.zip" fixed the archive.
    > After that, I was able to extract it and it works!
    >
    > Thanks to Paul once again!
    >
    > Piersante


    We really are back to the issue where Seamonkey downloads and the cache plus
    action by SMK if you have downloaded a file before with the same name will bite
    you in the nose!

    I'm back at the broadband connection site now. If I simply click on Paul's URL
    as quoted to refresh the download for gs861os2.zip, it is about two seconds
    before I get the 100% complete mark. I get the same 13942146 byte 'file' as I
    had before. Which I *CAN* use your suggestion to 'fix'. But that one still
    results in a GSview install which requires the libcups.dll in the LIBRARY path
    to load the documents.

    OK, if I completely clear the cache in Seamonkey, and rename the gs861os2.zip
    file that is 'corrupt' to say gs861os2b.zip, then download a complete 'new'
    gs861os2.zip into the same test directory, I get the exact same size 13942146
    byte file as before! It, too, is corrupt internally. OK I run your -FF force
    fix method on it.

    Surprise! The 'fixed' file size for the completely new download is much
    smaller than the 13MB size for the 'fixed' other one for just instructing
    Seamonkey to 're-download' the file from Paul.

    Now we get a file with the -FF technique which is:

    12-31-07 2:34p 12724869 0 gs861os2.zip
    12-31-07 2:52p 13942156 0 gs861os2b.zip

    If I use the smaller 12724869 byte file for the install of the current GSview
    application, it works as expected. I do not need to place the libcups.dll file
    in the LIBRARY path for the application to work.

    We are right back to the same issue of confusion over same name files and
    release size information, somehow, that has been afflicting us with browser
    downloads in HTML technique for even way back into OS/2's TestCase operations
    for years and years.

    I suspect that all Paul needs to do is run the -FF operation on the CURRENT
    file he is offering in the URL stated. That'll fix the problem. So long as
    the people know they have to erase the earlier file, and clear the cache in
    Seamonkey if they are using these tools and not some other form of file
    download tool for his URL citation that doesn't have this problem.

    I hope this helps everyone! And thanks Paul for your work!




    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  9. Re: ghostscript

    Paul .. would you be kind enough to read my detailed answer to Piesse?

    Paul Smedley wrote:

    > I refreshed http://download.smedley.info/gs861os2.zip to remove the
    > dependency on libcups.dll
    >


    Your file currently in that cited URL download can be 'fixed' here with his
    suggested 'zip -FF gs861os2.zip' action. That will result in a file which does
    not require the libcups.dll to be placed in the LIBRARY path.

    But a user of Seamonkey for HTML downloads has to be very careful in how they
    do this if they have used that URL for download previously to get home free to
    your very valuable work!

    Thanks!

    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  10. Re: ghostscript

    On Mon, 31 Dec 2007 15:00:19 UTC, Mike Luther
    wrote:

    > We really are back to the issue where Seamonkey downloads and the cache plus
    > action by SMK if you have downloaded a file before with the same name will bite
    > you in the nose!
    >
    > I'm back at the broadband connection site now.


    Sorry, what's a broadband connection site?

    Anyway, sounds like your ISP is running a transparent caching proxy.
    Complain.




  11. Re: ghostscript

    Hi Guys,

    On Sun, 30 Dec 2007 16:36:06 UTC, "Peter Weilbacher"
    wrote:

    > On Sun, 30 Dec 2007 08:53:07 UTC, "Paul Smedley" wrote:
    >
    > > I refreshed http://download.smedley.info/gs861os2.zip to remove the
    > > dependency on libcups.dll

    >
    > I see the same corruption that Mike found, but at least gsdll2.dll is
    > good. :-) Replaced the previous file with this one new one and
    > everything seems to work. Thanks!


    Sorry for the hassles - I can't delete the original file to reupload
    it right now - but I'm reuploading to
    http://download.smedley.info/new/gs861os2.zip - hopefully this one
    will be better!

    --
    Cheers,

    Paul.

  12. Re: ghostscript

    Thanks Paul ..

    Paul Smedley wrote:
    > Hi Guys,
    >
    > On Sun, 30 Dec 2007 16:36:06 UTC, "Peter Weilbacher"
    > wrote:
    >
    >> On Sun, 30 Dec 2007 08:53:07 UTC, "Paul Smedley" wrote:
    >>
    >>> I refreshed http://download.smedley.info/gs861os2.zip to remove the
    >>> dependency on libcups.dll

    >> I see the same corruption that Mike found, but at least gsdll2.dll is
    >> good. :-) Replaced the previous file with this one new one and
    >> everything seems to work. Thanks!

    >
    > Sorry for the hassles - I can't delete the original file to reupload
    > it right now - but I'm reuploading to
    > http://download.smedley.info/new/gs861os2.zip - hopefully this one
    > will be better!
    >


    Works perfectly here as far as I can tell.

    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  13. Re: ghostscript

    On Mon, 31 Dec 2007 22:45:13 UTC, "Paul Smedley" wrote:

    > Sorry for the hassles - I can't delete the original file to reupload
    > it right now - but I'm reuploading to
    > http://download.smedley.info/new/gs861os2.zip - hopefully this one
    > will be better!


    Yes, that works fine now, thanks. So you are building two different
    versions now, one with CUPS support and this one without?
    --
    Greetings, | My From: address is valid as is the version without "spam"
    Peter. | I try to find real messages among the spam once a week


  14. Re: ghostscript

    Hi Peter,

    On Tue, 1 Jan 2008 21:01:40 UTC, "Peter Weilbacher"
    wrote:

    > On Mon, 31 Dec 2007 22:45:13 UTC, "Paul Smedley" wrote:
    >
    > > Sorry for the hassles - I can't delete the original file to reupload
    > > it right now - but I'm reuploading to
    > > http://download.smedley.info/new/gs861os2.zip - hopefully this one
    > > will be better!

    >
    > Yes, that works fine now, thanks. So you are building two different
    > versions now, one with CUPS support and this one without?


    Right now - yes; later - no - I'll most likely link the cups stuff
    statically to avoid the libcups.dll problem.

    --
    Cheers,

    Paul.

  15. Re: ghostscript

    Bob -- I'd like to learn something from you if I can ..

    Bob Eager wrote:

    > On Mon, 31 Dec 2007 15:00:19 UTC, Mike Luther
    > wrote:
    >
    >> We really are back to the issue where Seamonkey downloads and the cache plus
    >> action by SMK if you have downloaded a file before with the same name will bite
    >> you in the nose!
    >>
    >> I'm back at the broadband connection site now.

    >
    > Sorry, what's a broadband connection site?
    >
    > Anyway, sounds like your ISP is running a transparent caching proxy.
    > Complain.
    >
    >
    >


    There are a number of sites from which I connect to my IP. The main site is
    via cable, which I call broadband in that it has download speeds way up beyond
    ADSL, for example. I do not have any ADSL connection here. At several sites
    which have no access to my IP for cable or other high speed 'broadband'
    connection types, the only connection to my IP is via plain old POTS telephone
    service. At one site, the maximum baud rate way out many quarters away from
    the little rural switch is about 21,600 baud via modem, sometimes 24,000 baud
    but never better than that.

    Testing 10-15+ megabyte downloads on slow POTS modem dial up lines like this is
    sort of painful as to the time it takes to test various files.

    For many years now on everything from Netscape on upward to the latest
    Seamonkey, on HTTP downloads, if a 'new' file on any remote site such as Paul's
    site has a file on it of the same name as one which has already been downloaded
    via HTTP in Seamonkey, then the browser 'thinks' that it has already gotten
    that file if the file is still in the cache directory. In fact, as far as I
    know, even though you may download a file such as gs861os2.zip, and the final
    destination directory has the file in it, a DUPLICATE file of that same size
    and 'identity' but not necessarily the same name for the file will still be in
    the cache directory for SMK.

    For example, the file which Paul fixed with the same name and released as
    smk861os2.zip is now in the directory I chose for it as:

    1-01-08 12:39a 12650092 66 gs861os2.zip

    But notice what is STILL in the cache directory in my profile:

    1-01-08 12:39a 12650092 0 6DA480E6d01

    And also, in that cache directory in my profile is:

    12-31-07 2:32p 13867165 0 64B30BA8d01

    That is the previous 'cache' download for the same file name of gs861os2.zip
    which was last taken in which is one of the corrupt versions. Had I tried to
    download the most recent fixed version into the directory for a file of the
    same name, SMK would have asked me if I choose to overwrite the file. I would
    tell it yes to do that. Then .. even though the file was a different file, SMK
    would have internally decided that the file had already been downloaded, almost
    instantly flashed in the download manager that the file was 100% and the file
    would never actually be downloaded as to the new release!

    This has been happening to me not only for the IP to which I am normally
    connected, but at a number of others as well wherever a browser is used for
    HTML orchestrated downloads. It was a very frequent issue with the IBM OS/2
    TestCase where for good reasons there would be small internal changes possible
    in a specific file, yet the date, time and name of the file .. as well as even
    the file size .. might be the same!

    The only way to prevent this, as far as I have ever known, is to use some other
    form of HTML file transfer program other than the Netscape - upward to even the
    present SMK releases. Which I've never attempted.

    What I would like to learn is how a transparent caching proxy involving my ISP
    works to cause this? It is true that I do run Privoxy as a proxy operation on
    my browsers. But to my knowledge, this issue with the browser cache holding
    file which is a 'duplicate' of the actual file stored, has been a problem for
    this for a lot longer than Privoxy or it's predecessor.

    Thoughts?


    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  16. Re: ghostscript

    On Wed, 2 Jan 2008 01:22:50 UTC, Mike Luther
    wrote:

    > There are a number of sites from which I connect to my IP. The main site is
    > via cable, which I call broadband in that it has download speeds way up beyond
    > ADSL, for example.


    Broadband is not defined by speed - but that's another issue. Broadband
    can be slow, and non-broadband can be fast.

    > What I would like to learn is how a transparent caching proxy involving my ISP
    > works to cause this? It is true that I do run Privoxy as a proxy operation on
    > my browsers. But to my knowledge, this issue with the browser cache holding
    > file which is a 'duplicate' of the actual file stored, has been a problem for
    > this for a lot longer than Privoxy or it's predecessor.


    If your *ISP* is running a caching proxy, and the cache hangs on to
    stale stuff, you'll see that effect. Some ISPs here in the UK are
    notorious for this. Luckily, my ISP filters and proxies nothing at all.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2