pollack@toto.cis.ohio-state.edu (Jordan B Pollack) (12/05/89)
It seems like it might be possible, in principle, to get a cheap and accurate postscript previewer given you already have postscript in a printer. Couldn't this be achieved by mucking with the device, page-size and scaling to matchd a host graphic screen or window, rendering inside the printer at the reduced resolution, and redefining SHOWPAGE to print the image back to the host in some innocuous ascii format? Does anyone have any pointers to it having been done already in some PD or commercial product, or advice on potential problems (including why, if its impossible) besides the slowness of serial transmission speed? Jordan
halliday@cheddar.cc.ubc.ca (Laura Halliday) (12/05/89)
In article <POLLACK.89Dec4133944@toto.cis.ohio-state.edu> pollack@cis.ohio-state.edu writes: > >It seems like it might be possible, in principle, to get a cheap and >accurate postscript previewer given you already have postscript in a >printer. You bet. Check out LaserTalk from Emerald City Software. It uses the printer's PostScript interpreter to image things, and then ships a bitmap back to your Macintosh to turn into stuff on the screen. This is in fact a side effect; what it's really intended for is creating PostScript effects for text that can then be pasted into Word/MacWrite/etc. documents. Disclaimer: I don't work for Emerald City. Almost, though... (Hi Frank!) ...laura
woody@rpp386.cactus.org (Woodrow Baker) (12/05/89)
In article <POLLACK.89Dec4133944@toto.cis.ohio-state.edu>, pollack@toto.cis.ohio-state.edu (Jordan B Pollack) writes: > > It seems like it might be possible, in principle, to get a cheap and > accurate postscript previewer given you already have postscript in a > printer. > > Couldn't this be achieved by mucking with the device, page-size and > scaling to matchd a host graphic screen or window, rendering inside the > printer at the reduced resolution, and redefining SHOWPAGE to print > the image back to the host in some innocuous ascii format? > > Does anyone have any pointers to it having been done already in some > PD or commercial product, or advice on potential problems (including > why, if its impossible) besides the slowness of serial transmission > speed? > > Jordan Yes, there is a product for the MAC and I under stand for the pc as well now, called LASERTALK that does just that. The way it works, is that it downloads a machinelanguage routine that implements a new postscript operator which causes the video screen to be dumped back. Adobe is extremely jealous of just how to do this, unfortunatly. The lasertalk people had to fork over a gob of cash to get the details from Adobe. One of the problems is that Adobe doesnot like to release genuinly usefull information like this. They will, if you pay enough, and sign umptyump agreements, but for the average Postscript developer, or freelancer, sadly they (Adobe) seem not to want to supply this stuff to. It is one of the reasons that I posted the comment that I did sometime earlier. I heard from Adobe over that one. Like all companies, individuals can be helpful, but corprate attitudes and cultures tend to put a damper on things..... Cheers Woody P.S. the above message is not ment to be derogratory in any way to Adobe.
pollack@toto.cis.ohio-state.edu (Jordan B Pollack) (12/06/89)
OK, I called Emerald City, and LASERTALK is NOT available for the PC, only the MAC. The technical representative thinks that a new header is placed on an EPSF file, and SHOWPAGE is replaced by an undocumented function whose access and description were purchased from Adobe. Unthinkingly, my proposal involved a trojan horse security gap, which Fort Adobe has already protected for. Imagine being able to get bitmaps for proprietary fonts back to the host! So I guess its probably impossible without a lot of money. But, if the feature is undocumented and inside all apple laserwriters from day 1, surely it can be used, given this knowledge, which could certainly be obtained by examining a file sent by lasertalk to a laserwriter, unless that is protected by law....
rsilverman@eagle.wesleyan.edu (12/06/89)
In article <POLLACK.89Dec4133944@toto.cis.ohio-state.edu>, pollack@toto.cis.ohio-state.edu (Jordan B Pollack) writes: > > It seems like it might be possible, in principle, to get a cheap and > accurate postscript previewer given you already have postscript in a > printer. > > ... > > Does anyone have any pointers to it having been done already in some > PD or commercial product, or advice on potential problems (including > why, if its impossible) besides the slowness of serial transmission > speed? > > Jordan Jordan, There is a commercial product that does this: Lasertalk, by Emerald City Software. The problem is that the standard PostScript language does not provide any means of accessing the frame buffer directly, to read out the rendered image. Lasertalk accomplishes it with a bit of encrypted code licensed from Adobe. Richard Silverman
ifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar) (12/08/89)
In article <POLLACK.89Dec5120903@toto.cis.ohio-state.edu> pollack@cis.ohio-state.edu writes: >OK, I called Emerald City, and LASERTALK is NOT available for the PC, >only the MAC. The technical representative thinks that a new header is >placed on an EPSF file, and SHOWPAGE is replaced by an undocumented >function whose access and description were purchased from Adobe. > This is very interesting, as I have in my hand an FAX from PICA Australia, giving details and price for Lasertalk PC available NOW (price $995 Australian - halve to obtain US pricing). When I rang the company, the sales rep - who seemed to know Postscript quite well - said that he had been using it for some months. Re the showpage hidden ops. Presumably Adobe will publish them when they release full font details. Would anyone from Adobe like to comment? One option to find these special "unlisted" instructions is to dump the ROM contents using the PEEK operator posted a couple on months ago. If you look around, you can see the table containing all of the commands. Most of these are listed, but there are some very interesting others. When I tried some of these, I found that I was locked out (some cursing in the general direction of Adobe Corp. ensued...), but some others worked. Unfortunately I have neither the time nor the desire to chase this further. You will also find a ML montior at the start of the ROMs. It would be nice if somebody could figure out hot to get into it. D
roussos@cs.arizona.edu (George E. Roussos) (12/12/89)
In article <POLLACK.89Dec5120903@toto.cis.ohio-state.edu> pollack@cis.ohio-state.edu writes: >OK, I called Emerald City, and LASERTALK is NOT available for the PC, >only the MAC. Perhaps the person you spoke with was mis-informed, but there does exist a LaserTalk for the PC which runs under MS Windows. I have used it before. They had been advertising it in Doctor Dobbs Journal for a good part of 1989 as I recall george
pollack@toto.cis.ohio-state.edu (Jordan B Pollack) (12/12/89)
Sorry for the mis-information posted. I called Emerald City AGAIN after finding LASERTALK/PC in a catalog, and it seems that either their technical rep misspoke, or I misheard! It is available, running under windows, for quite a bit more$ than the Mac version. (I also found that you need 2 serial ports to run it; one for the mouse and one for the printer; so its out of the question right now for my laptop!) Jordan
woody@rpp386.cactus.org (Woodrow Baker) (12/12/89)
In article <28@macuni.mqcc.mq.oz>, ifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar) writes: > In article <POLLACK.89Dec5120903@toto.cis.ohio-state.edu> pollack@cis.ohio-state.edu writes: > >OK, I called Emerald City, and LASERTALK is NOT available for the PC, > >only the MAC. The technical representative thinks that a new header is > >placed on an EPSF file, and SHOWPAGE is replaced by an undocumented > >function whose access and description were purchased from Adobe. > > > This is very interesting, as I have in my hand an FAX from PICA > Australia, giving details and price for Lasertalk PC available NOW > (price $995 Australian - halve to obtain US pricing). When I rang the > company, the sales rep - who seemed to know Postscript quite well - said > that he had been using it for some months. > > Re the showpage hidden ops. Presumably Adobe will publish them when > they release full font details. Would anyone from Adobe like to > comment? > > One option to find these special "unlisted" instructions is to dump the > ROM contents using the PEEK operator posted a couple on months ago. If > you look around, you can see the table containing all of the commands. > Most of these are listed, but there are some very interesting others. > When I tried some of these, I found that I was locked out (some cursing > in the general direction of Adobe Corp. ensued...), but some others > worked. Unfortunately I have neither the time nor the desire to chase > this further. You will also find a ML montior at the start of the ROMs. > It would be nice if somebody could figure out hot to get into it. > > > D The Redstone monitor is indeed in the roms. It turns out that on version 38.0 and below, you can download s1-s9 records and alter registers. on ver sions above 38, you have to change a couple of bytes in the roms to make it available. I have the details for starting the monitor. It takes a special connector for the outside of the computer's serial port. I have some of them available fo $15.00 u.s, along with some documentation on the ml monitor. rather crude, but does work. There is a reference to a peek operator that was posted previously on this group. Does anyone know where I can get a copy of it? Many of the internal undocumented functions reside in an internal dictionary. Decrypting any adobe font (there was a decryptor that is floating around somewhere) will give you a magic number that unlocks internaldict. The newerones have goodies like superexec which bypasses nearly all invalid access messages (fonts still give you invalid access). There are several other neat and useful functions available also. I arrived at these quite independantly of Adobe. Cheers Woody Baker Postscript hacker, and consultant.
shaver@cs.iastate.edu (Dave Shaver) (12/15/89)
pollack@toto.cis.ohio-state.edu (Jordan B Pollack) writes: >Imagine being able to get >bitmaps for proprietary fonts back to the host! So I guess its >probably impossible without a lot of money. Not much money at all. 8-) Look at Don Lancaster's "Ask the Guru" column in the February 1989 issue of Computer Shopper. He shows how to do exactly what you're talking about. /\ Dave Shaver -=*=- CS Systems Support Group, Iowa State University \\ UUCP: {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver \/ Internet: shaver@atanasoff.cs.iastate.edu ...In stereo where available...
shaver@cs.iastate.edu (Dave Shaver) (12/15/89)
woody@rpp386.cactus.org (Woodrow Baker) writes: >Many of the internal undocumented functions reside in an internal dictionary. >Decrypting any adobe font (there was a decryptor that is floating around >somewhere) will give you a magic number that unlocks internaldict. The >newerones have goodies like superexec which bypasses nearly all invalid >access messages (fonts still give you invalid access). Take a look at Don Lancaster's "Ask the Guru" column, November 1988, Computer Shopper. He defines his "snoop" command like this: /snoop {1183615869 internaldict begin} def % activates superexec And describes it like this: "The snoop command will activate superexec for your use. For instance, if a forall gives you an invalidaccess error, a {forall} superexec often will not. The same trick will often work for {get} superexec. Calling snoop also does open up internal dict along with all its many strange and wonderous denizens. Very handy. And most interesting." [He goes on to describe the "hidden" FlxProc command.] Now, does anyone have the decryptor "floating about?" How about sharing? /\ Dave Shaver -=*=- CS Systems Support Group, Iowa State University \\ UUCP: {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver \/ Internet: shaver@atanasoff.cs.iastate.edu ...In stereo where available...
woody@rpp386.cactus.org (Woodrow Baker) (12/15/89)
In article <226@dino.cs.iastate.edu>, shaver@cs.iastate.edu (Dave Shaver) writes: > pollack@toto.cis.ohio-state.edu (Jordan B Pollack) writes: > > >Imagine being able to get > >bitmaps for proprietary fonts back to the host! So I guess its > >probably impossible without a lot of money. > > Not much money at all. 8-) Look at Don Lancaster's "Ask the Guru" > column in the February 1989 issue of Computer Shopper. He shows how to > do exactly what you're talking about. > > /\ Dave Shaver -=*=- CS Systems Support Group, Iowa State University > \\ UUCP: {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver > \/ Internet: shaver@atanasoff.cs.iastate.edu > > ...In stereo where available... Yes, provided you have the version of the printer with a DISK. Otherwise it can't be done. It depends on the grabbing of cached images off the hard disk. NOTE: the hard disk system is really buggy, so if you have one, be careful. cheers Woody
woody@rpp386.cactus.org (Woodrow Baker) (12/15/89)
In article <227@dino.cs.iastate.edu>, shaver@cs.iastate.edu (Dave Shaver) writes: > woody@rpp386.cactus.org (Woodrow Baker) writes: > > >Many of the internal undocumented functions reside in an internal dictionary. > >Decrypting any adobe font (there was a decryptor that is floating around > >somewhere) will give you a magic number that unlocks internaldict. The > >newerones have goodies like superexec which bypasses nearly all invalid > >access messages (fonts still give you invalid access). > > Take a look at Don Lancaster's "Ask the Guru" column, November 1988, > Computer Shopper. He defines his "snoop" command like this: > > /snoop {1183615869 internaldict begin} def % activates superexec > > And describes it like this: > > "The snoop command will activate superexec for your use. For > instance, if a forall gives you an invalidaccess error, a > {forall} superexec often will not. The same trick will often > work for {get} superexec. > > Calling snoop also does open up internal dict along with all > its many strange and wonderous denizens. Very handy. And most > interesting." > > [He goes on to describe the "hidden" FlxProc command.] > > Now, does anyone have the decryptor "floating about?" How about sharing? > > /\ Dave Shaver -=*=- CS Systems Support Group, Iowa State University > \\ UUCP: {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver > \/ Internet: shaver@atanasoff.cs.iastate.edu > > ...In stereo where available... One problem here, is that Don got this information about superexec from me. My biggest gripe, is that 1. he did not credit me, and 2. he published it, thus knocking a large contract out from under me. Authors have loud mouths sometimes. Super exec is only available on certain versions, I thing V 41 and greater. There is a way to hijack the ps printer for decryption. first download the errhandler. then edit the code and insert some random character in the encrypted part, keeping track of what and where. Send it to the printer, and it will cause an error. The stack will dump, and the decrypted code to that point can be read, alternately you can alter the error handlr to return the stackdump to the serial port, then you can capture it. This is admittedly slow, but works. This was discovered by Don, and published. Cheers Woody
amanda@mermaid.intercon.com (Amanda Walker) (12/16/89)
Don Lancaster's columns are overrated. He finds odd tidbits and then prints things that imply he knows more about what's going on. He hasn't said anything about what FlxProc does, or coloring procedures, or anything more interesting than various hacks to get character bitmaps back to his Apple II. He seems mainly interested in ways to treat a LaserWriter as a 300dpi raster printer. Grumble. Maybe he should buy a LaserJet :-). Unless you're debugging a new PS printer, what's the use of a ROM monitor, beyond being able to say "I know something you don't know?" Except for Type 1 fonts, I generally find that when I want to do something that Adobe doesn't document, it's because I'm approaching the problem in the wrong way. LaserTalk is the only real exception, and that's only because Adobe keeps not shipping Display PostScript for the Macintosh, even though they also keep showing it at MacWorld as a "technology demonstration." I suppose I can understand that they want Apple to support it, but this seems to be an unrealistic hope at this point, and the success of ATM seems to show that real live Display PostScript would have a pretty high demand in the Macintosh market... Amanda Walker InterCon Systems Corporation --
woody@rpp386.cactus.org (Woodrow Baker) (12/18/89)
In article <1634@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > Don Lancaster's columns are overrated. He finds odd tidbits and then prints > things that imply he knows more about what's going on. He hasn't said > anything about what FlxProc does, or coloring procedures, or anything more > interesting than various hacks to get character bitmaps back to his Apple > II. He seems mainly interested in ways to treat a LaserWriter as a 300dpi > raster printer. Grumble. Maybe he should buy a LaserJet :-). > > Unless you're debugging a new PS printer, what's the use of a ROM monitor, > beyond being able to say "I know something you don't know?" > > Except for Type 1 fonts, I generally find that when I want to do something > that Adobe doesn't document, it's because I'm approaching the problem in > the wrong way. LaserTalk is the only real exception, and that's only because > Adobe keeps not shipping Display PostScript for the Macintosh, even though > they also keep showing it at MacWorld as a "technology demonstration." > > I suppose I can understand that they want Apple to support it, but this > seems to be an unrealistic hope at this point, and the success of ATM seems > to show that real live Display PostScript would have a pretty high demand > in the Macintosh market... > > Amanda Walker > InterCon Systems Corporation > -- True. Don lives in an APPLE II world. You are wrong, however in certain statements. He has (unfortunatly) mentioned what FLXPROC does. It happens to be critical to certain things, that several consultants are working on here and there. He knows enough not to blab some things, and jerk work out from under individuals(at least some of the time). Don has dug pretty deeply into certain areas of PS, and I have dug deeply into other areas of PS. Don is first and formost a writer. He's self employed, and extremely intellegent. I am first and formost a software engineer, and secondly a writer. I tend to write, however for clients. I'm confident that I know what FLXPROC does, and what it is good for. And I'm sure Don does also. I more or less told him about FLXPROC and he more or less told me what it does. After first quarter 1990, some things will be essentially worthless as consulting info, and will rapidly become public knowlege. I don't applogize for keeping the lid on some things. I'm a bit of a mercenary in a way. I like consulting. Cheers Woody
ifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar) (12/18/89)
In article <226@dino.cs.iastate.edu> shaver@cs.iastate.edu (Dave Shaver) writes: >pollack@toto.cis.ohio-state.edu (Jordan B Pollack) writes: > >>Imagine being able to get >>bitmaps for proprietary fonts back to the host! So I guess its >>probably impossible without a lot of money. > >Not much money at all. 8-) Look at Don Lancaster's "Ask the Guru" >column in the February 1989 issue of Computer Shopper. He shows how to >do exactly what you're talking about. > I cannot get Computer Shopper. How would someone like to post a summary of this article for all of us poor souls in this unfortunate position? D
amanda@mermaid.intercon.com (Amanda Walker) (12/19/89)
Urrrkh. Woody, you're starting to sound like Don :-). What's the big secret? Anyone with a modicum of intelligence who looks at an unencrypted Adobe font can figure out what the purpose of most of it is. With all of Don's emphasis on "pixel locking" and so on, I'm surprised he hasn't written an article about FlxProc and shown how it actually works, and how such techniques can be useful in general in PostScript programming, rather than just saying "look at what I found." Look, I respect him as an engineer and a writer. I've got several of his books on the shelf next to my desk, for example, and I think his "Incredible Secret Money Machine" is one of the best books on being a technology entrepreneur that has ever been written. I also think his columns talking about alternative binding methods and printing materials are very well done and are a distinct service to the on-demand publishing community. However, when he starts talking about PostScript itself, he seems to go off into left field (sort of like the the Monty Python skit where the guy puts a bag over his head whenever someone says "matress" :-)). After reading his columns for several years I still haven't figured out what axe he's trying to grind against Adobe, beyond "they didn't want me to take it apart," which sounds a little childish even from a hacker from way back. Sigh. Maybe I just don't have enough sense of the mysteriousness of PostScript, but all of the things that Don takes so much glee in "revealing" seem quite straightforward to me, such as: - Deglitching Bezier contours in device space (FlxProc) - Rounding overall font parameters in device space (BlueValues et al.) - Compensating for characteristics of the marking engine (Erosion functions and parameters) - Factoring out common features such as serifs, bows, and so on (Subrs) - Encoding glyph contours and composite characters in as compact a format as possible (Subrs and CharStrings) - Fulfilling license agreements with typeface manufacturers to prevent people from easily obtaining outline representations of characters (encrypted fonts and the infamous charpath "lockout" on pathforall). These aren't evil, secret things, folks... These are things that *should* be in an sophisticated page imaging system. The main reason that I'm waiting with bated breath for the Type 1 font format description isn't so that I can peek at Adobe fonts, or because it's a "secret finally seeing the light of day," but because it will give me the tool I need to build fonts that are both "hinted" and compact, at the same time. One thing I do get irritated about is reinventing wheels :-)... If I want to satisfy my hackerish impulses, I can think of a lot more rewarding things to take apart than my laser printer's intepreter... Grumble. Amanda Walker InterCon Systems Corporation --
shaver@cs.iastate.edu (Dave Shaver) (12/19/89)
amanda@mermaid.intercon.com (Amanda Walker) writes: >[Talking about Don Lancaster's PostScript stuff] >What's the big secret? [...] >However, when he starts talking about PostScript itself, he seems to go >off into left field [...] (My biggest bitch is that he publishes his PostScript source in "crunched" mode without any comments or indentation. Argh.) >Maybe I just don't have enough sense of the mysteriousness of PostScript, >but all of the things that Don takes so much glee in "revealing" seem >quite straightforward to me, such as: > - Deglitching Bezier contours in device space (FlxProc) > - Rounding overall font parameters in device space (BlueValues et al.) > - Compensating for characteristics of the marking engine (Erosion functions > and parameters) > - Factoring out common features such as serifs, bows, and so on (Subrs) > - Encoding glyph contours and composite characters in as compact a format as > possible (Subrs and CharStrings) > - Fulfilling license agreements with typeface manufacturers to prevent > people from easily obtaining outline representations of characters > (encrypted fonts and the infamous charpath "lockout" on pathforall). >These aren't evil, secret things, folks... These are things that *should* >be in an sophisticated page imaging system. Agreed. Then again, they should not only be in the imaging system, but they *should* be documented, too. I think that's the point Don (and many others) are trying to make. The red, blue, and (to a degree) green books don't really tell you what it's like to write PostScript "in the real world." "Real World Postscript" edited by Stephen Roth is the only book I've found so far that gives any real inside peeks into "real life." Then again, I'm just a novice PostScript hacker, so you wizards can feel free to tromp on this posting... 8-) /\ Dave Shaver -=*=- CS Systems Support Group, Iowa State University \\ UUCP: {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver \/ Internet: shaver@atanasoff.cs.iastate.edu ...In stereo where available...
amanda@mermaid.intercon.com (Amanda Walker) (12/19/89)
In article <246@dino.cs.iastate.edu>, shaver@cs.iastate.edu (Dave Shaver) writes: > The red, blue, and (to a degree) green books don't really tell you what > it's like to write PostScript "in the real world." "Real World > Postscript" edited by Stephen Roth is the only book I've found so far > that gives any real inside peeks into "real life." "Inside PostScript" by one of the engineers at QMS is good too. > Then again, I'm just a novice PostScript hacker, so you wizards can > feel free to tromp on this posting... 8-) Oh, you're much less annoying than Woody... :-). I do admit that I don't spend much time trying to eke the most out of 300dpi the way Don Lanacaster and Woody seem to, and that probably biases me. When I think of "real world" issues I think of things like: - Managing font downloads so as not to run out of VM in a LaserWriter - Finding good halftone frequencies and angles at 2540 dpi for doing color seps on a Linotron at >120 lpi - Finding the most effective compromises between doing computation in the printer and on the host for a particular job In part because of these and similar issues, I tend to think of a LaserWriter as a previewer for a typesetter, not as the ultimate in 300dpi printing. I want any PostScript that I write to work just as well on an L300 or a QMS ColorScript as it does on the LaserWriter downstairs. If it doesn't, I've goofed. The Red Book is sort of like Inside Macintosh--it's great if you already know what you're looking for. I admit that there's a lack of many good intermediate material on PostScript (although both "Real World PostScript" and the Green Book are very good), and that this can be a stumbling block. On good days, even Don's columns are good--he's certainly clever, and isn't afraid to get his readers' hands dirty... :-). His first set of columns about the halftone mechanism and how to trade better resolution against fewer gray levels was excellent, for example. His tirades against AppleTalk and Adobe, though, do get boring after the first couple of years... Amanda Walker InterCon Systems Corporation --
woody@rpp386.cactus.org (Woodrow Baker) (12/20/89)
In article <1637@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > Urrrkh. Woody, you're starting to sound like Don :-). > > What's the big secret? Anyone with a modicum of intelligence who looks at > an unencrypted Adobe font can figure out what the purpose of most of it is. > With all of Don's emphasis on "pixel locking" and so on, I'm surprised he > hasn't written an article about FlxProc and shown how it actually works, > and how such techniques can be useful in general in PostScript programming, > rather than just saying "look at what I found." Look, I respect him as an > engineer and a writer. I've got several of his books on the shelf next to > my desk, for example, and I think his "Incredible Secret Money Machine" is > one of the best books on being a technology entrepreneur that has ever been > written. I also think his columns talking about alternative binding methods > and printing materials are very well done and are a distinct service to the > on-demand publishing community. > > However, when he starts talking about PostScript itself, he seems to go > off into left field (sort of like the the Monty Python skit where the > guy puts a bag over his head whenever someone says "matress" :-)). After > reading his columns for several years I still haven't figured out what > axe he's trying to grind against Adobe, beyond "they didn't want me to > take it apart," which sounds a little childish even from a hacker from way > back. > > Sigh. > > Maybe I just don't have enough sense of the mysteriousness of PostScript, > but all of the things that Don takes so much glee in "revealing" seem > quite straightforward to me, such as: > > - Deglitching Bezier contours in device space (FlxProc) > - Rounding overall font parameters in device space (BlueValues et al.) > - Compensating for characteristics of the marking engine (Erosion functions > and parameters) > - Factoring out common features such as serifs, bows, and so on (Subrs) > - Encoding glyph contours and composite characters in as compact a format as > possible (Subrs and CharStrings) > - Fulfilling license agreements with typeface manufacturers to prevent > people from easily obtaining outline representations of characters > (encrypted fonts and the infamous charpath "lockout" on pathforall). > > These aren't evil, secret things, folks... These are things that *should* > be in an sophisticated page imaging system. The main reason that I'm waiting > with bated breath for the Type 1 font format description isn't so that I > can peek at Adobe fonts, or because it's a "secret finally seeing the light > of day," but because it will give me the tool I need to build fonts that > are both "hinted" and compact, at the same time. One thing I do get irritated > about is reinventing wheels :-)... > > If I want to satisfy my hackerish impulses, I can think of a lot more rewarding > things to take apart than my laser printer's intepreter... > > Grumble. > > Amanda Walker > InterCon Systems Corporation > -- A most enlightening post. I quite agree, that some of Dons's things are off the wall. I STILL haven't figured out what is so hot about "rubbergridding" However, most of these things that you feel are simple, are, but they were dug out with much effort. It wasn't until fairly recently, that the encryption scheme was craked. You seem to have all of the information on hand dealing with the hinted, compacted fonts. You seem to have some that I've been lacking and given that, I could long ago have created goodlooking, hinted fonts. Get with it. Cheers Woody Baker
ccain@ibmpcug.co.uk (chris cain) (12/21/89)
In article <17448@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > In article <226@dino.cs.iastate.edu>, shaver@cs.iastate.edu (Dave Shaver) writes: > > pollack@toto.cis.ohio-state.edu (Jordan B Pollack) writes: > > > > >Imagine being able to get > > >bitmaps for proprietary fonts back to the host! So I guess its > > >probably impossible without a lot of money. > > ...In stereo where available... > > Yes, provided you have the version of the printer with a DISK. Otherwise > it can't be done. It depends on the grabbing of cached images off the hard > disk. NOTE: the hard disk system is really buggy, so if you have one, be > careful. Is this realy the issue they are woried about ? . I have a program I wrote which takes a type 1 adobe font as input and draws the characters in large type on an EGA screen. I'ts in c and does not even need a postscript printer attached ie it directly decodes the font I would post it if anyone is interested and someone could assure me that I would't be sued by adobe for doing so !! The way the fonts work is realy very simplistic once you get past the rather feeble attempt at encryption on adobes part . An interesting sidepoint to the hinting is that it distorts the font shapes badly enough that in a large number of adobe fonts 2 complete sets of outline data is included one used for devices below 600dpi with a regularised outline and hints and one uses no hints for devices more than 600dpi using presumably the undistorted font shape. What price resolution independance now !. -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group.
rcd@ico.isc.com (Dick Dunn) (12/21/89)
woody@rpp386.cactus.org (Woodrow Baker) writes: > ...You are wrong, however in certain > statements. He has (unfortunatly) mentioned what FLXPROC does. It happens > to be critical to certain things, that several consultants are working on here > and there. He knows enough not to blab some things, and jerk work out from > under individuals(at least some of the time)... I'm not entirely sure I understand what's going on here, but it sure sounds like you're saying that people are doing consulting based on digging out undocumented features and using them. Sure sounds bizarre... -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
mills@adobe.com (Dan Mills) (12/22/89)
In article <1989Dec20.200005.13075@ibmpcug.co.uk> ccain@ibmpcug.co.uk (chris cain) writes: > ... > An interesting sidepoint to the hinting is that it distorts the font > shapes badly enough that in a large number of adobe fonts 2 complete > sets of outline data is included one used for devices below 600dpi > with a regularised outline and hints and one uses no hints for devices > more than 600dpi using presumably the undistorted font shape. What price > resolution independance now !. > ... Hogwash. The hints don't distort anything. Nor does the rendering software which makes use of those hints. The specification of the Type 1 font format, available 1st Qtr '90, will make this abundantly clear. And by the way, the "large number" of fonts with two complete sets of outline data is exactly 10. That's less than 2% of today's library, and since we have no intention of creating more such fonts, that percentage will only decrease. Dan Mills Manager of Typography Adobe Systems Incorporated
ccain@ibmpcug.co.uk (chris cain) (12/23/89)
In article <1546@adobe.UUCP> mills@adobe.COM (Dan Mills) writes: > > Hogwash. The hints don't distort anything. Nor does the rendering software > which makes use of those hints. The specification of the Type 1 font format, > available 1st Qtr '90, will make this abundantly clear. > > And by the way, the "large number" of fonts with two complete sets of > outline data is exactly 10. That's less than 2% of today's library, and > since we have no intention of creating more such fonts, that percentage will > only decrease. > > Dan Mills > Manager of Typography > Adobe Systems Incorporated I can only ask if the hint's distort nothing why do you need 2 sets of outline data in ANY fonts. I could see only 2 possible reasons either the hinting required some compromise to the outline shape or there were some founts which the hinting needed to start from a distorted outline and then hinted it back to the correct shape. A press release from Bitstream when they released Type 1 fonts suggested that they had not used hints because of the compromises requred to the outline shape to produce the hinted fonts. Now this may have been ad hype on the part of Bitstream and it may have caused me to jump to an incorrect conclusion on seeing the 2 outline fonts but that is part of the penalty you have to pay for having closed technology fonts. People will guess about what you are doing and why you are doing it they may guess wrong but we are all human (mostly) and so make misteaks. I'm sorry about the large number comment it was probably foolish comeing as it did from a sample of about 6 fonts where 2 had double data sets so I must have been lucky (unlucky?) in hitting so high a percentage. I have had a large number of requests for the program so perhaps you can comment on Adobes position on a posting of this program ?. Chris Cain -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group.
woody@rpp386.cactus.org (Woodrow Baker) (12/25/89)
Chris, It doesn't matter what Adobies policy is. They don't control the net, or free speech. Sure, they won't want you to post it. Post itt anyway. It's really none of thier business. We live in the land of the free, and you can say anything you want. Cheers Woody
mills@adobe.com (Dan Mills) (12/28/89)
In article <1989Dec22.210230.863@ibmpcug.co.uk> ccain@ibmpcug.co.uk (chris cain) writes: >I can only ask if the hint's distort nothing why do you need 2 sets of outline >data in ANY fonts. I could see only 2 possible reasons either the hinting >required some compromise to the outline shape or there were some founts >which the hinting needed to start from a distorted outline and then >hinted it back to the correct shape. A press release from Bitstream >when they released Type 1 fonts suggested that they had not used hints >because of the compromises requred to the outline shape to produce the >hinted fonts. Now this may have been ad hype on the part of Bitstream and >it may have caused me to jump to an incorrect conclusion on seeing the >2 outline fonts but that is part of the penalty you have to pay for >having closed technology fonts. People will guess about what you are >doing and why you are doing it they may guess wrong but we are all human >(mostly) and so make misteaks. > >I'm sorry about the large number comment it was probably >foolish comeing as it did from a sample of about 6 fonts where 2 had double >data sets so I must have been lucky (unlucky?) in hitting so high a percentage. >I have had a large number of requests for the program so perhaps you can >comment on Adobes position on a posting of this program ?. A few fonts have a second set of outlines because their design makes extensive use of features that are especially difficult to render on raster output devices. Optima* has very shallow curves that are nearly horizontal or vertical. ITC Eras(R) is very slightly slanted. Simply put, we couldn't get decent results so we made "simplified" versions for use at low resolution. It has very little to do with hints, except to the extent that the hints failed to work their magic adequately. My original vehemance was in response to your statement that hinting "distorts the font shapes badly". The vast majority of our hints don't modify the outlines at all, so they couldn't possibly distort them. Our hints are declarative rather than procedural. They just state some fact about a character or set of characters -- a fact that would be difficult or time consuming to derive on the fly. It is up to the rasterizing algorithm to use this information to achieve the desired results. In short, the smarts are mostly in the rasterizer, not in the fonts. The primary advantage of this is that you don't completely obsolete the installed base of fonts every time you get a great new idea about how to render characters. (Adobe Type Manager is a shining example of this.) Sorry, I obviously can't comment on legal issues relating to your program. Since the font format will be publicly available in a matter of weeks, it will soon be a moot question. - Dan Mills ITC Eras is a registered trademark of International Typeface Corporation. * Optima is a trademark of Linotype AG and/or its subsidiaries.
shaver@cs.iastate.edu (Dave Shaver) (12/29/89)
mills@adobe.com (Dan Mills) first writes in <1546@adobe.UUCP>: > The specification of the Type 1 font format, > available 1st Qtr '90, will make this abundantly clear. Then writes in <1565@adobe.UUCP>: >Since the font format will be publicly available in a matter of weeks, it >will soon be a moot question. Several quick questions: - How does one get a copy of the format? - Define "publicly available". e.g.: (a) Will I be able to get it off of the Adobe file server -or- (b) will I have to pay $X for it? If the answer is (b), then what amount is X? /\ Dave Shaver -=*=- CS Systems Support Group, Iowa State University \\ UUCP: {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver \/ Internet: shaver@atanasoff.cs.iastate.edu ...In stereo where available...