[gs-bugs] [Bug 542664] gs creates very large temp file

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Tue Jul 27 19:32:30 UTC 2010


http://bugs.ghostscript.com/show_bug.cgi?id=542664

Originally reported by: jackiem at 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 from Ray Johnston <ray.johnston at artifex.com> 2002-05-29 00:46:48 UTC ---
Comment originally by rayjj at 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 from SaGS <sags5495 at hotmail.com> 2010-07-27 19:32:28 UTC ---
Created an attachment (id=6563)
 --> (http://bugs.ghostscript.com/attachment.cgi?id=6563)
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.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list