ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (07/26/90)
The Spring 1990 issue of MacTech Quarterly had an interesting comparison of the relative virtues of the font handling schemes in PostScript versus Apple's TrueType system. The funny thing was, the author of the article, Bill Woodruff, is a self-confessed PostScript fan[atic?]--to the extent that the editor promised a future article promoting the opposing viewpoint--but it didn't read that way to me at all. I should admit up front that I'm not familiar with Adobe's hinting scheme--I *still* haven't got hold of a copy of the Type 1 Font Format book--but I do have a copy of the TrueType documentation. Anyway, one of the points of the article was that the hints in Adobe PostScript fonts merely identify important features of each character outline, and leave it to the interpreter (and imaging engine) to perform the appropriate transformations to preserve legibility at low resolutions. This is described as a "high level" approach, as opposed to the "assembly language" scheme of TrueType, which embeds explicit tweaking instructions in the outline description. The article goes on to say that Adobe has been steadily improving its hinting software since 1984. To take advantage of the improvements, you don't need to upgrade all your existing fonts--just your PostScript implementation. This is contrasted with TrueType, where you'd need new versions of your fonts, since these need to have the hinting algorithms built-in. Does anybody else spot what's wrong with this? It seems to me that most current implementations of PostScript takes the form of ROMs inside a printer or typesetter. Upgrading such a beast is far from a straightforward, low-cost job, judging from past experience. By contrast, for people with lots of fonts, most of those will be on disk rather than in a ROM, so upgrading them will be, at worst, a matter of returning the old original disks together with the upgrade charge. In these days of non-copy-protected software, you can continue working with copies of the originals until the new versions arrive. Some vendors don't even want the old disks back--the fact that they've got a record of you as a registered user is enough for them. Of course, for those proud owners of NeXT machines with Display PostScript interpreters included in the system software, things may work rather differently... What do other people think of the relative advantages of PostScript versus TrueType? There were a few other points mentioned in the article, but they didn't strike me as being as crucial as the above one. For example, the rarity of font designers, and the headaches they have to go through to support yet another font format. I thought Apple designed TrueType to make it as easy as possible for everybody else in the world to convert their fonts to this format. Comments, anyone? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
domo@tsa.co.uk (Dominic Dunlop) (07/26/90)
[Loadsa postings on the net from NZ and Australia recently. Hi folks. What happened? Anyways...] In article <1100.26af57d3@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >The Spring 1990 issue of MacTech Quarterly had an interesting comparison >of the relative virtues of the font handling schemes in PostScript versus >Apple's TrueType system. >Anyway, one of the points of the article was that the hints in Adobe >PostScript fonts merely identify important features of each character >outline, and leave it to the interpreter (and imaging engine) to perform >the appropriate transformations to preserve legibility at low >resolutions. This is described as a "high level" approach, as >opposed to the "assembly language" scheme of TrueType, which embeds >explicit tweaking instructions in the outline description. >Comments, anyone? OK. Why is a high-level approach almost always better than a low-level approach? Because a high-level approach can better accommodate new technologies simply by labelling the low-level aspects of any technology, whether new or old, as somebody else's problem. Suppose I have one of HP's spiffy new printers with Resolution Enhancement Technology. The low-level hints in a TrueType font are likely to be aimed at making ``dot/no dot'' decisions, and so cannot take advantage of an engine which can shrink dots and slightly vary their horizontal placement. High-level hints in PostScript fonts leave details of implementation to the interpreter, and a suitably clever interpreter (if Adobe or a clone maker should come up with one -- and that's quite a big if) could correctly drive RET, and so produce slightly better-looking results than TrueType. I'd guess that similar considerations would apply to anti-aliasing of character edges on grey- scale monitors by using shades of grey rather than straight black-white transitions. A PostScript RIP behind the screen should (assuming enough MIPs and memory to cook up fonts at a bearable speed) be able to do this. Would TrueType? Possibly talk of MIPs hints (pun intended) at Apple's and Microsoft's reason for going low-level. Most of the installed base of Macs and PCs has little power to spare for working out how to respond to a hint: better and cheaper to tell the poor little machine exactly what to do -- even at the cost of future problems or sub-optimal performance. Course, I could be wrong. TrueType hints may do all this. Comments anyone? -- Dominic Dunlop
capslock@wet.UUCP (Allen Crider) (07/28/90)
In article <1100.26af57d3@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > > >Does anybody else spot what's wrong with this? It seems to me that >most current implementations of PostScript takes the form of ROMs >inside a printer or typesetter. Yes I know what you mean. The important upgrades in Adobe's interpreters is more CPU horsepower. I have gone through all Linotype's RIPS from 'one' to the RIP IV. I'm waiting for Linotypes emerald rip. What I'm saying is CPU power is increasing as fast as the upgrades to Adobe's interpreters. >...By contrast, >for people with lots of fonts, most of those will be on disk rather >than in a ROM, so upgrading them will be, at worst, a matter of >returning the old original disks together with the upgrade charge. Extremely expensive for vendor and user alike. Software vendors want to be sure you own a legit copy of their fonts, so they have large databases and people to use them. They have to mail you a letter announcing the amazing new upgrade. They have to make new disks and documention. I just got an upgrade for PageMaker 4.0 on the Mac. $150. >Of course, for those proud owners of NeXT machines with Display >PostScript interpreters included in the system software, things >may work rather differently... <sigh> I'm looking at 18 point Courier as I type this. It is a bitmapped font. Display PostScript needs anti-aliasing. >What do other people think of the relative advantages of PostScript >versus TrueType? TrueType is not a complete page description language. TrueType does not know how to image a circle, or halftone a 24-bit image. TrueType depends on the host for its CPU, memory, operating system and disk storage. Besides, why buy another font library? TrueType doesn't offer enough of an advantage for me to consider switching. TrueType has been delayed long enough for me to comfortably call it VAPORWARE. I cannot use it now unless I find an Alpha System 7. I guess this is because Apple wants to be sure it works on a five-year-old Mac. Apple has lost years of their advantage vis-a-vis MS-DOS by going ahead with this project. I suspect they could have bought Adobe Systems for the true cost of TrueType. I'm glad they didn't.
chrisg@microsoft.UUCP (Chris GUZAK) (07/30/90)
In article <1990Jul26.135834.9874@tsa.co.uk> domo@tsa.co.uk (Dominic Dunlop) writes: >Possibly talk of MIPs hints (pun intended) at Apple's and Microsoft's >reason for going low-level. Most of the installed base of Macs and PCs has >little power to spare for working out how to respond to a hint: better and >cheaper to tell the poor little machine exactly what to do -- even at the >cost of future problems or sub-optimal performance. ummm... my 20MHz 386 can churn out more mips that the 68k in my printer. When it comes to putting power where it can be used, I'd rather pay for it in my desktop machine (where it is much cheaper) than in my printer. I'd also like my font engine there as well, that way I get nice stuff on the screen as well as on paper. >Dominic Dunlop Chris Guzak
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (07/30/90)
In <1393@wet.UUCP>, capslock@wet.UUCP (Allen Crider) says "TrueType is not a complete page description language." True, but not the whole truth. TrueType is just one component of a strategy which includes QuickDraw as the basic graphics engine, and the Macintosh Print Manager to supply the complete page description. Granted the strategy isn't complete yet: at last year's Australian Apple Developer's Conference I saw a preview--for a few minutes--of the Layout Manager. This builds on two existing components of the Mac system: the Script Manager, which handles the peculiarities of non-Roman versus Roman writing systems (including both keyboard input and font display), and TextEdit, which is a set of tools for managing pieces of editable text (and which supports non-Roman scripts via the Script Manager). To these, it adds extensive layout functions, including automatic kerning, handling of contextual forms, and vertical layout of, say, Chinese text. The demo used the Zapf Chancery font, including a full range of intricate swashes and ligatures which automatically broke and rejoined to the appropriate contextual forms as the presenter was typing and editing the text. Made the standard PostScript version of Zapf Chancery look pretty weak, I can tell you. What a pity the Layout Manager is one of those pieces that isn't going to make the initial System 7.0 release... I guess the point is, that PostScript cannot be made to fit easily into a system like this--I agree it's very powerful in its own way (I don't know much about the Display PostScript extensions), but its mindset is so different from so many of the existing pieces of the Macintosh system, that it could only partially replace some of them, and interface poorly to the rest. It would only make sense if you were building an interactive, WYSIWYG, multi-script, graphical environment from scratch, so you could fit your additions around Display PostScript. The same thing is probably true of the OS/2 environment, which would be why Microsoft is licensing TrueType for use there. Apple losing "years of their advantage vis-a-vis MS-DOS"? I don't think so. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
roger@grenada.UUCP (Roger Corman) (08/01/90)
According to Adobe, low level hinting (hinting code in the fonts) was tried
early in the company's history. They abandoned it and chose high-level
hinting (hinting code in the rendering engine) for two main reasons.
The first was that the amount of time and expense required to create each
font was great--it wad have taken an unacceptable amount of time to develop
a decent library of fonts. The code in each font had to be modified
and debugged. Their experiences lead one to suspect that it will take
awhile for a large number of TrueType fonts to become available. True,
it is probably easy to convert other font outline formats to this format,
but not so easy to create *quality* fonts with low level hinting.
The second reason had to do with the future of the font technology. In
order to get better rendering results, the low-level hinting
method probably would require upgrading the fonts themselves (where the
rendering hints are). With Adobe's approach, improved rendering
engines can get better results with the same old font libraries. Printers
being mechanical, and tied to microprocessor technology, are likely to
be upgraded every few years, with newer and better rendering engines.
Customers expect this. Customers don't expect to have to buy new fonts.
The high-level hinting approach appears to give Adobe fonts more long term
value.
I ought to add what I consider another reason that high-level hinting is
good for Adobe. Now that Adobe has, under market pressure, opened up their
font formats such that the information in them can be readily understood,
the key rendering technology is still in a black box (PostScript and ATM
rendering engines).
Which type of hinting is better for you and me? Whichever allows us
the most fonts of the best quality for the lowest price (obviously). I
personally expect it will be *years* (if ever) before the number of quality
fonts now available in Adobe format are available in TrueType format.
Roger Corman
Island Graphics
Santa Rosa, CA
(707)523-4465
{uunet,ucbcad,sun}!island!rogerbarnett@grymoire.crd.ge.com (Bruce Barnett) (08/03/90)
In article <862@grenada.UUCP> roger@grenada.UUCP (Roger Corman) writes: >The second reason had to do with the future of the font technology. In >order to get better rendering results, the low-level hinting >method probably would require upgrading the fonts themselves (where the >rendering hints are). With Adobe's approach, improved rendering >engines can get better results with the same old font libraries. Printers >being mechanical, and tied to microprocessor technology, are likely to >be upgraded every few years, with newer and better rendering engines. >Customers expect this. Customers don't expect to have to buy new fonts. >The high-level hinting approach appears to give Adobe fonts more long term >value. A good example of this is the new HP LaserJet III, which is 300 DPI, but uses variable size dots to get effectively 600 DPI. I doubt TrueType will look as nice as PostScript fonts on this device. Also - Font designers say it takes a year to design a decent font. I don't know how long it would take to convert it into the proper data for PostScript or TrueType, but I doubt it's trivial. How can you design low level hints in the fonts, when the output can be on 72, 200, 300, 600, 1200, or 2400 DPI machines? Do you only load the "hints" for the output devices you will drive? Getting a 10 point font to look decent on a 72 dpi screen is easy. Getting a 5 point font to look good on paper is something else. Given a screen that has QuickDraw/TrueType and a PostScript printer and typesetter, what will people do to get good output? Will they have to buy a QuickType (that's QuickDraw and TrueType) Laser Printer and Typesetter? (Bad answer - why buy more equipment?) Will QuickType be converted into PostScript? (Another Bad Answer - it won't be WYSIWYG) Will TrueType fonts be downloaded into the typesetter? (Another Bad Answer - I doubt TrueType will look as good as PostScript at 1270 or 2400 dpi). -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
r91400@memqa.uucp (Michael C. Grant) (08/03/90)
In article <BARNETT.90Aug2171900@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > How can you design low level hints in the fonts, when the output > can be on 72, 200, 300, 600, 1200, or 2400 DPI machines? Do you only > load the "hints" for the output devices you will drive? Hints aren't designed to be used on the virtual page, they are designed to be used on the physical page. What that gibberish means is that hints that are used for 6pt letters on a 300dpi printer would be equivalently used on 3pt letters on a 600dpi printer. The hints work with machine pixels, not point sizes. Needless to say, 2540dpi printers don't need many hints, eh? Michael C. Grant
chewy@apple.com (Paul Snively) (08/04/90)
In article <BARNETT.90Aug2171900@grymoire.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > A good example of this is the new HP LaserJet III, which is 300 DPI, > but uses variable size dots to get effectively 600 DPI. > > I doubt TrueType will look as nice as PostScript fonts on this device. This is indeed probably a good example of where "low-level" hints don't work too well. > Also - Font designers say it takes a year to design a decent font. > I don't know how long it would take to convert it into the proper data > for PostScript or TrueType, but I doubt it's trivial. It probably isn't, but on the other hand, the font-studly developers will probably have some very sophisticated tools for constructing/modifying/converting etc. fonts between the formats. (Let's put it this way: if they don't, we're in a world of hurt.) > How can you design low level hints in the fonts, when the output > can be on 72, 200, 300, 600, 1200, or 2400 DPI machines? Do you only > load the "hints" for the output devices you will drive? Don't let the term "low-level" fool you. TrueType fonts are still mathematical descriptions of curves, and this applies to the hints as well. They're still resolution independent. > Given a screen that has QuickDraw/TrueType and a PostScript printer > and typesetter, what will people do to get good output? If they use PostScript fonts, the PostScript engine will render them; if they use TrueType fonts, the new driver will download the TrueType rendering code and that will be used. Either way, it still works. > Will they have to buy a QuickType (that's QuickDraw and TrueType) > Laser Printer and Typesetter? (Bad answer - why buy more equipment?) This won't be necessary. > Will QuickType be converted into PostScript? > (Another Bad Answer - it won't be WYSIWYG) Right again, which is one reason it's not being done. > Will TrueType fonts be downloaded into the typesetter? > (Another Bad Answer - I doubt TrueType will look as good > as PostScript at 1270 or 2400 dpi). Well, that remains to be seen, doesn't it? :-) __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
macman@wpi.wpi.edu (Chris Silverberg) (08/04/90)
In article <862@grenada.UUCP> roger@grenada.uu.net (Roger Corman) writes: >Which type of hinting is better for you and me? Whichever allows us >the most fonts of the best quality for the lowest price (obviously). I >personally expect it will be *years* (if ever) before the number of quality >fonts now available in Adobe format are available in TrueType format. A couple years perhaps. But it will happen. Bitstream has already committed itself to fully supporting the TrueType format, and other companies are sure to follow. ._._._._._._._._._._._._._._._._._._.._._._._._._._._._._._._._._._._._._._. Chris Silverberg AOL: Silverberg Worcester Polytechnic Institute GEnie: C.Silverberg INTERNET: macman@wpi.wpi.edu SYSOP: Main Street U.S.A. BBS FIDONET: 322/575.1 508.832.7725 (1200/2400)
mneerach@b.inf.ethz.ch (Matthias Ulrich Neeracher) (08/06/90)
In article <BARNETT.90Aug2171900@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >Getting a 10 point font to look decent on a 72 dpi screen is easy. >Getting a 5 point font to look good on paper is something else. Assuming we talk about a 300 dpi or higher resolution printer, this should be *much* easier than getting a 10 point font on screen. 5 points on a laserwriter correspond to about a 20 point screen font. Or have I missed something ? Matthias ----- Matthias Neeracher mneerach@c.inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson
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 |
barnett@grymoire.crd.ge.com (Bruce Barnett) (08/07/90)
In article <174@neptune.inf.ethz.ch> mneerach@b.inf.ethz.ch (Matthias Ulrich Neeracher) writes: >>Getting a 10 point font to look decent on a 72 dpi screen is easy. >>Getting a 5 point font to look good on paper is something else. > Assuming we talk about a 300 dpi or higher resolution printer, this should be >*much* easier than getting a 10 point font on screen. 5 points on a laserwriter >correspond to about a 20 point screen font. Or have I missed something ? You haven't missed anything. I was considering the case of Apple and TrueType: They already had a 10 pt. font for each of their fonts, and it would just be a task of making sure the hints would generate the fonts they already used. But I think I am confusing TrueType, PostScript/ATM and Folio. I believe Folio has a bitmap font it uses for small, common screen fonts. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
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
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/07/90)
In <3880@bwdls58.UUCP>, hwt@.bnr.ca (Henry Troup) asks "How can anyone design low level hints without knowing if the the device is write-white or write-black?" I just want to point out that, according to my documentation, several of the TrueType operators include a "distance type for engine characteristic compensation". This is a code which indicates whether the distance value associated with that operation is "black", "white" or "grey", but the actual details of how to compensate for this are left to the implementation. See, TrueType isn't *that* low level after all... Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
kevina@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."
cory@three.MV.COM (Cory Kempf) (08/09/90)
chewy@apple.com (Paul Snively) writes: >If they use PostScript fonts, the PostScript engine will render them; if >they use TrueType fonts, the new driver will download the TrueType >rendering code and that will be used. Either way, it still works. 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)? +C -- Cory Kempf I do speak for the company (sometimes). The Enigami Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
chewy@apple.com (Paul Snively) (08/14/90)
In article <406@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: > chewy@apple.com (Paul Snively) writes: > > >If they use PostScript fonts, the PostScript engine will render them; if > >they use TrueType fonts, the new driver will download the TrueType > >rendering code and that will be used. Either way, it still works. > > 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. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
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 / /////////////////////////////////////////////////////////////////////////////
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/14/90)
An unnamed source [:-)] at Apple writes: >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. Uck. Uck! UCK! UUUUUCCCCCKKKKK!!!!! More d**n controller-dependent junk. I guess my NeXT printer won't be rendering "TrueType" fonts. Nor will any other PostScript printer that uses a different controller (such as the ones that use RISC chips). Adobe ought to be pleased with this decision; their PostScript driver is looking better and better. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
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
chewy@apple.com (Paul Snively) (08/16/90)
In article <1990Aug14.142056.720@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > >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. > > Uck. Uck! UCK! UUUUUCCCCCKKKKK!!!!! More d**n controller-dependent junk. > I guess my NeXT printer won't be rendering "TrueType" fonts. Nor will any > other PostScript printer that uses a different controller (such as the > ones that use RISC chips). Well, all this really means is that different devices will probably require different drivers. What a shock--this is already the case. > Adobe ought to be pleased with this decision; their PostScript driver is > looking better and better. I think their new PostScript driver sounds pretty cool, too. Keep in mind that it's not like the use of alternative font-rendering mechanisms is mutually exclusive--folks will be able to choose whatever best suits their purposes. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/22/90)
What sort of support will Level II PostScript have for contextual forms?
As I've tried to point out before, this is important not only for non-Roman
writing systems, but for some Roman fonts as well.
* A string of text shouldn't need to contain different codes to represent
different contextual forms of the same character. Instead, this should
be resolved at the time the text is drawn. This keeps things simple for
the application.
* Is there a Level II PostScript function for drawing a *part* of a
string *in context*? That is, you give it a string, but indicate that
you only want a part of it drawn. The reason for passing the whole
string is so that the drawing code can decide on the correct contextual
forms to use.
The reason for only wanting to draw part of the string is interactive
WYSIWYG editing: this lets you redraw only the part of the text that
has changed (saves time and avoids flicker), while displaying the
correct contextual forms at all times.
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
My other signature is a Porsche.cory@three.mv.com (Cory Kempf) (08/22/90)
chewy@apple.com (Paul Snively) writes: >In article <406@three.MV.COM> cory@three.MV.COM (Cory Kempf) 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. MACHINE CODE???? This sounds like a solution that will only work with Apple's Laserwriter (or other 68k based systems). What about all of the non-Apple postscript devices? What about the non-68k based postscript engines? Tell me it isn't so!!! (actually, at the moment, I am kinda glad that I didn't buy a postscript printer) +C -- Cory Kempf I do speak for the company (sometimes). The EnigamI Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
clarson@ux.acs.umn.edu (Chaz Larson) (08/24/90)
In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: >chewy@apple.com (Paul Snively) writes: >>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. > >MACHINE CODE???? This sounds like a solution that will only work with >Apple's Laserwriter (or other 68k based systems). What about all of >the non-Apple postscript devices? What about the non-68k based postscript >engines? I would presume that these non-68K-based PostScript engines have machine code of their own, which would be generated by the drivers which would be written for these printers. This seems like it would be faster than sending PostScript to be interpreted by the printer. In some fictional printer controlled by an 80486, instead of a PostScript program being interpreted by a PostScript interpreter running on the 80486, you'd have curve equations being rendered by 80486 machine code. Seems like a good idea to me, but then I'm not a gnarly printing dude, either. <chaz> -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Does Captain Kirk Exist?" Chinese AI Experts Offer New Evidence." - spew clarson@ux.acs.umn.edu AOL:Crowbone
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/24/90)
In article <2120@ux.acs.umn.edu>, clarson@ux.acs.umn.edu (Chaz Larson) writes: > In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: > >chewy@apple.com (Paul Snively) writes: > > I would presume that these non-68K-based PostScript engines have machine > by the printer. In some fictional printer controlled by an 80486, instead of > a PostScript program being interpreted by a PostScript interpreter running on > the 80486, you'd have curve equations being rendered by 80486 machine code. > Well, I think that the bezier curve stuff in Postscript (as well as the rest of the primatives) are really 'C' programs that are compiled into 68000 or whatever code. I don't think that there would be much diffrence once the parameters are set up for the function. It does appear that the Adobe interpreter uses sort of a PCODE mechanism, or at least a compact tokenization. I have dumped some of the built in operators out, especially things like dictionaries, and there does appear to be a token $82 that marks some sort of pseudo opcode. I have not dug to deeply, but once you have gotten, say the parameters to your curve the actual point generation is not handled interpretively. Cheers Woody
jtc@motcad.portal.com (J.T. Conklin) (08/24/90)
In article <2120@ux.acs.umn.edu> clarson@ux.acs.umn.edu (Chaz Larson) writes: >In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: >>MACHINE CODE???? This sounds like a solution that will only work with >>Apple's Laserwriter (or other 68k based systems). What about all of >>the non-Apple postscript devices? What about the non-68k based postscript >>engines? > >I would presume that these non-68K-based PostScript engines have machine >code of their own, which would be generated by the drivers which would >be written for these printers. The whole point of PostScript is that there should be only one print driver for all PostScript devices, regardless of manufacture or implementation. Including machine code defeats this. >This seems like it would be faster than sending PostScript to be interpreted >by the printer. In some fictional printer controlled by an 80486, instead of >a PostScript program being interpreted by a PostScript interpreter running on >the 80486, you'd have curve equations being rendered by 80486 machine code. Doubtless it would be faster, but just who is going to write the different 88k, R3000, 'x86, and T800 transputer implementations? Is someone going to give me the source, so I can include it in my software postscript interpreter? >Seems like a good idea to me, but then I'm not a gnarly printing dude, either. In my opinion, the downloaded machine code should only be used if the manufacturer needs to fix a bug in their PostScript implementation and doesn't want to do a general rom upgrade yet. --jtc -- J.T. Conklin UniFax Communications, Inc. CADnet Inc, San Ramon California jtc@motcad.portal.com, ...!portal!motcad!jtc
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/24/90)
In <1990Aug24.012301.23588@motcad.portal.com>, jtc@motcad.portal.com (J.T. Conklin) says "The whole point of PostScript is that there should be only one print driver for all PostScript devices, regardless of manufacture or implementation." I agree this was one of the original aims. So you tell me: has PostScript lived up to its design goals? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
jaz@icd.ab.com (Jack A. Zucker) (08/24/90)
This whole thing bothers me. People should not be making big bucks off programming languages, page description languages, etc. I hope GNU is listening. How about putting more effort into Ghostscript ?! I resent it when I have to pay Adobe $1000.00 to get Postscript in my printer, then I have to pay them again to get the matching screen fonts. I'm sure the situation won't be much different with Microsoft or Apple. Hurry GNU, Hurry.... -jaz
dhoyt@vx.acs.umn.edu (08/25/90)
In article <1331.26d577e2@waikato.ac.nz>, > ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes... >>In <1990Aug24.012301.23588@motcad.portal.com>, >> jtc@motcad.portal.com (J.T. Conklin) >>says "The whole point of PostScript is that there should be only one print >>driver for all PostScript devices, regardless of manufacture or >>implementation." > >I agree this was one of the original aims. So you tell me: has PostScript >lived up to its design goals? Yes. I can create a postscript file in Pagemaker, proof it on a Laserwriter then send the same file to a printer to print on a Linotronic or Agfa typesetter with only a small chance of problems. I don't care what their rasteriser is and they don't care about mine. Downloading 68000 code seems very stupid to me. But I don't really care what TrueType does. I'll never use it. I've got my fonts, I've got my ATM, I've got real Postscript printers in house and at the printers. The pros all use postscript. Where does that leave Royal & TrueType? david | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet
rcd@ico.isc.com (Dick Dunn) (08/25/90)
jaz@icd.ab.com (Jack A. Zucker) writes, inter alia: > I resent it when I have to pay Adobe $1000.00 to get Postscript in > my printer... What's the source of this $1000 story? I've heard it before, but I've never been able to make sense of it. Current market price for Adobe's PostScript add-on cartridge for the LaserJet II is $300--and that's a physical gadget, not just a license. Seems like a pretty good buy to me. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...I'm not cynical - just experienced.
chewy@apple.com (Paul Snively) (08/25/90)
In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: > >In article <406@three.MV.COM> cory@three.MV.COM (Cory Kempf) 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. > > MACHINE CODE???? This sounds like a solution that will only work with > Apple's Laserwriter (or other 68k based systems). What about all of > the non-Apple postscript devices? What about the non-68k based postscript > engines? Geez, relax, will ya? What this means is that different devices will probably require a different driver (gee, what a shock. That already seems to be true). Or maybe the folks in printing land will see if the device has a 680x0 and will use machine code if so, otherwise downloading rendering code in PostScript. The truth is that _I don't know_ if any of this is correct; this is what I seem to remember from the cobwebs. Printing ain't my job, a fact for which I thank God every day. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
jeffe@eniac.seas.upenn.edu (George Jefferson ) (08/25/90)
Adobe liscense + Apple markup - competetion = ~$1000. It looks to me like Adobe/HP are trying to drive Apple out of the printer business before (or in spite of) the introduction of TrueType
glenn@heaven.woodside.ca.us (Glenn Reid) (08/26/90)
In article <9931@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >> MACHINE CODE???? This sounds like a solution that will only work with >> Apple's Laserwriter (or other 68k based systems). What about all of >> the non-Apple postscript devices? What about the non-68k based > >Geez, relax, will ya? What this means is that different devices will >probably require a different driver (gee, what a shock. That already >seems to be true). The Macintosh already downloads machine code, which is also one of the reasons that Mac-generated PostScript files run into trouble on other brands of printers. There is "bit-smoothing" code in eexec form buried in LaserPrep (or was the last time I looked). Luckily, it checks to see if the product is an Apple LaserWriter before executing it. Unluckily, in the process of NOT executing it, it often NOT executes the rest of your job too. Adobe's driver should fix this, I would imagine. In the meantime it continues to be a first-class headache for everyone trying to use Mac-generated PostScript. In fact, I'm sure it's one of the most frequently asked questions in this newsgroup. And no, different devices really shouldn't require a different driver, except where printer-specific features like trays are concerned, and even that should go away with PostScript Level II. The one thing that is truly device-independent in PostScript is the fonts. There are something like 90 Adobe-licensed PostScript devices out in the world, I think. All of them work with the same font library, from IBM Electro-compositors hooked up to IBM 370 mainframes right through to Display PostScript on a NeXT machine. I think it would be very bad if my fonts were written in (or rendered by) machine code. I don't think the instruction sets on the IBM 370 and the 68030 are very similar. What Apple wants to do can be done, of course, but it will require re-building a lot of what already exists. People who are serious PostScript users require color printers, film recorders, typesetters, large plotters, high-speed printers, duplex printers, envelopes, stapling, and endless other things. Unless Apple manages to license technology, get products built, and keep the system end of things tied up neatly, it is likely to be messy, and I can't believe they could ever close the gap on the products already available in the world. Need a color PostScript printer? There are at least five or six of them to choose from. Need 11x17 output? 600dpi on plain paper? full-color slides? They're all shipping. And your fonts work. Maybe three years ago it might have been all right to build just a low-cost, low-speed laser printer and complement it with a high-resolution phototypesetter, but that's just the tip of the iceberg in 1990. Anyway, we'll wait and see. A brand new font technology will present many major software and hardware issues before becoming successful. These are just opinions. I speak for no one, and probably would be better off just not speaking, but what the heck, it's Saturday. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
jaz@icd.ab.com (Jack A. Zucker) (08/27/90)
In article <1990Aug24.213407.26653@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > What's the source of this $1000 story? I've heard it before, but I've > never been able to make sense of it. > > Current market price for Adobe's PostScript add-on cartridge for the > LaserJet II is $300 You're right. The Postscript clones have obviously driven the price down. But, I still have to shell out additional money to get the screen fonts ! -jaz
philip@minnie.Stanford.EDU (Philip Machanick) (08/28/90)
In article <1798@abvax.UUCP>, jaz@icd.ab.com (Jack A. Zucker) writes: > You're right. The Postscript clones have obviously driven the price > down. But, I still have to shell out additional money to get the > screen fonts ! I don't know what kind of computer you use, but I've never had to pay for screen fonts. Additional PostScript fonts, yes, but not bitmapped versions of fonts supplied with the printer. Philip Machanick philip@pescadero.stanford.edu
zben@umd5.umd.edu (Ben Cranston) (08/28/90)
In article <257@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: > The Macintosh already downloads machine code, which is also one of the > reasons that Mac-generated PostScript files run into trouble on other > brands of printers. There is "bit-smoothing" code in eexec form buried > in LaserPrep (or was the last time I looked). Luckily, it checks to see > if the product is an Apple LaserWriter before executing it. Unluckily, > in the process of NOT executing it, it often NOT executes the rest > of your job too. Adobe's driver should fix this, I would imagine. In > the meantime it continues to be a first-class headache for everyone trying > to use Mac-generated PostScript. In fact, I'm sure it's one of the most > frequently asked questions in this newsgroup. For the record, the "flushfile"s were replaced with code that reads up to a known %-comment in level 6.0 (dict version 70) printing. The problem Glenn alludes to is present in 5.0 and 5.2 printing. When doing my vetted versions I replaced the flushfiles with painstakingly-counted skip-counts, like that used to skip the LaserWriter II NT retrofit code near the top. There are other gotchas that are still there. Look for calls to "setsccinteractive", "waittimeout", and "setdefaulttimeouts". Or get "macps" from sumex, run it on a command-K file, then diff it :-) -- Ben Cranston <zben@umd2.umd.edu> A determined iconoclast, it would be better to assume the opinion expressed above is the diametric OPPOSITE to that of the Warm and Fuzzy Network Group of Egregious State University...
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/28/90)
In article <7190@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes: > In article <257@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us > > For the record, the "flushfile"s were replaced with code that reads up to a > known %-comment in level 6.0 (dict version 70) printing. The problem Glenn This technique of skipping headers and such, by watching for (%%%) in the input stream fails on the NEC 890. It will never see them. Cassidy and Greene's fonts don't work because of it. You can send one down to the printer, but it will happily eat anything else. Apparently the %'s are not captured by the interpreter. It appears that comments are just tossed away. I posted some code to the net some months back that demonstrated this, but I never saw any reply as to whether or not other people saw the same thing. I DO know that I spent a very LONG time converting a bunch of C&G fonts to work properly on the NEC890. Cheers Woody > > There are other gotchas that are still there. Look for calls to > "setsccinteractive", "waittimeout", and "setdefaulttimeouts". > > Or get "macps" from sumex, run it on a command-K file, then diff it :-) > > -- > Ben Cranston <zben@umd2.umd.edu> > A determined iconoclast, it would be better to assume the opinion expressed > above is the diametric OPPOSITE to that of the Warm and Fuzzy Network Group > of Egregious State University...
izumi@mindseye.berkeley.edu (Izumi Ohzawa) (08/28/90)
In article <1798@abvax.UUCP> jaz@icd.ab.com (Jack A. Zucker) writes: > >You're right. The Postscript clones have obviously driven the price >down. But, I still have to shell out additional money to get the >screen fonts ! For NeXT computer which comes with DPS (Display PostScript), you only pay once for the screen & printer. I wonder how much NeXT pays Adobe for DPS per machine, but it can't be $1000 considering that the whole thing is $6.5k for universities. Window Server is the printer. Izumi Ohzawa, izumi@violet.berkeley.edu
blarsen@spider.uio.no (Bjorn Larsen) (08/29/90)
In article <9931@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: > Geez, relax, will ya? What this means is that different devices will > probably require a different driver (gee, what a shock. That already > seems to be true). False. I run a printer spooler that accepts PostScript code from PCs, VAX/VMS, Unix, NOS/VE and Macs. It spools output to a big variety of PostScript printers; most with Adobe RIPs: Apple LaserWriter, LN03R, LPS-40, LPS-20, Agfa Matrix SlideWriter, QMS 100 ColorScript, TI MicroLaser, Linotronic 100/RIP3, and others. In general I can send PostScript code generated on a Mac to any device. Just a few programs demand special attention: - the Apple LaserPrep file is badly written. I have prepared custom versions of this for the various RIPs, and my spooler strips the original ProcSet and adds one suited for the target printer. - the Apple LaserWriter driver doesn't care to document the use of fonts (using DocumentFonts/DocumentNeededFonts), so I have to do a RE-search through the document for font invocations, and add the right comments before handing the PS file to the font downloader. A drag, but it works. - Freehand 2.0 insists on using letter/a4 operators without checking if they are defined or not. I use the ProcSet-substitution for that as well. - Fullwrite Professional 1.1 starts one of it's ProcSets with %%BeginProcSet as required, but ends it with %% End of Fullwrite ProcSet so as to implement my ProcSet substitution, I have to recognize that as a legal way to end a ProcSet. Ugh. Apart from these minor things (which my spooler fixes for me), I am able to print from any Mac to any make of PostScript printer. No matter what the hardware in the RIP consists of. So yes, PostScript has acheived it's goal about being device independent. And all in all - most PostScript generating software does a decent job about being printer-independent. -- Bjorn Larsen University of Oslo, Norway Bjorn.Larsen@usit.uio.no
glenn@heaven.woodside.ca.us (Glenn Reid) (08/29/90)
In article <1511@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >This technique of skipping headers and such, by watching for (%%%) in the >input stream fails on the NEC 890. It will never see them. Cassidy and >Greene's fonts don't work because of it. You can send one down to the >printer, but it will happily eat anything else. Apparently the %'s >are not captured by the interpreter. It appears that comments are >just tossed away. I posted some code to the net some months back that >demonstrated this, but I never saw any reply as to whether or not other >people saw the same thing. We've been around this before. You posted a while ago that that the LC-890 stripped out comments in the scanner and they couldn't be read by the interpreter. I posted a test program that would decide whether or not the % comments were indeed getting through. At least three people independently confirmed that it worked on their NEC LC-890 printers. You say "I never saw any reply...". Maybe you were out of town that week, or maybe you don't read followup postings to your own postings, since it was the next day that these all appeared. Summary: it's not the LC-890, it's either your analysis of the problem, your spooler, the fonts themselves, or something else. It's possible that the fonts are using "readstring" and expecting a precise number of bytes, and some conversion of carriage-return newline sequences to just newline might make the byte count wrong, as a guess. It is a reasonable technique to read the input stream until you see a % flag, as Ben suggested. Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/29/90)
In article <258@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: > In article <1511@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > >This technique of skipping headers and such, by watching for (%%%) in the > >input stream fails on the NEC 890. It will never see them. Cassidy and > >people saw the same thing. > > We've been around this before. > > You posted a while ago that that the LC-890 stripped out > comments in the scanner and they couldn't be read by the > interpreter. > > I posted a test program that would decide whether or not the > % comments were indeed getting through. At least three people > independently confirmed that it worked on their NEC LC-890 > printers. You say "I never saw any reply...". Maybe you were I did indeed see Glens code, and the followups. I then posted the following message, which clearly demonstrates the problem. I never saw any reply, and have no Idea whether anyone tested it or not. I'd like to see someone test this. This is not a complete font, most of the guts have been cut out, but there should be enough here to demonstrate the problem. After coming back from a long weekend vacation, attending a flint knappers convention (studying the art of making stone tools), I have read the news and found Glenns bit of code and the test run of it. Since this problem came up over a year and a half ago, I decided to go get a copy of one of the fonts, delete all but 1 character and post it. I may be dead wrong about the input scanner, but regardless, the readstring operator does not find the (%%%) and thus hangs forever on the second font download in a NEC 890. The symptom is that you can download 1 font. downloading another font causes the machine to hang looking for the %%%. This failure causes it to stay in the procesing state indefintly. The QMS-ps810 does not exhibit the problem, and presumably other machines don't either. C & G had tested it exclusively on Apples, and had no problems. I came up with a crude, simple workaround that fixed the problem. We downloaded for Pagemaker on the fly, i.e. non-persistant fonts, and I changed the dictionary name Casa1 to Casa(n) where (n) was some arbitrary number. It worked. It is not optimal. You should be able to copy this to a NEC-890 (using whatever) and the second time you copy it, it should hang the machine. changing the dictionary name, and deleteing the comment hunting code fixed the problem. Cheers Woody %!PS-Adobe-2.0 %%Title: Fontographer 2.4.1 %%FontName: GalileoRoman %%CreationDate: 1/9/89 7:52:05 PM %%Creator: RICHARD WARE %%Pages: 0 %% Galileo*Roman, Version 3.1a, Copyright ) 1987-1988 by Richard A. Ware. All Rights Reserved. %%EndComments %serverdict begin 0 exitserver % remove first percent sign for PC fonts... systemdict /currentpacking known { /SavPak currentpacking def true setpacking }if userdict /Casa1 known % if the preamble was known { { currentfile( )readstring { (%%%)eq %look for separator { exit }if } { pop %hangs, looking forever }ifelse }loop }if userdict begin/Casa1 39 dict def Casa1 begin/NL 0 def/B{bind def}bind def /Cache{NL 0 eq{setcachedevice}{6{pop}repeat}ifelse 0 0 moveto}B /SetWid{NL 0 eq{0 setcharwidth setgray}{pop setgray}ifelse 0 0 moveto}B /ShowInt{/NL NL 1 add store BC2 grestore/NL NL 1 sub store}B /charStr(.)def/Strk 0 def/Sstrk{/Strk 1 store}B /Cfill{PaintType 0 eq{Strk 0 eq{exec}{gsave exec grestore currentgray 0 ne{0 setgray}if stroke}ifelse}{pop stroke}ifelse}B /Fill{{fill}Cfill}def/Eofill{{eofill}Cfill}def/Cp{closepath 0 0 moveto}def /ShowExt{EFN exch get findfont setfont matrix currentmatrix exch InvMtx concat 0 0 moveto charStr 0 3 -1 roll put PaintType 0 ne Strk 0 ne or currentgray 0 ne or{charStr false charpath setmatrix Fill} {charStr show pop}ifelse grestore}B/stringtype{{UCS}forall}B /arraytype/exec load def/packedarraytype/exec load def /BuildChar{Casa1 begin exch begin BC2 end end}B /BC2{save 1 setflat exch StrokeWidth setlinewidth/Strk 0 store Encoding exch get dup CharStrings exch known not{pop/.notdef}if CharStrings exch get newpath dup type exec restore}B /UVec[{rmoveto}{rlineto}{rcurveto}{ShowExt}{]concat}{Cache}{setlinewidth} {ShowInt}{setlinecap}{setlinejoin}{gsave}{[}{Fill}{Eofill}{stroke}{SetWid} {100 mul add}{100 mul}{100 div}{Cp}{Sstrk}{setgray}]def /UCS{dup 200 lt{100 sub}{dup 233 lt{216 sub 100 mul add} {233 sub UVec exch get exec}ifelse}ifelse}B /CD{/NF exch def{exch dup/FID ne{exch NF 3 1 roll put} {pop pop}ifelse}forall NF}B /MN{1 index length/Len exch def dup length Len add string dup Len 4 -1 roll putinterval dup 0 4 -1 roll putinterval}B /RC{(|______)anchorsearch {1 index MN cvn/NewN exch def cvn findfont dup maxlength dict CD dup/FontName NewN put dup /Encoding MacVec put NewN exch definefont pop}{pop}ifelse}B /RF{dup cvn FontDirectory exch known{pop}{RC}ifelse}B /MacVec 256 array def MacVec 0 /Helvetica findfont /Encoding get 0 128 getinterval putinterval MacVec 127 /DEL put MacVec 16#27 /quotesingle put MacVec 16#60 /grave put/NUL/SOH/STX/ETX /EOT/ENQ/ACK/BEL/BS/HT/LF/VT/FF/CR/SO/SI/DLE/DC1/DC2/DC3/DC4/NAK/SYN /ETB/CAN/EM/SUB/ESC/FS/GS/RS/US MacVec 0 32 getinterval astore pop /Adieresis/Aring/Ccedilla/Eacute/Ntilde/Odieresis/Udieresis/aacute /agrave/acircumflex/adieresis/atilde/aring/ccedilla/eacute/egrave /ecircumflex/edieresis/iacute/igrave/icircumflex/idieresis/ntilde/oacute /ograve/ocircumflex/odieresis/otilde/uacute/ugrave/ucircumflex/udieresis /dagger/degree/cent/sterling/section/bullet/paragraph/germandbls /registered/copyright/trademark/acute/dieresis/notequal/AE/Oslash /infinity/plusminus/lessequal/greaterequal/yen/mu/partialdiff/summation /product/pi/integral/ordfeminine/ordmasculine/Omega/ae/oslash /questiondown/exclamdown/logicalnot/radical/florin/approxequal/Delta/guillemotleft /guillemotright/ellipsis/nbspace/Agrave/Atilde/Otilde/OE/oe /endash/emdash/quotedblleft/quotedblright/quoteleft/quoteright/divide/lozenge /ydieresis/Ydieresis/fraction/currency/guilsinglleft/guilsinglright/fi/fl /daggerdbl/periodcentered/quotesinglbase/quotedblbase /perthousand/Acircumflex/Ecircumflex/Aacute /Edieresis/Egrave/Iacute/Icircumflex/Idieresis/Igrave/Oacute/Ocircumflex /apple/Ograve/Uacute/Ucircumflex/Ugrave/dotlessi/circumflex/tilde /macron/breve/dotaccent/ring/cedilla/hungarumlaut/ogonek/caron MacVec 128 128 getinterval astore pop end end %%%%%% %%EndProlog /$GalileoRoman 19 dict def $GalileoRoman begin/PaintType 0 def/FontType 3 def /StrokeWidth 0 def/FontBBox[-52 -251 1006 832]def %/UniqueID 4835107 def /FontMatrix[0.001000 0 0 0.001000 0 0]def/InvMtx[1000 0 0 1000 0 0]def /CharStrings 257 dict def/FontName (GalileoRoman) def /BuildChar{Casa1/BuildChar get exec}def /FontInfo 3 dict def FontInfo begin /UnderlinePosition -166 def/UnderlineThickness 19 def end /Encoding Casa1/MacVec get def CharStrings begin/.notdef{500 0 setcharwidth} def /NUL<646486D97CDA88D97EDAEE87D97DDAE9F5>def /HT<6464AE6DDBB06FDBEEAF6EDBE9F5>def /CR<6464AE95DAB097DAEEAF96DAE9F5>def /space<AADA6490D9A9D992D9ABD9EE91D9AAD9E9F5>def /exclam<96DA649D4064DA7FDFEEBCA8DEE97684A484B664EB704E73387221EB62453236 D43236D4EB5A64EA64643473DC3292DCEB637A659172A7EBFC81D9C2E9266426066605EB A563A4C262C3EBFCF5>def end/EFN[]def end systemdict/currentpacking known{SavPak setpacking}if /GalileoRoman $GalileoRoman definefont pop /GalileoRoman findfont/EFN get Casa1 begin{RF}forall end Cheers Woody
cortesi@infmx.UUCP (David Cortesi) (08/29/90)
In article <9931@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: >> MACHINE CODE???? >Geez, relax, will ya? What this means is that different devices will >probably require a different driver (gee, what a shock. That already >seems to be true). Absolutely not true. We have printers from TI, Imagen, QMS, and Printware, and we drive them all from the identical UNIX spooling daemons. These include Adobe-license RIPS of different change levels and at least one clone (Printware's PrintScript). We shove at them the output of FrameMaker (on Sun and NeXT), Eroff, and Wingz (Sun and NeXT) and they print it all, plus EPS clip art from Adobe Illustrator on the Mac. To me it is pure magic how you can hook up any arbitrary PostScript printer to a serial port and start pouring documents through it with *no* configuration except to set the baud rate. It would be totally unacceptable to have to maintain separate spooling or driving code for each make of printer. That would be a major step backward.
zben@umd5.umd.edu (Ben Cranston) (08/30/90)
In article <1513@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > ... This is not a complete font, most of the guts have been > cut out, but there should be enough here to demonstrate the problem. > /Casa1 known % if the preamble was known > { > { > currentfile( )readstring > { > (%%%)eq %look for separator > { > exit > }if > } > { > pop %hangs, looking forever > }ifelse > }loop > }if I think this is broken. Seems to me this will read 3-character chunks from the input and compare them against %%%, but if the stuff being skipped is not EXACTLY a multiple of 3 characters long you could get a test against <newline> % % or % % <somethingelse> and fail to find the target. Remember that (according to red book) readstring does NOT stop on line bdry! Perhaps if you used readline, gave it a fairly longish string to read into, ==== and used an anchorsearch to match the three first characters on the line, ============ this could be made to work... Am I off base? -- Ben Cranston <zben@umd2.umd.edu> A determined iconoclast, it would be better to assume the opinion expressed above is the diametric OPPOSITE to that of the Warm and Fuzzy Network Group of Egregious State University...
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/30/90)
In article <7214@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes: > In article <1513@chinacat.Unicom.COM> woody@chinacat.Unicom.COM > (Woody Baker @ Eagle Signal) writes: > > > currentfile( )readstring > > { > > (%%%)eq %look for separator > > { > > exit > > }if > > } > I think this is broken. Seems to me this will read 3-character chunks from > the input and compare them against %%%, but if the stuff being skipped is That is why the string of comments is 6 characters long. That way you should be garanteed to get at least one match. I tried making the line 10 or 12 characters long, and it still failed. I also tried changing the (%%%) to something else like (***) and changing the line of comments to %*********** This failed also. What I cannot understand, is why this works on a PS-810, and Apple Laserwriters, but fails on the NEC 890. (and only the nec 890 to my knowlege). I know that things worked flawlessly on my PS-810, but failed on the nec 890. Cheers Woody > <newline> % % or % % <somethingelse> and fail to find the target.
glenn@heaven.woodside.ca.us (Glenn Reid) (08/31/90)
In article <7214@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: [ example with "readstring" omitted] >I think this is broken. Seems to me this will read 3-character chunks from >the input and compare them against %%%, but if the stuff being skipped is >not EXACTLY a multiple of 3 characters long you could get a test against ><newline> % % or % % <somethingelse> and fail to find the target. >Remember that (according to red book) readstring does NOT stop on line bdry! > >Perhaps if you used readline, gave it a fairly longish string to read into, > ==== >and used an anchorsearch to match the three first characters on the line, > ============ >this could be made to work... > >Am I off base? No, you are right on target. I think you have hit on exactly the right analysis of the code. "readstring" always reads three bytes, and if the byte alignment of the PS code is off by even a single byte, you'll read right past the comments. Your solution to use "readline" and a large buffer will work well, especially since the code is usually designed to skip something very specific, and you already know how long the longest line might be. The other possibility is to actually read the data one byte at a time, and exit when you see the first '%', regardless of where it might be. That will always work (no buffer overflows or alignment problems), but is a lot slower and might exit at the wrong place if more comments are introduced into the file somewhere. Anyway, the original program as posted would fail on ANY PostScript printer under the right circumstances. It's certainly a mis-analysis to blame it on the serial driver in the NEC LC-890. If the PS is generated on a Mac and printed from a Mac you probably get lucky, but even the act of transfering the file to another computer will very likely change the byte count (newlines added or subtracted) somewhere along the way. /Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
zben@umd5.umd.edu (Ben Cranston) (08/31/90)
I wrote >> I think this is broken. Seems to me this will read 3-character chunks from >> the input and compare them against %%%, but if the stuff being skipped is In article <1527@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > That is why the string of comments is 6 characters long. That way you > should be garanteed to get at least one match. I tried making the > line 10 or 12 characters long, and it still failed. I also tried > changing the (%%%) to something else like (***) and changing the > line of comments to > %*********** > This failed also. Sorry Woody and all the others who had to read my previous posting, I had concentrated on the code and missed the fact that the end sentinal was actually SIX percent signs. > What I cannot understand, is why this works on a PS-810, and Apple > Laserwriters, but fails on the NEC 890. (and only the nec 890 to my > knowlege). I know that things worked flawlessly on my PS-810, but > failed on the nec 890. It is a good question why it does different things in any case. Is it possible that NEC lets the carriage returns and the line feeds through unmolested? Is it possible there is a certain minimal string size imposed for efficiency and the ( ) is allocating more memory than just three characters, so the readstring is actually reading larger chunks? If I had one of these printers I would arrange to send back the chunks: { %loop currentfile( )readstring { %ifelse dup == % added by zben (%%%) eq %look for separator { exit } if }{ pop %hangs, looking forever } ifelse } loop The output from the == would be very informative. It is possible the (%%%) construct is being improperly parsed. Does %% mean anything to this printer? Is it possible the exit could be exiting the IF block but not the LOOP block? Cannot speculate, must have experimental evidence... I still think I would have done it like this: 80 string { %loop dup currentfile exch readline exch (%%%) eq or { exit } if } loop pop (You can tell I'm an old dinosaur tamer, that 80 is a dead giveaway! :-) -- Ben Cranston <zben@umd2.umd.edu> A determined iconoclast, it would be better to assume the opinion expressed above is the diametric OPPOSITE to that of the Warm and Fuzzy Network Group of Egregious State University...
chewy@apple.com (Paul Snively) (08/31/90)
In article <5079@infmx.UUCP> cortesi@infmx.UUCP (David Cortesi) writes: > In article <9931@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: > >In article <438@three.mv.com> cory@three.mv.com (Cory Kempf) writes: > >> MACHINE CODE???? > >Geez, relax, will ya? What this means is that different devices will > >probably require a different driver (gee, what a shock. That already > >seems to be true). > > Absolutely not true. We have printers from TI, Imagen, QMS, and Printware, > and we drive them all from the identical UNIX spooling daemons. These > include Adobe-license RIPS of different change levels and at least one > clone (Printware's PrintScript). We shove at them the output of FrameMaker > (on Sun and NeXT), Eroff, and Wingz (Sun and NeXT) and they print it all, > plus EPS clip art from Adobe Illustrator on the Mac. I believe that; I was referring to the Macintosh drivers. PostScript definitely does its job of being independent well; it seems to be the QuickDraw to PostScript conversion that can be problematic. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
glenn@heaven.woodside.ca.us (Glenn Reid) (08/31/90)
In article <1527@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >That is why the string of comments is 6 characters long. That way you >should be garanteed to get at least one match. I tried making the >line 10 or 12 characters long, and it still failed. I also tried >changing the (%%%) to something else like (***) ... Woody, you're using the "eq" operator. It has to match EXACTLY for "eq" to be happy. Making the string longer has nothing to do with it. Go read the green book, page 201, and look at the "userexec" procedure. There is code in there that flushes to a comment. Notice that it uses the "readline" operator, as suggested by Ben Cranston. The bottom line is that the technique of using "readstring" and "eq" can never be made to work 100% of the time. To be fair, neither can "readline", since version 23.0 of the LaserWriter (the LaserWriter "Classic") has a version of "readline" that doesn't handle all possible combinations of carriage return and linefeed pairs. But it's still the right way to go. And use "anchorsearch", not "eq", to find your end-of-stuff flag. >What I cannot understand, is why this works on a PS-810, and Apple >Laserwriters, but fails on the NEC 890. (and only the nec 890 to my >knowlege). I know that things worked flawlessly on my PS-810, but >failed on the nec 890. I cannot understand it either, but it's more likely to be the way you transmit the file to the printer than it is the printer itself. If you make the code better, along the lines of the various suggestions, it will not fail on the LC-890, or I'll eat a toner cartridge. /Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/31/90)
In article <7221@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes: > I wrote > > imposed for efficiency and the ( ) is allocating more memory than just > three characters, so the readstring is actually reading larger chunks? I think that this would violate the specs. > If I had one of these printers I would arrange to send back the chunks: > > { %loop > currentfile( )readstring > { %ifelse > dup == % added by zben > (%%%) eq %look for separator > { exit } if > }{ > pop %hangs, looking forever > } ifelse > } loop > The output from the == would be very informative. It is possible the I hope some one will try this. My hypothesis is that someone decided that it was ineffecient for the interpreter to have to read in, and parse out a comment line, so they simply prevented readstring from ever getting it. Glenn posted some code that seems to refute that, but it seems to me to be the only thing that explains all the conditions. I don't remember what his code was now, I could go hunt it up in the archieves, but I seem to remember that it might not have excercized readstring. > > I still think I would have done it like this: > > 80 string > { %loop > dup currentfile exch readline exch > (%%%) eq or { exit } if > } loop > pop > > (You can tell I'm an old dinosaur tamer, that 80 is a dead giveaway! :-) Yep. No kidding. I am one also. Last count I had 16 diffrent computers sitting around my house. Most of them are even in working condition!. Some of them are OLD. The computer in my PS-810 has more horsepower than any of them 8=} Cheers Woody Sorry for these few lines, but inews is really picky. It won't post anything unless the poster has written more new text than he has included. So In order to satisfy it, these lines are being written. :=>
dorner@pequod.cso.uiuc.edu (Steve Dorner) (09/01/90)
In article <9995@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >I believe that; I was referring to the Macintosh drivers. PostScript >definitely does its job of being independent well; it seems to be the >QuickDraw to PostScript conversion that can be problematic. Yes, because Apple insists on putting hardware dependencies, including 68000 programs in hex, in its LaserPrep. (Does anyone else feel a sense of deja vu in this thread?) To have such built into TrueType (if it is) would pose a big problem for everyone with non-Apple printers. Perhaps that is exactly what Apple has in mind. Like I said before, I'm ordering Adobe's Mac PostScript printer driver as soon as they release it. I suggest anyone with non-Apple printers and Macintoshes do the same. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (09/03/90)
In article <1990Aug31.194241.27316@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <9995@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >>I believe that; I was referring to the Macintosh drivers. PostScript >>definitely does its job of being independent well; it seems to be the >>QuickDraw to PostScript conversion that can be problematic. > >Yes, because Apple insists on putting hardware dependencies, including >68000 programs in hex, in its LaserPrep. (Does anyone else feel a sense >of deja vu in this thread?) To have such built into TrueType (if it is) >would pose a big problem for everyone with non-Apple printers. Perhaps >that is exactly what Apple has in mind. > >Like I said before, I'm ordering Adobe's Mac PostScript printer driver >as soon as they release it. I suggest anyone with non-Apple printers >and Macintoshes do the same. >-- >Steve Dorner, U of Illinois Computing Services Office >Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner Actually, I think that Mr. Snively is wrong on this one. One of the big features of the System 7 PostScript driver which was pushed real hard is that the postscript output is: a) Device independent. (They even are going so far as changing the icon so that it no longer resembles an Apple laser printer) b) Self-contained. (I.E. No LaserPrep) c) Can be sent to a file in a supported, consistent manner for downloading or fiddling. It is inconceivable that given the particular design requirements the PostScript driver people have set for themselves that they'd be downloading M68000 code to the printer. -- Mark Wilkins wilkins@jarthur.claremont.edu
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (09/06/90)
In article <262@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: > In article <1527@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > >That is why the string of comments is 6 characters long. That way you > >should be garanteed to get at least one match. I tried making the > >line 10 or 12 characters long, and it still failed. I also tried > >changing the (%%%) to something else like (***) ... > > Woody, you're using the "eq" operator. It has to match EXACTLY for "eq" I did not write the code, it apparently was produced via fontographer. But in either case, I believe that readstring fills the supplied string completely, with characters, and stops. This means that readstring will read in 3 character chunks. If you have 6 %'s in a row, it should find 3 of them. If you had less, it could miss some as pointed out, and if you had more you just would have an extra margin of saftey. Increasing the number did not solve the problem. > Go read the green book, page 201, and look at the "userexec" procedure. > There is code in there that flushes to a comment. Notice that it uses > the "readline" operator, as suggested by Ben Cranston. > > The bottom line is that the technique of using "readstring" and "eq" > can never be made to work 100% of the time. > > > >What I cannot understand, is why this works on a PS-810, and Apple > >Laserwriters, but fails on the NEC 890. (and only the nec 890 to my > >knowlege). I know that things worked flawlessly on my PS-810, but > >failed on the nec 890. > > I cannot understand it either, but it's more likely to be the way you > transmit the file to the printer than it is the printer itself. If you > make the code better, along the lines of the various suggestions, it will > not fail on the LC-890, or I'll eat a toner cartridge. The fonts were supplied on MS-DOS disks, along with screen fonts for windows. The platform was an AT clone, connected to the NEC via a Centronics paralell port. My platform consists of an AT clone connected to a PS-810 via a Centronics port. Both copy and print techiniques were tried, as well as telling Windows to treat the fonts as non permanent fonts to be downloaded on the fly. In all 3 cases on both platforms, the result was the same. Just for grins, I guess I'll drive over there and try it again. My original suspicion was that someone figured that it was wasteful of interpreter time to have to wade through comments, so decided to filter them out instantly. Cheers Woody
glenn@heaven.woodside.ca.us (Glenn Reid) (09/06/90)
In article <262@heaven.woodside.ca.us>, I write, among other nonsense: > Go read the green book, page 201, and look at the "userexec" procedure. > There is code in there that flushes to a comment. Notice that it uses > the "readline" operator, as suggested by Ben Cranston. > > The bottom line is that the technique of using "readstring" and "eq" > can never be made to work 100% of the time. As several of you have pointed out through Email and as Woody mentions, I'm all wet; the code as posted would read three percent signs, or so it would seem, if there were six of them somewhere along the way. In article <262@heaven.woodside.ca.us>, I continue: > I cannot understand it either, but it's more likely to be the way you > transmit the file to the printer than it is the printer itself. If you > make the code better, along the lines of the various suggestions, it will > not fail on the LC-890, or I'll eat a toner cartridge. I'm not ready to eat the toner cartridge yet. Have you ever had the experience of starting with a conclusion that you know to be true, and then working backwards to a plausible explanation, rather than trying to actually analyze the problem at hand? Well, that's what I was doing. And I still think the the conclusion that I know to be true is that the NEC LC-890 is not throwing away comments in the serial driver. A lot of other things might be happening, but I won't believe that's one of them unless Ed Taft tells me so. But, rather than shut up, which is probably what I should do, I'll venture some more half-baked thoughts :-) >The fonts were supplied on MS-DOS disks, along with screen fonts for >windows. The platform was an AT clone, connected to the NEC via a Centronics >paralell port. My platform consists of an AT clone connected to a PS-810 >via a Centronics port. Both copy and print techiniques were tried, as well >as telling Windows to treat the fonts as non permanent fonts to be downloaded >on the fly. In all 3 cases on both platforms, the result was the same. >Just for grins, I guess I'll drive over there and try it again. Perhaps it is related to the parallel port somehow? I've never driven a PostScript printer through a parallel port. I suppose it is possible that the parallel driver does different things than the serial driver does, and one of them might be to throw away comments. That might also explain why the test program I posted a while back, which would indicate that the comments *were* getting through, might not have worked for Woody. Woody, howzabout testing it on the serial port while you're there (if you're still there, after having driven over to try it again :-) It's also possible that the program is just getting a PostScript error somewhere and is flushing the rest of the file; I assume that Woody would catch this, though. >My original suspicion was that someone figured that it was wasteful of >interpreter time to have to wade through comments, so decided to filter >them out instantly. I'd stake that toner cartridge that this isn't happening on AppleTalk or the serial port, but I have no idea about Centronics, other than to think that it should be pretty much the same. I know that test program I wrote a while ago is lost, so here's another one that should print the string "%%Comments are getting through" if they in fact are getting through, and will print nothing if not: ---------------------------- cut here --------------------- %! /buff 30 string def currentfile buff readstring %%Comments are getting through 100 100 moveto /Helvetica findfont 18 scalefont setfont buff show showpage ---------------------------- and here --------------------- Several of you helpful folks out there reported that the other program I posted a while back worked on your NEC LC-890 printers. Just so we squash this once and for all, how 'bout if people only report if it DOESN'T work on their printer. And if it doesn't, the more you can report about your setup, the better. Version of printer, connection to host, kind of host, whatever. Now I've become curious about this whole issue. If it's a real problem, it ought to pop up all over the place, not just on Woody's system, unless the intersection between people who read comp.lang.postscript and those driving PS printers over Centronics ports from PC clones is a very small set, which I would be happy to believe. Glenn P.S. If it ends up that I have to eat a toner cartridge, please send me only new toner cartridges that will fit in the LaserWriter II NTX :-) -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
shiva@well.sf.ca.us (Kenneth Porter) (09/06/90)
Bjorn Larsen writes: > I run a printer spooler that accepts PostScript code from > PCs, VAX/VMS, Unix, NOS/VE and Macs. > > It spools output to a big variety of PostScript printers; most > with Adobe RIPs: Apple LaserWriter, LN03R, LPS-40, LPS-20, > Agfa Matrix SlideWriter, QMS 100 ColorScript, TI MicroLaser, > Linotronic 100/RIP3, and others. Is this spooler commercial, freeware, local, or what? Bjorne, you mention that you do ProcSet substitution. This begins to sound like the sexy "Document Managers" mentioned in the Structuring Comments document and Glenn's Green Book. Just what all can it do? Does it parse and use PPD's? Does it handle document font requests? What platforms does it run on? And while I'm at it, what other spoolers are available for various platforms? I use Pipeline's devps stuff (the same people who produce the PostScript Language Journal), heavily customized to fit my needs. It doesn't do document management, but I did add a filter to auto-sense various kinds of PostScript files (%!, MS Word, Word Perfect 4.2) and translate those that don't match using a text-to-PostScript utility provided by Pipeline. If the "-l" switch was given to lpr, my auto-sense routine complements its decision, to allow printing of non-standard PostScript files and to allow me to get listings of a conforming PostScript source. I also added back-channel capture to a Sunview window, so I could see my error messages in realtime. The devps product is primarily for converting dvitroff to PostScript, which I don't use since dvitroff doesn't come with Suns. The spooler is a small part of the product, and essentially consists of filters to put in printcap. These include one to convert CAT files to dvi (I couldn't get this part to work; probably something weird about Sun 386i COFF-format font files, I use thack instead), two to convert text to PostScript, and a script to read the arguments passed from lpd to dispatch to the appropriate filter. The latter is what goes in printcap, aliased to different names (ps.if, ps.tf, ps.nf). The rest of the package is a variety of handy utilities for such things as printing font samples, getting AFM files back from the printer, and overlaying ghosted text across a page. The original package runs about $300 for source. It's not for users who don't feel comfortable with hacking around with printcap, serial ports, and shell scripts. I think Legatto sells a Sun binary all integrated and ready for use for roughly the same amount. What do you get with TranScript for $1800 (source from Adobe, or binary from Sun)? At the time I was researching it, it didn't sound like enough to warrant a 6x price difference.
shiva@well.sf.ca.us (Kenneth Porter) (09/06/90)
Woody posted code containing the following fragment as an
example of something that would hang an NEC LC890, with the
request that fellow LC890 owners would test it.
{
currentfile( )readstring
{
(%%%)eq %look for separator
{
exit
}if
}
{
pop %hangs, looking forever
}ifelse
}loop
%
% ...bunch of PostScript code to skip over...
%
%%%%%%
Sorry, Woody, but your LC890 file works just fine on my LC890.
It finds the (%%%) and exits. I put the test in foo.ps and did
"cat foo.ps foo.ps | lpr" and got a standard EOF indication
back. I even put prints in the exit and pop paths of the loop
to verify which was taken and the comment detection path *was*
taken. I also cat-ed two copies of your complete font example
and got the same result.
Just so we agree on versions, here's a dump of some stats from
the printer:
Product: Silentwriter
Version: 47.0
Revision: 1
Printer Name: Silentwriter
Pagecount: 24432
Do Start Page: true
Margins: -16 25
Default Paper Tray: 2
Default Timeouts: 0 60 30
Usertime: 581751454
VM Total: 1318576
VM Used: 544622
VM Available: 773954
Save Level: 2
Perhaps there's something odd about your host setup. What do
you use to send files? If a unix spooler, what filters are
involved? Could a filter in the host be stripping your
comments or adding unexpected newlines?
Incidentally, I noted that the code fragment was saving the
packing flag and packing the font. Users of Presentation
Manager should be aware that the PM PostScript prolog is
ignorant of the packing flag and writes a dictionary into a
procedure body to get local variables in a private dictionary:
/BuildChar { 0 begin ... end } def
BuildChar load 0 3 dict put
This means that you can't set packing on by default when using
PM or the above trick will cause an invalidaccess as the put
stores into a (packed) readonly object.kibo@pawl.rpi.edu (James 'Kibo' Parry) (09/07/90)
In article <20146@well.sf.ca.us> shiva@well.sf.ca.us (Kenneth Porter) writes: >Woody posted code containing the following fragment as an >example of something that would hang an NEC LC890, with the >request that fellow LC890 owners would test it. > >{ > currentfile( )readstring > { > (%%%)eq %look for separator > { > exit > }if > } > { > pop %hangs, looking forever > }ifelse >}loop >% >% ...bunch of PostScript code to skip over... >% >%%%%%% > >Sorry, Woody, but your LC890 file works just fine on my LC890. >It finds the (%%%) and exits. It also seems to work for others--the DTP program "PageStream" uses it when downloading fonts (so that the fonts are skipped if they're already known). (PageStream's prep file looks for "%%%%%" and not "%%%", but that doesn't matter...) As far as I know, PageStream works on those printers. -- james "kibo" parry, 138 birch lane, scotia, ny 12302 <-- close to schenectady. kibo@pawl.rpi.edu _________________________________________________ kibo%pawl.rpi.edu@rpi.edu / Kibology / Anything I say is my opinion, userfe0n@rpitsmts.bitnet / is better! / and is the opposite of Xibo's.
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (09/07/90)
In article <267@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: > > I'm not ready to eat the toner cartridge yet. Have you ever had the > other things might be happening, but I won't believe that's one of them > unless Ed Taft tells me so. > > But, rather than shut up, which is probably what I should do, I'll venture > some more half-baked thoughts :-) Half baked or not, that's what this forum is all about. > > >The fonts were supplied on MS-DOS disks, along with screen fonts for > > Perhaps it is related to the parallel port somehow? I've never driven a > PostScript printer through a parallel port. I suppose it is possible that > the parallel driver does different things than the serial driver does, and That might be the case. I'll test it. Either Monday or Tuesday, depending on my schedule etc etc, I'll drive over and test it. I'll test Glenns'code, as well as make the change to one of the fonts to use the anchor search technique. I'll also test the following (%%%) %%%%%%%%%%%%% (***) %*************** (jjj) /jjjjjjjj 0 def as search strings. I don't know whether I can test it with serial or not. I think the machine only has one serial port and it is dedicated to the mouse. Of all the PS printers that I have sold that have centronics interfaces, to a printer they are used with the centronics interface. It is *MUCH* faster than serial mode, and does not have the handshaking problems. It might be interesting to tabluate percentages of useage of the various interfaces. If anyone has any other ideas for testing this, let me know.... > > It's also possible that the program is just getting a PostScript error > somewhere and is flushing the rest of the file; I assume that Woody would It isnot flushing the rest of the file. The NEC has a front panel and the thing just hangs in PROCESSING rather than dropping back to IDLE which is what should happen if it just flushed the job. > > > I'd stake that toner cartridge that this isn't happening on AppleTalk or > > > Now I've become curious about this whole issue. If it's a real > problem, it ought to pop up all over the place, not just on Woody's > system, unless the intersection between people who read > comp.lang.postscript and those driving PS printers over Centronics > ports from PC clones is a very small set, which I would be happy to > believe. It happens on a client of mine. She runs a KWIK COPY franchise, and purchased an AT and a NEC from someone else rather than me. She thought the other guy walked on air, that is until he sold her the system and then disappeared. Then guess who she called on??? That was always one of my pet peeves in the sales business. :-) >
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (09/07/90)
In article <20146@well.sf.ca.us>, shiva@well.sf.ca.us (Kenneth Porter) writes: > > > Woody posted code containing the following fragment as an > example of something that would hang an NEC LC890, with the > request that fellow LC890 owners would test it. > > > Sorry, Woody, but your LC890 file works just fine on my LC890. > It finds the (%%%) and exits. I put the test in foo.ps and did O.k. Thanks a bunch. I'll report further when I go back over and test it. I'll try putting the prints in the exit and pop paths as well. It is starting to sound like either a brain-damaged NEC, or an interface problem. I guess I'll drag my PS810 over there as well, to see if it is an interface problem. :-) Cheers Woody >
taft@adobe.com (Ed Taft) (09/07/90)
Since Glenn mentioned my name, I suppose I'd better contribute what I can to this discussion. I certainly don't want Glenn to eat a toner cartridge; it might interfere with his ability to participate in this newsgroup. Comments are not stripped out by the serial driver, centronics driver, or any other driver in a PostScript printer. Comments are recognized as such only by the PostScript language scanner, which is invoked when you execute the file or read it using the token operator, but not when you read it using data transfer operators such as readstring. My guess is that either the connection is flakey or the comments are being stripped by software further upstream. But that's just a guess. By the way, the subject of this thread doesn't have much to do with its content, does it? Ed Taft taft@adobe.com ...decwrl!adobe!taft
chewy@apple.com (Paul Snively) (09/08/90)
In article <8257@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: > Actually, I think that Mr. Snively is wrong on this one. One of the big > features of the System 7 PostScript driver which was pushed real hard is > that the postscript output is: > > a) Device independent. (They even are going so far as changing the icon > so that it no longer resembles an Apple laser printer) > > b) Self-contained. (I.E. No LaserPrep) > > c) Can be sent to a file in a supported, consistent manner for downloading > or fiddling. > > It is inconceivable that given the particular design requirements the > PostScript driver people have set for themselves that they'd be downloading > M68000 code to the printer. My comments weren't meant to apply to the driver sending PostScript to any particular PostScript device; they were meant to apply to the case of rendering TrueType on a device that doesn't have TrueType in ROM. Again, what seems to be the case is that if it has an '0x0, machine code gets downloaded, otherwise PostScript gets downloaded (I think). The point is that everything just works, which is what everyone keeps asking for. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
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 / /////////////////////////////////////////////////////////////////////////////