home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / os2 / apps / 7903 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  1.7 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!ames!elroy.jpl.nasa.gov!nntp-server.caltech.edu!jyang
  2. From: jyang@cco.caltech.edu (Chih Meng Yang)
  3. Newsgroups: comp.os.os2.apps
  4. Subject: gs252pm and SWAPPER.DAT
  5. Date: 5 Nov 1992 23:32:42 GMT
  6. Organization: California Institute of Technology, Pasadena
  7. Lines: 24
  8. Distribution: world
  9. Message-ID: <1dcauqINNhed@gap.caltech.edu>
  10. NNTP-Posting-Host: sandman.caltech.edu
  11.  
  12. Recently there were posts by people who said that using gs252pm (or gsos2pm10)
  13. causes their swapfile to grow out of control.  The fact that this happens
  14. when they are using gs252pm to view files with fonts leads me to suspect that
  15. they are not using the dll "emxlibc.dll" that I supplied with gs, but
  16. instead using the emxlibc.dll that came with emx 0.8e.  As I pointed out
  17. in the file "readme.1st", in the section "***** VERY IMPORTANT****",
  18. the emxlibc.dll that came with emx 0.8e has a bug in the routine "frexp",
  19. which is used by GhostScript's font rendering routines.  The bug COULD
  20. make GhostScript think that the fonts are HUGE, thus requiring a lot of
  21. memory to store or render the fonts, eventually filling the swapfile.
  22.  
  23. I have tried gsos2pm10 on every PostScript file I have, including some
  24. that have quite a few fonts, and gsos2pm10 correctly display all of them
  25. except one - "warbird.ps", which was emailed to me by a user of gsos2pm10,
  26. Darrel Hankerson.  Gsos2pm10 displays nothing for "warbird.ps", but does
  27. not crash or otherwise misbehave.  
  28.  
  29. PS:  Gs252pm and gsos2pm10 do not allocate space in the swapfile directly
  30. or assume anything about the swapfile.  The nice thing about OS/2 is that
  31. your program does not have to worry about managing virtual memory.
  32.  
  33. Jim Yang
  34. jyang@daedalus.caltech.edu
  35.  
  36.