Bug 686919 - pswrite should be a high-level device
Summary: pswrite should be a high-level device
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Writer (show other bugs)
Version: 0.00
Hardware: All Linux
: P4 enhancement
Assignee: Igor Melichev
URL:
Keywords:
: 687050 687335 687380 687665 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-06-13 15:43 UTC by David Hammerton
Modified: 2008-12-19 08:31 UTC (History)
4 users (show)

See Also:
Customer:
Word Size: ---

Attachments
File that, when printed, takes ages to print with ghostview. (109.49 KB, application/pdf)
2003-06-13 15:44 UTC, David Hammerton 		Details
Improved pswrite capability (2.92 KB, text/plain)
2004-04-22 11:40 UTC, Igor Melichev 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Hammerton 2003-06-13 15:43:31 UTC 
Hi There, 
 
This bug is originally from bug 59636 at bugs.kde.org: 
http://bugs.kde.org/show_bug.cgi?id=59636 
 
It seems with the given file, kghostview takes much longer to print than xpdf or 
acroread. I have narrowed it down to the fact that, on a single page, kghostview, 
driven by ghostscript will be sent to the printer as a 1355kb file, here is a list of other 
programs printed file size: 
 
According to cups, the following file sizes for each job, printing the same page, 
existed:  
 KDE Print System [kghostview] 1355k  
 AcroywWSVc [acroread] 69k  
 (stdin) [xpdf] 35k  
  
These were all the same page (page 3 on the file I'll try to upload), and the time to 
print reflects the size of the output.  
 
So I guess that ghostscript is just generating way too big files when it tries to print? 
 
Thanks for you're attention. 
 
Cheers 
 
David
Comment 1 David Hammerton 2003-06-13 15:44:19 UTC 
Created attachment 196 [details]
File that, when printed, takes ages to print with ghostview.
Comment 2 Jack Moffitt 2003-06-19 10:39:04 UTC 
This issue would be solved by making pswrite a highlevel device.  This is
currently on the todo list, and we'll use this bug to track the project's status.
Comment 3 Igor Melichev 2003-12-14 12:01:07 UTC 
Changing the assignment to Ray because he is gathering the information from 
customers about the importance of this improvement.
Comment 4 Igor Melichev 2004-03-09 02:49:59 UTC 
*** Bug 687335 has been marked as a duplicate of this bug. ***
Comment 5 Igor Melichev 2004-04-22 11:40:07 UTC 
Created attachment 634 [details]
Improved pswrite capability
Comment 6 Jack Moffitt 2004-06-18 10:06:19 UTC 
From 687050:
Using pswrite Device, setscreen operator seems to get lost. After processing
a PS or PDF file containing setscreen / halftone dictionary all of this
information e.g. Frequency, Angle SpotFunction is lost.
When the output (separated file) is sent to an imagesetter, all colors are
rasterized with the same angle.

The same problem occurs with the pdfwrite device.

Here is the test snippet:
%%%%%
<< /PageSize [100 100]>> setpagedevice
 
/DeviceGray setcolorspace
 
65 25 { exch pop abs neg } setscreen
 
.5 setgray
4 setlinewidth
0 0 moveto
100 100 lineto
stroke
 
showpage
Comment 7 Jack Moffitt 2004-06-18 10:06:39 UTC 
*** Bug 687050 has been marked as a duplicate of this bug. ***
Comment 8 Jack Moffitt 2004-06-23 11:27:48 UTC 
*** Bug 687380 has been marked as a duplicate of this bug. ***
Comment 9 Jack Moffitt 2004-09-13 06:46:27 UTC 
*** Bug 687665 has been marked as a duplicate of this bug. ***
Comment 10 Jack Moffitt 2005-03-04 09:39:28 UTC 
A customer 600 bug was closed as a dupe of this, so propagating the customer
status to this bug.
Comment 11 Igor Melichev 2005-03-04 12:54:51 UTC 
Drop the customer status of this bug sinse Miles says that the customer 600 is 
not longer supported.
Comment 12 Igor Melichev 2005-08-18 02:10:42 UTC 
The ps2write device now works for this.