hwt@.bnr.ca (Henry Troup) (08/06/90)
I'm a veteran of Dick Rubenstein's Digital Typography course. I remember his discussion of the interaction of device physics (electrostatics) and write- white and write-black devices. How can anyone design low level hints without knowing if the the device is write-white or write-black? And is there any information in systemdict (PostScript) to know which way a laser printer is set up? Exp. Note: quoting Rebenstein here: "One striking difference among laser printers is that some write a black image on the drum during formation of the image, and others write the white part of the image. Because of the way the toner is attaracted to the resulting charged image, one image will be bolder than the other, even thought _exactly_the_same_array_of_dots_ is specified. A font designed for one printer may give dramatically different results on another..." -- Henry Troup - BNR owns but does not share my opinions | 21 years in Canada... uunet!bnrgate!hwt%bwdlh490 HWT@BNR.CA 613-765-2337 |
glenn@heaven.woodside.ca.us (Glenn Reid) (08/07/90)
In article <3880@bwdls58.UUCP> hwt@bwdlh490.bnr.ca (Henry Troup) writes: >I'm a veteran of Dick Rubenstein's Digital Typography course. I remember his >discussion of the interaction of device physics (electrostatics) and write- >white and write-black devices. How can anyone design low level hints without >knowing if the the device is write-white or write-black? And is there any >information in systemdict (PostScript) to know which way a laser printer is >set up? The Adobe Type 1 format addresses this problem with "erosion". It's not covered at all in the Type 1 Font Format specification, as far as I can see, but if you decrypt a font and have a look, you will see some clues (see below). The engine class of the marking engine (write-white or write-black) is stored in the printer somewhere, too. This doesn't really help you to understand how it works, but the code does do something about write-white versus write-black, at least. I wonder why this wasn't covered in the specification, given that you can see vestiges of it when you decrypt a font: % ... /Erode { 9.5 dup 3 -1 roll 0.1 mul exch 0.5 sub mul cvi sub dup mul 76 0 dtransform dup mul exch dup mul add le{pop pop 1.0 1.0}{pop pop 0.0 1.5}ifelse } def % ... /erosion 1 def % default systemdict /internaldict known { 1183615869 systemdict /internaldict get exec dup % get internal dict /erosion known {/erosion get /erosion exch def} {pop} ifelse } if % ... /erode PaintType 2 ne erosion 0.5 ge and def erode {/cy cy 0.5 sub def} if % as long as assume eroding by 0.5, will get same subpixel % position whether positive or negative erosion % cy is now in its post-erosion subpixel location /ey cy dY add def % ey is integral number of pixels from cy /ey ey ceiling ey sub ey floor add def % reverse loc in pixel erode {/ey ey 0.5 add def} if % remove the erosion ey cx flipXY 1 eq {exch} if itransform exch pop y2 sub /eShift exch def /y1 y1 eShift add def /y2 y2 eShift add def /y3 y3 eShift add def % ... /erode PaintType 2 ne erosion .5 ge and def erode {/cx cx .5 sub def} if /ex cx dX add def /ex ex ceiling ex sub ex floor add def erode {/ex ex .5 add def} if ex cy flipXY -1 eq {exch} if itransform pop x2 sub /eShift exch def /x1 x1 eShift add def /x2 x2 eShift add def /x3 x3 eShift add def Disclaimer: a long time ago when I worked for Adobe I wrote a lot of font production software that added, changed, and deleted this erosion code back and forth among various versions of it, but I never knew enough about it to have any "inside information" or anything :-) So this is all just observation, guess-work, and some recollections about the basic function of erosion. Beyond that, you'll have to figure it out for it yourself.... (Glenn) cvn -- Glenn Reid PostScript/NeXT consultant glenn@heaven.woodside.ca.us Independent Software Developer ..{adobe,next}!heaven!glenn 415-851-1785
amanda@mermaid.intercon.com (Amanda Walker) (08/07/90)
Both Adobe and TrueType fonts have a certain amount of support for taking
marking engine characteristics into account. In TrueType, this is done by
having a set of three "compensation terms" that affect four different classes
of distance ("gray", "black", and "white"), which affect how the rounding
works. Of course, like most things in TrueType, this rounding (and which
compensation term to use) must be explicitly programmed into the code for
each glyph.
Adobe implementations of Type 1 interpreters use the "erosion" technique
mentioned by Glenn to adjust outlines depending on printer characteristics.
From what I can tell, the erosion code affects how stem hints are applied,
so that stems get thickened up on write-white engines and thinned down on
write-black engines. It works pretty well; I first got curious about Type 1
fonts when I noticed that they didn't come out anorexic on a Toshiba marking
engine (the Dataproducts LZR-2665), and Type 3 fonts did...
The LanguageGroup hint (and the older RoundStemUp hint) evidently affect
whether or not erosion is applied (since it might not be as good of a
heuristic for non-Roman characters).
--
Amanda Walker <amanda@intercon.com>
InterCon Systems Corporation
--
"What a strange pattern the shuttle of life can weave."
--Frances Marionkevina@apple.com (This space for rent) (08/08/90)
In article <3880@bwdls58.UUCP> hwt@.bnr.ca (Henry Troup) writes: > I'm a veteran of Dick Rubenstein's Digital Typography course. I remember his > discussion of the interaction of device physics (electrostatics) and write- > white and write-black devices. How can anyone design low level hints without > knowing if the the device is write-white or write-black? And is there any > information in systemdict (PostScript) to know which way a laser printer is > set up? TrueType includes instructions which can be used to compensate for engine characteristics. Between write-white and write-black, the significant difference is the resulting size of the black spot. Those instructions modify points based on that size, independent of what the size actually is. (There seems to be a feeling that TrueType's "low-level" hints somehow make it device- or resolution-dependent. This is not the case.) Type 1 fonts have something called "Erode" (in the Private dictionary) and "ErodeSW" (in internaldict-- presumably used by stroked fonts) which appear to be functions to do some sort of engine compensation. Don't know how you can distinguish between write-white and write-black in general, though. --Kevin Andresen [kevina@apple.com] "Orange whip? Orange whip? Three orange whips."
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/08/90)
In article <3880@bwdls58.UUCP>, hwt@.bnr.ca (Henry Troup) writes: > information in systemdict (PostScript) to know which way a laser printer is > set up? Nope, but there is a way to tell. Print Times Roman at 6, 7 and 8 point and look at the tops of the o's e's etc. Try this on an Apple, then a Ricoh based laser like the TI. On a white writer, the tops of those letters will tend to be broken. Why? see below. > > Exp. Note: quoting Rebenstein here: > "One striking difference among laser printers is that some write a > black image on the drum during formation of the image, and others > write the white part of the image. Because of the way the toner is > attaracted to the resulting charged image, one image will be bolder This is close, but not *exactly* what happens. Here is what happens I have been thinking about writing a PS program to demonstrate this, but haven't. 1. Lasers use a round laser beam to write the graphics to the page. If you try to clip the beam to a square beam you get fringed effect around the spots. There are 2 ways to effect the drum. A short course in laser printers: The drum in a laser has a photo sensitive layer. This layer acts like a capacitor. The drum passes a highvoltage corona wire, from when comes the smell of ozone. The corona charges the surface of the drum. Depending on the type of photo surface, and the polarity of the corona, it applies either a + or - charge. That part has nothing to do with write black or write white. The laserbeam hitting the drum, causes the charge to leak through the photo sensitive layer, and disapate into the metal drum. The result, is a series of regions on the drum with either a + or - charge depending on the polarity. toner is formulated for either a + or - charge. The toner carries a charge that is opposite to the drum charge WHERE THE BLACK IS TO GO. Now, if it is a white writer, the beam will neutralize the charge to the same as the toner. If it is a white writer, the beam will cause the toner to NOT be attracted to the drum. If it is a black writer the beam will cause the toner to BE attracted every where it hits. The charged drum with the latent image, moves through the toner. There are 2 types of toners. Mono-component, and dual component. Canon uses mono component toner. This means that the toner particles are magnetic. A Dual component system on the other hand, has a "carrier" called a "developer" that is magnetic. The toner is static sensitive, and sticks to the sharps points of the carrier. The carrier in turn sticks to the magnet and forms sort of a brush. This lightly touches the drum. The mono component toner sticks to the magnet forming a brush as well, but it does not touch the drum. It merely jumps the gap to the drum. It has the distinct advantage of being a simpler system, but the disadvantage of not covering as well. The drum with the latent image, then continues rolling, and comes to a point when it is in contact with the paper. On the other side of the th paper, is another corona wire that has a voltage on it that is opposite of the charge holding the toner to the drum. The toner leaves the drum, adheres to the paper and is melted into the paper under heat and pressure. Now: Since we are working conceptually with square pixels, and we have a round laser beam, we have a choice to make. How to fit a round peg in a square hole. There are 2 choices. We can fan the beam out such that it just completely compases our 300th inch pixel. This means that the pixel is ENTIRELY within the beam, and the beam extends outside of the sides of the pixel. We can focus the beam so that it is completly contained WITHIN the 300th inch square pixel, or we can go in between, and make it slightly bulge out the 4 sides, but stay inside the corners. Now, consider a write BLACK engine. If we choose the first method, we get a line a bit bigger than 1/300th of an inch. If we choose the second method we will get LARGE white diamonds between ajacent rows of dots. If we pick the third method, we will get SMALL diamonds. IF we design the toner correctly, the charging system correctly, and the laser power correctly, we can arrange things such that the charge is just a tad bit larger than the pixel, such that the 4 pixels surrounding the diamond, will bleed enough charge to allow the toner to cover the diamond. The original laser writers (CX engine) attempted this, but was not designed quite right, and thus you had VERY fine rows of white diamonds in the black areas, resulting in washed out blacks. The SX engines solved the problem with diffrent toner, particle size, chargin system, and spot size. It should be immediatly apparent that for a WHITE writer, it just would not do to have rows of tiny black diamonds all over your white areas, so the white writers HAVE to use the first technique. Now, the simplest way to visualize this, is to get some graph paper, and draw a line of dots that COMPLETELY enclose each square. SKIP a line (this will be our black line) and draw another line. Then mark out a 2x2 square and draw circles completely around the borders. Go to the upper left and lower right corners of teh 2x2 square and draw a style 1 dot around each. Now set back and look. You will notice that the single black line is NO LONGER 1/300th of an inch. It has little bitty nibbles along the edges. You will also note that the 2 black pixels in our 2x2 gray shade box are smaller than 1/300th of an inch. This is why, on fine details such as 1 pixel lines, and the tops of small o's (which get down to 1 pixel) that often times the charge is not enough to make the toner stick, thus resulting in broken lines, and missing pixels. However, the BLACKS ARE BLACK (there are no white or black diamonds, the drum was never touched by the laser here). To sum things up, White writers are bad on fine gray shades, and small letters, but good on solid blacks, so If you are say, making silkscreen masters, the White writer would be the printer of choice, the resolution of the silk is less than 1/300th of an inch, and you need the blocking power of solid solid black. On the other hand, for doing fine typesetting, etc, the black writer is superior because the pixels don't drop out. Now, in some cases, attempts are made to correct the white writer problem, by always doing 2 rows of pixes, never one row. I know that this probably should be over in comp.lasers, since it has no real bearing on postscript, except for the output, but it sure helped me sell a lot of CANON black writers against Ricoh white writers. Cheers Woody
newbery@rata.vuw.ac.nz (Michael Newbery) (08/09/90)
In article <1468@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >1. Lasers use a round laser beam to write the graphics to the page. If you >try to clip the beam to a square beam you get fringed effect around the spots. While we are being picky, the spot is actually elliptical in most printers, moreso in the LED lasers (Canon) than the HeNe. If you are using 1000dpi or up the differences are not nearly so important and you can use the 'simpler' system, i.e. write white, without any loss of resolution. -- Michael Newbery<newbery@rata.vuw.ac.nz> "MVS - well yes, it's big - but it IS slow!"
poynton@vector.Eng.Sun.COM (Charles A. Poynton) (08/14/90)
This message was automatically generated by a filter that detected the phrase "square pixel" in UseNet news message <1468@chinacat.Unicom.COM> writen by woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) on 8 Aug 90 02:49:46 GMT. "Square pixel" has acquired a colloquially meaning, namely, that samples are equally speced horizontallly and vertically (e.g. 300 dots per inch, both directions). A more precise term is "unity sample aspect ratio". This widely-accepted interpretation has no relationship to the distribution of energy associated with one pixel, properly known as point-spread function. Someone is Boston told me he once tried to build a CRT monitor whose electron beam was square in cross section; predictably the pictures looked terrible. A precise term for this would be "box-shaped point spread function", in contrast to the more usual "gaussian point spread function" of a CRT or (I suppose) cylindrical PSF of a laserwriter. C.
hammen@ddsw1.MCS.COM (Robert Hammen) (08/14/90)
In article <9724@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >> Does this mean that the fonts will be down loaded as the curve equations, >> and a postscript program will be sent along to convert the equations into >> bitmaps? Or are the bitmaps going to be generated on the Mac and then >> downloaded to the printer/typesetter (expensive, especially on something >> like a 1200 dpi device)? >My understanding (I'm not a gnarly printing dude, so don't quote me on >this!) is that the curve equations will be downloaded to the printer along >with machine code to do the rendering. So the printer will still do the >rendering, but will do it as fast as its processor can. From our "experiments" with System 7.0, this is exactly what seems to be the case. When a TrueType font is called for the first time, a message pops up in the status window saying "Downloading font scaling code." This is the better way to do things (who would want to wait while your Mac generated bitmaps at 3386 dpi and shipped them down the network to your imagesetter?). We'll just have to see how fast this font-scaling code is compared to the PostScript font rasterizer. Another question is compatibility. We've got a bunch of PostScript clones in-house for testing purposes, and they both failed to work with the font scaling code (and the more ironic thing is that one of them uses the Bauer PS clone that's the basis for Microsoft's TrueImage!). It's very important for this code to work on non-680x0-based controllers, now that Adobe has introduced many of these. ///////////////////////////////////////////////////////////////////////////// / Robert Hammen | Technical Editor | Personal Publishing Magazine / / 191 S. Gary Ave. | Carol Stream, IL 60188 | (708) 462-2414 / / hammen@ddsw1.mcs.com | 76702.1135@compuserve.com | GEnie: R.HAMMEN / /////////////////////////////////////////////////////////////////////////////
cmf@obie.cis.pitt.edu (Carl M. Fongheiser) (08/15/90)
In article <1990Aug14.124450.7262@ddsw1.MCS.COM> hammen@ddsw1.MCS.COM (Robert Hammen) writes: >Another question is compatibility. We've got a bunch of PostScript clones >in-house for testing purposes, and they both failed to work with the font >scaling code (and the more ironic thing is that one of them uses the Bauer >PS clone that's the basis for Microsoft's TrueImage!). It's very important >for this code to work on non-680x0-based controllers, now that Adobe has >introduced many of these. Yeah, and non-680x0 controllers have been out for years. The DEC PrintServer 40 is based on a MicroVAX, and it's been out for around 3 years now. Carl Fongheiser cmf@unix.cis.pitt.edu
hammen@ddsw1.MCS.COM (Robert Hammen) (09/08/90)
If you print TrueType fonts to a PostScript printer with System 7, you see the message "Downloading font scaling code" flash by in the printer status window. Previous discussions on the net have centered on whether or not this code is being sent down as 68000-based machine code or not. Two interesting results I found when attempting to find out just what was going on. 1) I printed a test to a Qume CrystalPrint Publisher II. The printer uses a PostScript clone, and uses a Weitek RISC chip for its controller. It took 45 minutes to an hour for it to generate a waterfall that an NTX printed in about five minutes. 2) I printed a test to an Abaton LaserScript. This printer uses the Bauer PostScript clone that is the basis of Microsoft's TrueImage PDL. The page would not print because the language currently doesn't support the eexec operator. 3) I printed a test to a NewGen Turbo/PS 480. This RIPS PS clone uses an Intel RISC chip for a processor. The page printed in about 10 minutes. The next two tests I will run will be on a software-based PS interpreter (the Hyphen clone RIP) and a Linotronic 300/RIP 4. ///////////////////////////////////////////////////////////////////////////// / Robert Hammen | Macintosh enthusiast & publishing guru, looking for a job / / hammen@ddsw1.mcs.com | 70701.2104@compuserve.com | GEnie: R.HAMMEN / /////////////////////////////////////////////////////////////////////////////