Bug 542664 - gs creates very large temp file
Summary: gs creates very large temp file
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: master
Hardware: All All
: P4 normal
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-11 13:42 UTC by Jack Moffitt
Modified: 2010-07-27 19:39 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
Suggested patch: use a Win9X-compatible construct instead of ‘%~dp0’ (13.97 KB, patch)
2010-07-27 19:32 UTC, SaGS
Details | Diff
Suggested patch: %TEMP%-related fixes (11.35 KB, patch)
2010-07-27 19:33 UTC, SaGS
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Moffitt 2002-04-11 13:42:51 UTC
Originally reported by: jackiem@users.sourceforge.net
Customer #710

Test file testpage.ps.bz2 when run with the tiffg4 device  
works fine at 1200 or 1300 dpi, but at 1270 dpi the
temp files grows so large that it fills up the disk.  I
stopped the file  when it reached 1GB on my system.

Test file available on casper.
Comment 1 Ray Johnston 2002-05-29 00:46:48 UTC
Comment originally by rayjj@users.sourceforge.net
Logged In: YES 
user_id=11206

The problem is that a halftone tile happens to exceed the clist
command reading buffer, and so the clist logic reverts to a
painfully large and slow "default" method to fill the path.

The simple work around is to increase the cbuf_size from the
very small size of 800 bytes to a more reasonable 4K bytes.
This is in gxcldev.h.

There may be some other logic that is the set up of the half
tone tiles that is a more fundamental fix, but nowadays, 800
bytes is a very small buffer, and even 4096 bytes is hardly
noticeable.

The diff is:
*** gxcldev.h   21 Feb 2002 22:24:53 -0000      1.6
--- gxcldev.h   29 May 2002 07:42:20 -0000
***************
*** 261,267 ****
  /* Define the size of the command buffer used for reading. */
  /* This is needed to split up operations with a large amount of data, */
  /* primarily large copy_ operations. */
! #define cbuf_size 800

  /* ---------------- Driver procedures ---------------- */

--- 261,267 ----
  /* Define the size of the command buffer used for reading. */
  /* This is needed to split up operations with a large amount of data, */
  /* primarily large copy_ operations. */
! #define cbuf_size 4096

  /* ---------------- Driver procedures ---------------- */
Comment 2 SaGS 2010-07-27 19:32:28 UTC
Created attachment 6563 [details]
Suggested patch: use a Win9X-compatible construct instead of ‘%~dp0’

Follow-up #1 to rev 11498: replace the use of ‘%~dp0’, available only on 
NT-based Windows, with ‘%0\..’ which is compatible with all Windows 
versions. A special test is also done to detect the situation when the bat 
was found by searching the %PATH%, in which case no path is specified for 
subordinate bat files to allow the command interpreter to look for them 
on the %PATH% as it did for the master bat.
Comment 3 SaGS 2010-07-27 19:33:14 UTC
Created attachment 6564 [details]
Suggested patch: %TEMP%-related fixes

Follow-up #2 to rev 11498:
(i)   By using the construct ‘%TEMP%_at’, temp files may (and often they 
      do, because by default %TEMP% does not have a trailing ‘\’) go in 
      the %TEMP%’s parent, not inside %TEMP%. Use ‘%TEMP%.\_at’ instead.
(ii)  Fix a typo in ps2pdf.bat, the removal of a ‘>>’.
(iii) Enclose temp filenames in quotes, just in case %TEMP% contains 
      spaces or other separators.
Comment 4 SaGS 2010-07-27 19:39:41 UTC
Please ignore the 2 patches (and associated comments) that I just attached, they were for a different bug. Don’t know why, but lately Bugzilla passes to a different, random, report once you post a comment, and I didn’t notice that in time.