pollack@toto.cis.ohio-state.edu (Jordan B Pollack) (03/07/90)
Let us imagine a scenario where a talented software engineer cloned a standard product and did amazingly thoughtful work extending it in the realms of human factors and communication efficiency. After presenting the new specification and prototype work to his company, management vetoed all of it because it violated the marketplace "standard." Management went further, and placed a "gag order" on said engineer, forbidding him to release his ideas as they might be very valuable to the company, SOMEDAY. Such a deadly embrace could certainly cause a crash of a person's operating system. So, rather than getting offended or embarrassed by the public display of incoherence, some of us should ignore the garbage and go right for the crucial piece of core dump: >> 1. Why are Adobe and SUN using a compact, binary format in Display Post- >> Script, but only a readable format in Printer PostScript? >> 2. Why cannot Adobe propose a standard binary format for Printer Post- >> Script that could be implemented in all PostScript interpreters, so >> that our printer drivers can produce PostScript programs that would >> be up to 10 times shorter than the programs written in readable format? (I assume that Sun DPS actually means NeWS, which may be bigger than Sun at this point) Certainly performance could be improved at the expense of field reprogramming. This sounds like a job for a small company, selling "faster postscript" for about $25/printer to printer owners, first for the Mac, then for Windows, then custom drivers for WordPerfect, then for Illustrator, Freehand, Designer, Ventura...eventually, when it became a standard, more money could be made by licensing to the software companies themselves, or even to Adobe, if your technology was well protected. >> 3. Why don't we improve the user interface programs which allow you to use >> PostScript interpreters in interactive or executive mode, so that they >> are at least as good as the programs which allow you to use a BASIC >> interpreter interactively? Forth doesn't seem to have a better interface than ps, and yet appears to be accepted. This is because the feedback from a command issued is a pretty immediate result. Even if the ps programming environment was improved (to APL or LISP quality with break, trace, debug, and stubs), there is still a problem in that the feedback is a (slowly) rendered image! I thought about this last time it by in Ivan's samizdat and could really use a utility where editing changes in postscript would be dynamically linked to a display. Currently I develop my custom postscript by an rapid emacs/psview loop wth occasional printing, and have considered linking the two through some process-filter. The really tough problem is that instantaneous changes in the postscript prose can cause error or severe change in the rendered image! one character changed can erase your page. When should the display be updated, and how can it be done smoothly? The first step would be a "syntax-oriented" editor which only allowed legal ps to be written. This would require the dynamic maintenance of the dependency structure of the program. I suppose this could be within gnu emacs. The dictionary structure of the printer/process in question must be accessible.. The second step would be a display which automatically zoomed in and out to show where your figure is wrt the page. The third step would be to worry about efficiency, i.e. how to have incremental display, minimizing the change in display when the text is changed. This is why most people opt for WYSIWYG graphics editors with more limited capabilities, but a smooth control over the layout! >> 4. Why don't we improve our application programs in such a way that they >> give us full access to the power of PostScript, so that we do not have >> to program in PostScript directly? I suppose it would be possible to build an wysiwyg editor with a macro feature which mapped directly to postscript; Having written a Macdraw-like graphics-editor (in Interlisp) in graduate school, I believe it won't be too easy. -- Jordan Pollack Assistant Professor CIS Dept/OSU Laboratory for AI Research 2036 Neil Ave Email: pollack@cis.ohio-state.edu Columbus, OH 43210 Fax/Phone: (614) 292-4890