[2052] in Enterprise Print Delivery Team
Re: 300 DPI v. 600 DPI and test printouts
daemon@ATHENA.MIT.EDU (David F Lambert)
Thu Dec 13 12:00:47 2001
Message-Id: <200112131700.MAA20162@fort-point-station.mit.edu>
Date: Thu, 13 Dec 01 11:45:37 EST
From: David F Lambert <LAMBERT@MITVMA.MIT.EDU>
To: Gillian Emmons <gemmons@MIT.EDU>, "David M. Rosenberg" <Rosenberg@MIT.EDU>,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>,
jnicker@MIT.EDU
cc: debbie@MIT.EDU, mprudden@MIT.EDU, Allan Davidson <davidsoa@MIT.EDU>,
r3-print@MIT.EDU
In-Reply-To: Message of Tue, 11 Dec 01 16:05:28 EST from
<LAMBERT@MITVMA.MIT.Edu>
Hi Folks,
I'm resending this note for four reasons.
1) r3-print's email address was wrong on the initial email exchange
2) Printdel would like to request that Jay send us a couple of additional
full size GL test files. We'd feel more comfortable seeing a few more
of these just to make sure there are no surprises with the full December
GL run.
3) I misspoke below. Lynne did the manual rip to test file size info -
not to actually produce a ripped file for printing. The good news is
that the file DID rip and print successfully thru the normal ripping
and printing processes! :)
4) Just now on the phone Gill mentioned a few files for the ancillary reports
needed to be resubmitted. A prior note explained the problem but I'm
not sure who that note went to now. So, for everyone's benefit, the
problem was associated with making copies of incoming files for
safety's sake during earlier testing. The safety files were being
saved in a very small filesystem which became full, and caused problems
for a few of the ancillary reports which were submitted. We're taking
three corrective actions to fix this. Most immediately, Lynne is closely
monitoring all the filesystems for fullness. Second, we're looking into
building some cron jobs to automatically check for space issues. Third,
we will eliminate the no longer needed "safety" copy of the file currently
saved to a small filesystem.
-Dave
On Tue, 11 Dec 01 16:05:28 EST David F Lambert said:
>Hello Gill & others,
>
>We're glad to hear the 600 dpi test looked good since we are emulating
>Postscript when output is directed to the IBM printers. We had a minor
>hiccup with the single file test. As you may recall, IPM needs to rip
>each Postscript file to process on the IBM printers. The original
>Postscript file was received by IPM just fine. However, during the
>ripping process, an unexplainable I/O occurred ~90% into the file. The
>output that was produced looked good. For this test, a command was
>issued to rip the file. When done via this command, a single ripped
>file is produced. If we let IPM rip a file automatically, the process
>produces many little ripped files. So, we're guessing there was some
>sort of file size limitation. The normal mode is for IPM to automatically
>rip files which are to be printed. We expect to do more testing over the
>next day or two. We'll post results as soon as possible.
>
>I know there were serious concerns about the run times for producing
>the new Postscript files vs the old AFP output. We're very glad to hear
>the run time of the full job did not dim the Cambridge lights or run
>thru the end of this FY's quarter! :)
>
>-Dave
>
>On Mon, 10 Dec 2001 08:37:09 -0500 Gill said:
>>The 600 dpi test we did looked good (our output was delivered to us on
>>Friday). How did the test go with the full file we sent to Lynne? Also,
>>our test of a full run for the sapscript statement on the SAP side was
>>okay, it took 12 hours. The real statement run we did on Friday using AFP
>>took about 9.5 hours. From our point of view that difference is not a
>>problem.
>>
>>
>>
>>At 07:20 PM 12/3/2001 -0500, David F Lambert wrote:
>>>David,
>>>
>>>Sorry for the lack of formal response until now. Thankfully, I know
>>>you've seen several emails which addressed much of your note already.
>>>ASST has physically installed the new disks on the production & test
>>>IPM servers. They are increasing the filesystem sizes on the test
>>>server tonight and will do the same for Pillage tomorrow morning.
>>>
>>>Lynne did configure the GLMP queue to process the output at 600 dpi.
>>>However, as she noted in her email, we will need to see if the additional
>>>disk can accommodate the much larger 600 dpi output files. We were
>>>appreciative that Gill made the 600 dpi output a request but not
>>>a hard requirement.
>>>
>>>Also, I wanted to thank Allan for jumping in quickly, and finding
>>>solutions to the missing line & jagged line on the left edge.
>>>
>>>-Dave
>>>
>>>On Wed, 28 Nov 2001 20:15:59 -0500 you said:
>>> >PrintDel Colleagues, Gill, and Jay,
>>> >
>>> >1. Mark Prudden sent another two short files (approx 7 pages each) to GLTW
>>> >and GLMP. We would appreciate having them printed and the output brought to
>>> >us (NOT delivered to the apparent addressee).
>>> >
>>> >2. I understood from our meeting on Monday that PrintDel will explore
>>> >running the GLMP queue at 600 DPI. We know that the grey bars look much
>>> >better printed at 600 DPI. Can you give us an update on what you've found?
>>> >
>>> >3 If it is necessary to run the GLMP queue at 300 DPI for the November
>>> >statements, could you continue trying to get to 600 DPI in time for the
>>> >December statements?
>>> >
>>> >4. Independent of whether GLMP ends up as 300 DPI or 600 DPI, I think that
>>> >the test queues (GLTE and GLTW) should run at the same resolution as the
>>> >production queue - in order to make test output as representative of
>>> >production output as possible.
>>> >
>>> >5. In the very short term (e.g. Thursday, 29-Nov-2001), Gill and Jay need
>>> >to be able to see sample output produced at both 300 DPI and 600 DPI. Can
>>> >you arrange that output produced under either Gill's user ID (GEMMONS) or
>>> >Jay's user ID (JNICKER) on either the GLTE (600 DPI) queue or the GLMP (300
>>> >DPI) queue be printed in E19 and held for (or brought to) Gill or Jay?
>>> >
>>> >6. Allan Davidson has been doing some work with the SAPscript layout set
>>> >for the Summary Statement and the DTR. Right now that work is only in SF2.
>>> >We have been looking at the Summary Statement and the DTR as printed on a
>>> >300 DPI departmental HP printer (via Athena Print Services) and on both 300
>>> >and 600 DPI IP60 printers (via InfoPrint Manager). These is nothing that we
>>> >can do about the grey areas looking like separate dots (that depends
>>> >entirely on the print resolution). However, Allan has dealt with the solid
>>> >line at the bottom of the DTR and the vertical line at the left of the
>>> >Summary Statement and the DTR. We believe that that if the Summary
>>> >Statements and the DTRs have to be printed at 300 DPI, the only thing that
>>> >will not look good will be the grey areas - and they won't look any worse
>>> >than they do on the current Summary Statements and DTRs (printed via AFP).
>>> >
>>> >--
>>> >/David M. Rosenberg rosenberg@mit.edu 1-617-253-8054
>>
>>Gillian Emmons
>>Controller's Accounting Office
>>3-2777
>>E-19 504 E
>>
