Xref: utzoo comp.fonts:1388 comp.lang.postscript:5702 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!adobe!heaven!glenn From: glenn@heaven.woodside.ca.us (Glenn Reid) Newsgroups: comp.fonts,comp.lang.postscript Subject: Re: PostScript vs TrueType? Message-ID: <237@heaven.woodside.ca.us> Date: 6 Aug 90 20:15:48 GMT References: <1100.26af57d3@waikato.ac.nz> <1990Jul26.135834.9874@tsa.co.uk> <862@grenada.UUCP> <9583@goofy.Apple.COM> <3880@bwdls58.UUCP> Reply-To: glenn@heaven.woodside.ca.us (Glenn Reid) Followup-To: comp.fonts Organization: RightBrain Software, Woodside CA Lines: 70 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