laser-lovers@uw-beaver (03/26/85)
From: William LeFebvre <phil@rice.ARPA>
Background:
We have an Imagen 8/300 attached to our Ethernet and driven primarily
by a VAX 11/750 running the standard 4.2BSD spooling software.
I have been trying to print something with the amssmc40 font in TeX.
This font is a 40 point sans-serif font that is good for things like
name plates for office doors. But, alas, when I try to print my first
name ("William"), the "W" comes out looking like something that is
almost, but not completely unlike a "W" (for non-Douglas Adams fans,
that statement implies that it looks like crap). Further investigation
has shown that all previewers and font editors display the capital "W"
fine. I had just assumed that the converter I was using ("iptex",
written by Chris Torek) just didn't know how to deal with a glyph that
large.
One of my office mates started investigating this problem last night.
He produced an imPRESS file from the appropriate portions of the iptex
distribution that prints a "W" in amssmc40. Our imPRESS utilities say
this file looks just dandy. The bitmap for the BGLY command comes out
as pretty as you please (rest easy Chris -- it wasn't your fault, and
sorry for not having faith in your code). BUT, when we send this
imPRESS file to the printer, the capital "W" once again comes out
looking like something that is almost, but not completely unlike a "W".
Admittedly, this is the largest glyph that we have ever tried to print.
It is 139 pixels wide by 116 pixels high. We have printed every
alphabetic character in amssmc40 and they all work fine, except for the
capital "W".
Has anyone seen this before, and is there any possible way to solve the
problem? I would hate to have to change my name! (I could use "Bill",
but that's boring and it doesn't really solve the problem.) I have
found nothing in the imPRESS documentation that would indicate a limit
on the size of an individual glyph. The only thing that comes close is
an upper bound on the total amount of memory that all downloaded glyphs
may consume. But overloading this produces error messages, and nothing
that we have done that relates to this problem has produced error messages.
Just to make sure there is no communication breakdown: this is NOT a
problem with TeX, the pxl files, or even iptex. It appears that the
problem is with the Imagen 8/300 itself.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.arpa>laser-lovers@uw-beaver (03/27/85)
From: William LeFebvre <phil@rice.ARPA>
Here's the latest on my 40 point W glyph problem:
We are still running version 2.04 of the printer software. Both David
Fuchs at Stanford and Chris Ryland of Imagen have printed an imPRESS
file on 8/300 printers running version 2.1 for me. The file (which
failed on our printer) works fine on theirs. I hope that this is the
only problem and that once we get 2.1 running on our printer that this
problem will go away. I just found out today that someone else here
has tried to print a 36 point radical with ditroff and experienced a
similar problem. If anyone out there is still running 2.04 and would
be willing to run a test for me, let me know. I am still interested to
see if other 8/300s with 2.04 have the same problem.
Thanks to David and Chris for taking the time to help me with this.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.arpa>laser-lovers@uw-beaver (03/27/85)
From: Dave Nelson <daven@lll-crg.ARPA> This may not be apropos, but... With our older 240dpi Imagen, we at LLNL had problems printing 40 point ANYTHING on ditroff. As I recall, this was because the supplied driver (called dcan) used font files in vfont(5) format, and the large font sizes had more than 64K worth of bitmaps. When this happens, dispatch.addr (excuse the abuse of notation) no longer points to the start of the glyph for glyphs beyond 64K into the font file. Thus the driver picks up random bits at offset mod 64K and uses them as the glyph. We kludged around it without much difficulty. daven@lll-crg