[1852] in Enterprise Print Delivery Team
Re: Filesizes for rip options
daemon@ATHENA.MIT.EDU (Lynne E. Durland)
Mon Oct 29 20:49:27 2001
Message-Id: <5.0.2.1.2.20011029201058.02a8f880@hesiod>
Date: Mon, 29 Oct 2001 20:48:38 -0500
To: David F Lambert <LAMBERT@MITVMA.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,
Let me run a test at 300. I am not entirely sure the printer will run at
300 without an additional change in the menu settings. It is currently set
to 240/600.
At 05:38 PM 10/29/2001 -0500, 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.
If PI1P and PI1T were set to default then they were getting 240 dpi not
300. What I said was the default rip, in the transform is 300, the default
for a psf printer is 240, in the logical destination. The reading of the
manual I did this afternoon indicates that the setting in the logical
destination overrides the default set in the psf2afpd.cfg file.
>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?
I may not have been clear in my statement below about behaior and
defaults. I hope I have made it better. I will run a test with the
current Mark file set to 300 and see if the printer will print it. When I
said the transform defaults to 300, I was running from the command line
without the -r option which forces the rip to happen at the resolution in
the command, overriding the default in the .cfg file.
ie ps2afp -r600 -o /var/mit/testing/gl600.afp foobar --> results in rip
at 600 dpi
ps2afp -o /var/mit/testing/gldef.afp foobar --> will result in a rip at
300 dpi
Printing a job submitted to a logical destination with resolution set to
default will result in the job being ripped at 240 dpi if actual
destination is a psf printer. (IP60 printer is a psf printer) I have just
grepped through the error log for the 16th when Banta and I were doing the
testing. The gl testing that I was running was at 600 dpi. We did print a
couple of the test files Theresa had submitted to the gltw or glte queue
which were set to default in the logical destination, they ripped at 300.
So I will set glmp to default which will rip at 300, and print at either
300 or 240, based on the output we looked at last week, Dave, I am thinking
it will still print at 240 since the printer is set to 240/600. I can set
or teach the operators to set the printer to another setting that will let
the resolution out of IPM determine the resolution the printer prints at,
but that would mean yet another step to print, and I believe a restart of
the printer when that setting is changed, further lengthening the switch
process.
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 Team
W91-109
P:258-5857
E: durland@mit.edu
H: 603-421-0940
H: KB1FEM
"When speaking to a Bear of Very Little Brain, remember that long words may
Bother Him."
--A.A. Milne
