[1855] in Enterprise Print Delivery Team
Re: Filesizes for rip options
daemon@ATHENA.MIT.EDU (Lynne E. Durland)
Tue Oct 30 14:56:04 2001
Message-Id: <5.0.2.1.2.20011030145736.03b468d0@hesiod>
Date: Tue, 30 Oct 2001 14:59:38 -0500
To: David F Lambert <LAMBERT@MITVMA.MIT.EDU>,
"Lynne E. Durland" <durland@MIT.EDU>,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
From: "Lynne E. Durland" <durland@MIT.EDU>
In-Reply-To: <200110292337.SAA15492@fort-point-station.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Dave,
I did run the test today, and the file would not take off until I reset the
job to run at 300 instead of 240.
The actual destination was set to 300 and 600 for the W91 printer and 240
and 600 on the E19 printer. I have reset both printers to accept 240, 300
and 600. I set the logical destination glmp to 300 resolution.
We should now be ready to for the SAP run coming up in 10 days or so.
Lynne
At 05:38 PM 10/29/2001, David F Lambert wrote:
>Howdy,
>
>Looking back at the recent disk sizing work, we said one GL statement
>file (Postscript) was ~33MB and the ripped file was ~.5GB. So, the
>13.2 looks about right given rounding (and I remember rounding up to
>the ~.5GB number).
>
>I'm concerned about decreasing the resolution from 300dpi to 240dpi since
>the client has been testing and reviewing the quality of output. Of course,
>they've been looking at 300dpi (default) quality.
>
>Given the client testing already performed @ 300dpi, and the disk
>sizing effort which was based unknowingly on a 300dpi assumption,
>I'd vote for keeping the monthly GL at 300dpi but changing all other
>queues to 600dpi.
>
>For SAP & other users who move from 600dpi local printers, there should
>be no resolution loss. For recipients of the monthly GL statements,
>they should see a slight improvement over the forced 240dpi provided
>via the mainframe path.
>
>Could you live with this proposal, Lynne?
>
>-Dave
>
>On Mon, 29 Oct 2001 13:43:24 -0500 Lynne said:
> >Greetings,
> >
> >I have now had a chance to run some rips on the file Mark Prudden submitted
> >this morning.
> >
> >The results were about what was expected.
> >
> >The 240 dpi file was about 8 times larger than the original PS file.
> >The 300 dpi file was about 13.2 time larger than the original PS file.
> >The 600 dpi file filled the disk space where I was writing the test files
> >and so I have no data. (the 300 dpi file took up ~37% of the space)
> >
> >In poking in the manuals I think I have figured out that if the resolution
> >is set to default for the logical destination/default document, then this
> >will pass the information to the transform to rip the file at 240 dpi. The
> >default behavior for the transform as currently configured is 300 dpi.
> >
> >The printer is currently set to 240/600 dpi setting.
> >
> >So I believe that the best course of action is for the production GL queue
> >be set to default, which is 240 dpi.
> >
> >This will make our space calculations true and workable. Running at 600
> >would not leave us room for growth and could potentially fill the space we
> >have requested.
> >
> >I will set the option in the logical destination tomorrow, that will give
> >y'all a chance to let me know if my thinking is bent or on the mark.
> >
> >Lynne
> >Lynne E. Durland
> >Information Systems
> >Database Services
> >W91-109
> >O: 617-258-5857
> >C: 617-293-8091
> >H: KB1FEM
> >
> >"When one door of happiness closes, another opens; but often we look so
> >long at the closed door that we do not see the one which has been opened
> >for us."
> >
> > --Helen Keller
> >
Lynne E. Durland
Information Systems
Database Services
W91-109
O: 617-258-5857
C: 617-293-8091
H: KB1FEM
"When one door of happiness closes, another opens; but often we look so
long at the closed door that we do not see the one which has been opened
for us."
--Helen Keller
