Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!adobe!heaven!glenn From: glenn@heaven.woodside.ca.us (Glenn Reid) Newsgroups: comp.lang.postscript Subject: Re: PostScript vs TrueType? Message-ID: <261@heaven.woodside.ca.us> Date: 30 Aug 90 19:54:37 GMT References: <9724@goofy.Apple.COM> <438@three.mv.com> <9931@goofy.Apple.COM> <258@heaven.woodside.ca.us> <1513@chinacat.Unicom.COM> <7214@umd5.umd.edu> Reply-To: glenn@heaven.woodside.ca.us (Glenn Reid) Organization: RightBrain Software, Woodside, CA Lines: 47 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 > % % or % % 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