8 ms·

To my eyes, NeWS does not look like a mistake. On the contrary, it looks beautifully engineered. Among other advantages, I can imagine a world where PostScript

To my eyes, NeWS does not look like a mistake. On the contrary, it looks beautifully engineered. Among other advantages, I can imagine a world where PostScript would be used for building user interfaces: a document in screen and print would look the same, without need for writing conversions like, e.g. HTML+SVG -> PDF when someone needs to somehow print a web form quickly. And perhaps the old principles of typography and the experience in typesetting beautiful books with PostScript could be more easily applied to UI design.

crooked-v 7y ago
> a document in screen and print would look the same This only works if all the screens are the same size as a sheet of paper.
- japanoise 7y ago
  And have the same dpi as whatever's used to print them!
  - basementcat 7y ago
    I can print the same PS file to different printers (inkjet, laser, dot matrix) and (subject to resolution constraints) obtain similar documents from each device.
- triska 7y ago
  A key advantage of PostScript is that you can scale all output using transformations, so that you internally work with the same coordinate space (called user space) on all devices, and implicitly scale — and also for example rotate — all graphics when they are actually drawn. This extends to fonts too, since PostScript letters are drawn using the same graphic primitives as other graphs.
  - arethuza 7y ago
    I worked on a project in the early 1990s where we used the utterly wonderful HyperNeWS for most things - we used to play tricks on each other by doing silly things like logging into someone else's NeWS server using psh and setting the rotation in the transforms for a terminal window to be slightly off as people were using them - eventually people would notice of course but things would just work. Another neat trick that HyperNeWS supported was drawing a shape in its graphical editor and then pasting that shape as the shape of a window...
    - nibbula 7y ago
      My friend and I had an ongoing competition / psychological experiment to psh into each other's NeWS servers and see how long it was before we would notice a some semi-subliminal or mildly psychedelic window system hack.
  - pmontra 7y ago
    Circa 1990 I was working/studying in university on a mix of 1024x1024 1 bit per pixel XTerminals and workstations (Sun, Apollo?) with somewhat better resolutions and colors. We had one NeXT too. Printers where mostly dot matrix, with some lasers, A4 format (Europe here). Nothing would have prevented sending a Postscript screen output to a printer, with some white space around due to different geometries. Actually I learned Postscript in 1996 to print some stuff directly instead of drawing it using Word or whatever.
- radiator 7y ago
  Well, I have some questions now: - Is it necessary that the document should take the whole screen? - Is it possible to render a PostScript document in different sizes and resolutions? - Do any people today read PDFs on their screens? If some do, are all their screens the same size as a sheet of paper? Anyway, that was not the spirit of my comment. I meant, doing design in HTML, CSS, SVG and then working out again, all from the beginning, how to convert the document to a printable version of professional quality, is more work than writing PostScript for both, even if some configuration necessarily differs between screen and print.
  - DonHopkins 7y ago
    There are definitely a lot of difficult issues and trade-offs about implementing true "WYSIWYG" editors that let you layout text and graphics that looks exactly the same on the screen and when printed. This Cedar demonstration video has some great examples of many of these issues. The Tioga text editor was "WYSIMOLWYG": what you see is more or less what you get. https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 Some problems were due to technology and aren't as bad any more. Cedar and NeWS used black-and-white screens and didn't have anti-aliased fonts. CPUs were much slower and memory was much tighter and graphics were not accelerated, so even with color displays (which were usually only 8 bits with a colormap that makes anti-aliasing very difficult), anti-aliased text wasn't practical. And fonts rendered at screen resolutions have totally different measurements than high resolution printed fonts, so words have different widths and get flowed and wrapped differently, so the formatting is quite different. NeWS had a "setprintermatch" primitive that makes the font rendering machinery use the official precise printer measurements for fonts, instead of the actual pixel screen measurements. That was useful for the PostScript previewer, and for editors previewing how formatted text will look. (There was a nice port of FrameMaker to NeWS, but I don't remember how its preview features worked.) But text rendered with printer metrics looks terrible and is hard to read, so you wouldn't want to actually edit text like that. NeWS 1.1 manual, page 146: http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801.pdf http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801... >setprintermatch: (boolean setprintermatch - ) Sets the current value of the printermatch flag in the graphics state to boolean. When printer matching is enabled text output to the display will be forced to match exactly text output to a printer. The metrics used by the printer will be imposed on the display fonts. This will usually cause displayed text to look bunched up and generally reduce readability. With printer matching disabled, readability will be maximized, but the character metrics for the display will correspond to the printer. See also: currentprintermatch Windows are resizable, and while text is scalable, you still want to be able to read and edit text in narrow windows, and not waste screen space or get giant text in wide windows. So reflowing text differently for the screen while editing is very useful. Also, rendering text in a wysiwyg previewer that precisely scales text is slow the first time and uses a lot of memory, because the particular point size of that font must be rendered into the cache, since it can't just round the point size to a whole number that may already be in the cache (like the scalable "jet" NeWS terminal emulator did to avoid blowing the cache). So it's better if the system renders all text in the same restricted set of point sizes, instead of scaling it continuously. Also it's costly in terms of screen space to edit two columns of text at once, or pages at a time. It's just ergonomically easier and wastes less screen space to edit formatted text in one continuous non-paginated column, resizable to any window width you want to use at the time, formatted as close as possible to how it will look on the printer, but without the exact same measurements. And in this day and age, most text that people write is intended to be read in many different media, formats, screen and font sizes, and layouts. Now it's about WYSIWYG editing text and graphics in the way they will appear in a web browser, and those come in all shapes and sizes (thus Chrome Developer Tool's device preview mode). Now printing text on paper is only an afterthought, something wasteful to be avoided. So fewer people actually need to edit two-column paginated text just like it will appear printed on paper in a journal, or fuss about exact text layout and worry about terrible "rivers" ruining their otherwise perfectly justified paragraphs. https://en.wikipedia.org/wiki/River_(typography) https://en.wikipedia.org/wiki/River_(typography) https://en.wikipedia.org/wiki/WYSIWYG https://en.wikipedia.org/wiki/WYSIWYG WYSIAWYG; what you see is almost what you get, similar to WYSIMOLWYG. WYSIMOLWYG, what you see is more or less what you get, recognizing that most WYSIWYG implementations are imperfect. http://foldoc.org/WYSIWYG http://foldoc.org/WYSIWYG What You See Is What You Get <jargon> (WYSIWYG) /wiz'ee-wig/ Describes a user interface for a document preparation system under which changes are represented by displaying a more-or-less accurate image of the way the document will finally appear, e.g. when printed. This is in contrast to one that uses more-or-less obscure commands that do not result in immediate visual feedback. True WYSIWYG in environments supporting multiple fonts or graphics is rarely-attained; there are variants of this term to express real-world manifestations including WYSIAWYG (What You See Is Almost What You Get) and WYSIMOLWYG (What You See Is More or Less What You Get). All these can be mildly derogatory, as they are often used to refer to dumbed-down user-friendly interfaces targeted at non-programmers; a hacker has no fear of obscure commands (compare WYSIAYG). On the other hand, Emacs was one of the very first WYSIWYG editors, replacing (actually, at first overlaying) the extremely obscure, command-based TECO. See also WIMP.
- deleted 7y ago
  [deleted]
- DonHopkins 7y ago
  In this video of Eric Bier and his colleagues from Xerox PARC demonstrating Cedar, they discuss writing resolution independent applications, and the problem and approaches to matching the text and formatting displayed on the screen, with how it looks when printed: https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 >Eric Bier Demonstrates Cedar. Computer History Museum, Recorded on January 24, 2019. >This interpretive production was created from archival footage of Eric Bier, PARC research scientist, demonstrating the Cedar integrated environment and programming language on January 24, 2019. Cedar was an evolution of the Mesa environment/language, developed at PARC’s Computer Science Laboratory originally for the Xerox Alto. Mesa was modular and strongly-typed, and influenced the later Modula family of languages. Cedar/Mesa ran on the D-machine successors to the Alto (such as the Dorado) and added features including garbage collection, and was later ported to Sun workstations. Cedar/Mesa’s integrated environment featured a graphical window system and a text editor, Tioga, which could be used for both programming and document preparation, allowing for fonts, styles, and graphics to be embedded in code files. The editor and all its commands were also available everywhere, including on the command console and in text fields. The demo itself is running through a Mac laptop remotely logged into Bier’s Sun workstation at PARC using X Windows. Bier demonstrates the Cedar development environment, Tioga editor, editing commands using three mouse buttons, sophisticated text search features, the command line, and the Gargoyle graphics editor, which was developed as part of Bier’s UC Berkeley Ph.D. dissertation. Bier is joined by Nick Briggs, Chris Jacobi, and Paul McJones. Here are some notes about that I took: There were several window systems developed for Cedar: Warren Teitelman developed Docs. Lots of functionality, but slow. Scott McGregor developed Viewers. It was lean and fast, in response to Docs. Michael Plass built the Cedar imager. The Experimental Programming Environment Research Project looked at different competing projects to decide which to standardize on. Cedar/Mesa came out of that and played a dominant role in the 80's. The Smalltalk people contributed ideas but were (not railroaded but) frustrated. Cedar had a ubiquitous almost-wysiwyg structured text and code editor called Tioga. It was important in Cedar, because it's everywhere, even the text fields. The terminal window has a stripped down text editor with subset of commands. Setting the so-called "clipping level" in Tioga (like a folding outliner) goes back to Englebart's NLS. Bill Paxton and Doug Wyatt were NLS people who also worked on Tioga. Key ideas were applicable in any possible place in both systems. The Alto had small memory, and each program took over the entire system. It was not integrated. Simple little editors for code. Fancier editors for documents. Using the same component everywhere is something Smalltalk was pioneering even on the tiny Alto. When Cedar came along, running on a much bigger more powerful 1 megabyte D-Machines, it pulled together those ideas, and added so much more, including much more advanced graphics, way beyond what the Alto could do. Tioga could display and edit formatted code with different levels of indentation and formatting. Tioga was not completely WYSIWYG. Print mode shows two columns, but you edit one column. You could get a pretty good idea of what it would look like, but in the early times it did not have smooth fonts. Bitmap fonts measure differently on the printer, so text is necessarily broken and flowed differently. The printer used Interpress, the predecessor of PostScript. You could preview Interpress files in Cedar. (The video shows a demo of both editing a document in Tioga, and previewing the Interpress file that it produced for the printer.) Recently I wrote about the differences and similarities between Forth and PostScript, and the influences of Evans and Sutherland's "Design System" on John Warnock and Martin Newall's "Jam", then Jam's influence on John Warnock and Charles Geschke's "Interpress", then Interpress's influence on PostScript: https://news.ycombinator.com/item?id=21968175 https://news.ycombinator.com/item?id=21968175 >Kragen is right that PostScript is a lot more like Lisp or Smalltalk than Forth, especially when you use Owen Densmore's object oriented PostScript programming system (which NeWS was based on). PostScript is semantically very different and much higher level that Forth, and syntactically similar to Forth but uses totally different names (exch instead of swap, pop instead of drop, etc). >But its most obvious similarities with Forth are based on generic Computer Science concepts like stacks, which is not something particularly unique to Forth itself, so saying PostScript was influenced by Forth ignores other much more influential languages like Interpress, JaM, and Design System, which directly influenced PostScript and were designed by the same people. Also, PostScript is not threaded like Forth. But it's homoiconic, unlike Forth and Lisp. https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Martin_Newell_(computer_scientist) https://en.wikipedia.org/wiki/Martin_Newell_(computer_scient... The heavily commented PostScript source code of PizzaTool for NeWS shows Owen's OOP PostScript system in action: https://donhopkins.com/home/archive/NeWS/pizzatool https://donhopkins.com/home/archive/NeWS/pizzatool PostScript was a direct descendent of and heavily influenced by Xerox PARC's Interpress, by John Warnock and Charles Geschke, which itself was a direct descendent of JaM, which stands for "John and Martin", by John Warnock and Martin Newall. And JaM was a descendent of Evans and Sutherland's Design System, by John Warnock and John Gaffney. https://en.wikipedia.org/wiki/John_Warnock https://en.wikipedia.org/wiki/John_Warnock http://historyofinformation.com/detail.php?entryid=1213 http://historyofinformation.com/detail.php?entryid=1213 https://en.wikipedia.org/wiki/Martin_Newell_(computer_scientist) https://en.wikipedia.org/wiki/Martin_Newell_(computer_scient... https://en.wikipedia.org/wiki/Charles_Geschke https://en.wikipedia.org/wiki/Charles_Geschke https://en.wikipedia.org/wiki/Interpress https://en.wikipedia.org/wiki/Interpress https://en.wikipedia.org/wiki/Evans_%26_Sutherland https://en.wikipedia.org/wiki/Evans_%26_Sutherland Brian Reid (whose brother is Glenn Reid, author of several books on PostScript from Adobe) wrote up an excellent historical summary in 1985 on the laser-lovers mailing list of the influences and evolution of PostScript. https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist) https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist... http://glennreid.blogspot.com/ http://glennreid.blogspot.com/ Here's a post I wrote earlier: https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19874245 >DonHopkins 8 months ago [-] >Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other: https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us4h8S3Kk https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us... >By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools. There's more interesting discussion about the relationship between PostScript and Forth on c2: http://wiki.c2.com/?ForthPostscriptRelationship http://wiki.c2.com/?ForthPostscriptRelationship Here's a lot more stuff I've written about PostScript and Forth (two of my favorite topics!): https://news.ycombinator.com/item?id=11479364 https://news.ycombinator.com/item?id=11479364 https://news.ycombinator.com/item?id=13198492 https://news.ycombinator.com/item?id=13198492 https://news.ycombinator.com/item?id=13705664 https://news.ycombinator.com/item?id=13705664 https://news.ycombinator.com/item?id=13705739 https://news.ycombinator.com/item?id=13705739 https://news.ycombinator.com/item?id=18317280 https://news.ycombinator.com/item?id=18317280 https://news.ycombinator.com/item?id=18692144 https://news.ycombinator.com/item?id=18692144 https://news.ycombinator.com/item?id=18695275 https://news.ycombinator.com/item?id=18695275 https://news.ycombinator.com/item?id=18696116 https://news.ycombinator.com/item?id=18696116 https://news.ycombinator.com/item?id=19873630 https://news.ycombinator.com/item?id=19873630 https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19882301 https://news.ycombinator.com/item?id=19882301
basementcat 7y ago
Your post prompted me imagine a nightmare/utopia in which TeX was used for building user interfaces. This was followed by a vision of a window system built on ROFF.
- mhd 7y ago
  Someone taking a verbose format for writing text and adding feature and feature to it until it supports UI applications? Jesus, that's a horrific vision. Hope something like that will never see the light of day.
  - Jailbird 7y ago
    Perhaps all that will be implemented is character cell windowing systems. And Doom. Definitely Doom.
    - DonHopkins 7y ago
      Hurray for the MGR window system! https://hack.org/mc/mgr/ https://hack.org/mc/mgr/ https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR >ManaGeR or MGR was an early windowing system originally designed and developed for Sun computers in 1984 by Stephen A. Uhler, then at Bellcore. >MGR featured overlapped, asynchronous windows and an applications interface that was both machine and network independent. >Each MGR window had support for both character terminal operations as well as basic graphics operations. It was controlled by mousing pop-up menus, by keyboard interaction, and by escape sequences written on pseudo-terminals by client software. >The system was presented at the USENIX Fourth Computer Graphics Workshop in 1987 as "MGR - a Window System for UNIX".[1] The entire MGR source code was posted to the comp.sources.unix Usenet newsgroup, Volume 17, Issue 1, in January 1989.[2] MGR was the largest posting to ever appear in comp.sources.unix: https://groups.google.com/forum/#!topic/comp.sources.unix/GGMq2FNEI1A https://groups.google.com/forum/#!topic/comp.sources.unix/GG... Also Chris Torek, Mark Weiser and others developed "Maryland Windows" at the University of Maryland Computer Science Department, based on the Gosling Emacs screen redisplay code and terminal drivers. It was very good over slow modems because it used Emacs's intelligent redisplay algorithm aka "Ultra-hot screen management package" -- the one with the skull and crossbones. https://www.donhopkins.com/home/code/display.c.txt https://www.donhopkins.com/home/code/display.c.txt Maryland Windows source code: http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/XGsf97m7fA0J https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/... Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux.
Lammy 7y ago
> I can imagine a world where PostScript would be used for building user interfaces NeXT did that in 1988: https://en.wikipedia.org/wiki/Display_PostScript https://en.wikipedia.org/wiki/Display_PostScript
- DonHopkins 7y ago
  What NeXT missed out on is what we now call "AJAX": the advantages of implementing the user interface toolkit and the front-end parts of the application in PostScript, so it runs right next to the user, can can implement an efficient application specific networking protocol to communicate between the client and server. NeXT didn't have any of the advantages of NeWS and AJAX when run over the network. Just the stencil/paint imaging model. But no light weight processes, local event handling, object oriented programming, etc. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation.
  - DanielKehoe 7y ago
    Consider this. As we know, Tim Berners-Lee developed the first web browser on a NeXT computer, with Display Postscript to render HTML (and print it, too). Two years later, Marc Andreessen and Eric Bina developed the NCSA Mosaic web browser for the X Window System and Microsoft Windows. Another 2 years, and Brendan Eich made the Netscape Navigator web browser programmable with JavaScript. What if Sun had open sourced NeWS in the early 90s? Could NCSA or Netscape have used an open source NeWS to build a web browser that renders HTML using NeWS on X11 or Windows? With no need for JavaScript or CSS, just Postscript? Don Hopkins? Is it plausible that we’ve had 25 years of JavaScript hell because Sun management didn’t open source NeWS? Or were there insurmountable technical obstacles as well?
    - dboreham 7y ago
      Netscape succeeded because they had a 16-bit implementation. 16-bit postscript would have been a significant challenge.
gnufx 7y ago
My "hyperTeX" documents under NeWS looked pretty much the same on screen as printed, modulo hyperlinks, but I wouldn't want to write documents directly in PostScript. I'm unconvinced generally about the trades-off of markup in a non-macro programming language. Incidentally, the nascent web looked horribly primitive when you already had fairly rich networked hypermedia and missed the significance of the web architecture.

crooked-v 7y ago

> a document in screen and print would look the same This only works if all the screens are the same size as a sheet of paper.

japanoise 7y ago
And have the same dpi as whatever's used to print them!
- basementcat 7y ago
  I can print the same PS file to different printers (inkjet, laser, dot matrix) and (subject to resolution constraints) obtain similar documents from each device.
triska 7y ago
A key advantage of PostScript is that you can scale all output using transformations, so that you internally work with the same coordinate space (called user space) on all devices, and implicitly scale — and also for example rotate — all graphics when they are actually drawn. This extends to fonts too, since PostScript letters are drawn using the same graphic primitives as other graphs.
- arethuza 7y ago
  I worked on a project in the early 1990s where we used the utterly wonderful HyperNeWS for most things - we used to play tricks on each other by doing silly things like logging into someone else's NeWS server using psh and setting the rotation in the transforms for a terminal window to be slightly off as people were using them - eventually people would notice of course but things would just work. Another neat trick that HyperNeWS supported was drawing a shape in its graphical editor and then pasting that shape as the shape of a window...
  - nibbula 7y ago
    My friend and I had an ongoing competition / psychological experiment to psh into each other's NeWS servers and see how long it was before we would notice a some semi-subliminal or mildly psychedelic window system hack.
- pmontra 7y ago
  Circa 1990 I was working/studying in university on a mix of 1024x1024 1 bit per pixel XTerminals and workstations (Sun, Apollo?) with somewhat better resolutions and colors. We had one NeXT too. Printers where mostly dot matrix, with some lasers, A4 format (Europe here). Nothing would have prevented sending a Postscript screen output to a printer, with some white space around due to different geometries. Actually I learned Postscript in 1996 to print some stuff directly instead of drawing it using Word or whatever.
radiator 7y ago
Well, I have some questions now: - Is it necessary that the document should take the whole screen? - Is it possible to render a PostScript document in different sizes and resolutions? - Do any people today read PDFs on their screens? If some do, are all their screens the same size as a sheet of paper? Anyway, that was not the spirit of my comment. I meant, doing design in HTML, CSS, SVG and then working out again, all from the beginning, how to convert the document to a printable version of professional quality, is more work than writing PostScript for both, even if some configuration necessarily differs between screen and print.
- DonHopkins 7y ago
  There are definitely a lot of difficult issues and trade-offs about implementing true "WYSIWYG" editors that let you layout text and graphics that looks exactly the same on the screen and when printed. This Cedar demonstration video has some great examples of many of these issues. The Tioga text editor was "WYSIMOLWYG": what you see is more or less what you get. https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 Some problems were due to technology and aren't as bad any more. Cedar and NeWS used black-and-white screens and didn't have anti-aliased fonts. CPUs were much slower and memory was much tighter and graphics were not accelerated, so even with color displays (which were usually only 8 bits with a colormap that makes anti-aliasing very difficult), anti-aliased text wasn't practical. And fonts rendered at screen resolutions have totally different measurements than high resolution printed fonts, so words have different widths and get flowed and wrapped differently, so the formatting is quite different. NeWS had a "setprintermatch" primitive that makes the font rendering machinery use the official precise printer measurements for fonts, instead of the actual pixel screen measurements. That was useful for the PostScript previewer, and for editors previewing how formatted text will look. (There was a nice port of FrameMaker to NeWS, but I don't remember how its preview features worked.) But text rendered with printer metrics looks terrible and is hard to read, so you wouldn't want to actually edit text like that. NeWS 1.1 manual, page 146: http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801.pdf http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801... >setprintermatch: (boolean setprintermatch - ) Sets the current value of the printermatch flag in the graphics state to boolean. When printer matching is enabled text output to the display will be forced to match exactly text output to a printer. The metrics used by the printer will be imposed on the display fonts. This will usually cause displayed text to look bunched up and generally reduce readability. With printer matching disabled, readability will be maximized, but the character metrics for the display will correspond to the printer. See also: currentprintermatch Windows are resizable, and while text is scalable, you still want to be able to read and edit text in narrow windows, and not waste screen space or get giant text in wide windows. So reflowing text differently for the screen while editing is very useful. Also, rendering text in a wysiwyg previewer that precisely scales text is slow the first time and uses a lot of memory, because the particular point size of that font must be rendered into the cache, since it can't just round the point size to a whole number that may already be in the cache (like the scalable "jet" NeWS terminal emulator did to avoid blowing the cache). So it's better if the system renders all text in the same restricted set of point sizes, instead of scaling it continuously. Also it's costly in terms of screen space to edit two columns of text at once, or pages at a time. It's just ergonomically easier and wastes less screen space to edit formatted text in one continuous non-paginated column, resizable to any window width you want to use at the time, formatted as close as possible to how it will look on the printer, but without the exact same measurements. And in this day and age, most text that people write is intended to be read in many different media, formats, screen and font sizes, and layouts. Now it's about WYSIWYG editing text and graphics in the way they will appear in a web browser, and those come in all shapes and sizes (thus Chrome Developer Tool's device preview mode). Now printing text on paper is only an afterthought, something wasteful to be avoided. So fewer people actually need to edit two-column paginated text just like it will appear printed on paper in a journal, or fuss about exact text layout and worry about terrible "rivers" ruining their otherwise perfectly justified paragraphs. https://en.wikipedia.org/wiki/River_(typography) https://en.wikipedia.org/wiki/River_(typography) https://en.wikipedia.org/wiki/WYSIWYG https://en.wikipedia.org/wiki/WYSIWYG WYSIAWYG; what you see is almost what you get, similar to WYSIMOLWYG. WYSIMOLWYG, what you see is more or less what you get, recognizing that most WYSIWYG implementations are imperfect. http://foldoc.org/WYSIWYG http://foldoc.org/WYSIWYG What You See Is What You Get <jargon> (WYSIWYG) /wiz'ee-wig/ Describes a user interface for a document preparation system under which changes are represented by displaying a more-or-less accurate image of the way the document will finally appear, e.g. when printed. This is in contrast to one that uses more-or-less obscure commands that do not result in immediate visual feedback. True WYSIWYG in environments supporting multiple fonts or graphics is rarely-attained; there are variants of this term to express real-world manifestations including WYSIAWYG (What You See Is Almost What You Get) and WYSIMOLWYG (What You See Is More or Less What You Get). All these can be mildly derogatory, as they are often used to refer to dumbed-down user-friendly interfaces targeted at non-programmers; a hacker has no fear of obscure commands (compare WYSIAYG). On the other hand, Emacs was one of the very first WYSIWYG editors, replacing (actually, at first overlaying) the extremely obscure, command-based TECO. See also WIMP.
deleted 7y ago
[deleted]
DonHopkins 7y ago
In this video of Eric Bier and his colleagues from Xerox PARC demonstrating Cedar, they discuss writing resolution independent applications, and the problem and approaches to matching the text and formatting displayed on the screen, with how it looks when printed: https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 >Eric Bier Demonstrates Cedar. Computer History Museum, Recorded on January 24, 2019. >This interpretive production was created from archival footage of Eric Bier, PARC research scientist, demonstrating the Cedar integrated environment and programming language on January 24, 2019. Cedar was an evolution of the Mesa environment/language, developed at PARC’s Computer Science Laboratory originally for the Xerox Alto. Mesa was modular and strongly-typed, and influenced the later Modula family of languages. Cedar/Mesa ran on the D-machine successors to the Alto (such as the Dorado) and added features including garbage collection, and was later ported to Sun workstations. Cedar/Mesa’s integrated environment featured a graphical window system and a text editor, Tioga, which could be used for both programming and document preparation, allowing for fonts, styles, and graphics to be embedded in code files. The editor and all its commands were also available everywhere, including on the command console and in text fields. The demo itself is running through a Mac laptop remotely logged into Bier’s Sun workstation at PARC using X Windows. Bier demonstrates the Cedar development environment, Tioga editor, editing commands using three mouse buttons, sophisticated text search features, the command line, and the Gargoyle graphics editor, which was developed as part of Bier’s UC Berkeley Ph.D. dissertation. Bier is joined by Nick Briggs, Chris Jacobi, and Paul McJones. Here are some notes about that I took: There were several window systems developed for Cedar: Warren Teitelman developed Docs. Lots of functionality, but slow. Scott McGregor developed Viewers. It was lean and fast, in response to Docs. Michael Plass built the Cedar imager. The Experimental Programming Environment Research Project looked at different competing projects to decide which to standardize on. Cedar/Mesa came out of that and played a dominant role in the 80's. The Smalltalk people contributed ideas but were (not railroaded but) frustrated. Cedar had a ubiquitous almost-wysiwyg structured text and code editor called Tioga. It was important in Cedar, because it's everywhere, even the text fields. The terminal window has a stripped down text editor with subset of commands. Setting the so-called "clipping level" in Tioga (like a folding outliner) goes back to Englebart's NLS. Bill Paxton and Doug Wyatt were NLS people who also worked on Tioga. Key ideas were applicable in any possible place in both systems. The Alto had small memory, and each program took over the entire system. It was not integrated. Simple little editors for code. Fancier editors for documents. Using the same component everywhere is something Smalltalk was pioneering even on the tiny Alto. When Cedar came along, running on a much bigger more powerful 1 megabyte D-Machines, it pulled together those ideas, and added so much more, including much more advanced graphics, way beyond what the Alto could do. Tioga could display and edit formatted code with different levels of indentation and formatting. Tioga was not completely WYSIWYG. Print mode shows two columns, but you edit one column. You could get a pretty good idea of what it would look like, but in the early times it did not have smooth fonts. Bitmap fonts measure differently on the printer, so text is necessarily broken and flowed differently. The printer used Interpress, the predecessor of PostScript. You could preview Interpress files in Cedar. (The video shows a demo of both editing a document in Tioga, and previewing the Interpress file that it produced for the printer.) Recently I wrote about the differences and similarities between Forth and PostScript, and the influences of Evans and Sutherland's "Design System" on John Warnock and Martin Newall's "Jam", then Jam's influence on John Warnock and Charles Geschke's "Interpress", then Interpress's influence on PostScript: https://news.ycombinator.com/item?id=21968175 https://news.ycombinator.com/item?id=21968175 >Kragen is right that PostScript is a lot more like Lisp or Smalltalk than Forth, especially when you use Owen Densmore's object oriented PostScript programming system (which NeWS was based on). PostScript is semantically very different and much higher level that Forth, and syntactically similar to Forth but uses totally different names (exch instead of swap, pop instead of drop, etc). >But its most obvious similarities with Forth are based on generic Computer Science concepts like stacks, which is not something particularly unique to Forth itself, so saying PostScript was influenced by Forth ignores other much more influential languages like Interpress, JaM, and Design System, which directly influenced PostScript and were designed by the same people. Also, PostScript is not threaded like Forth. But it's homoiconic, unlike Forth and Lisp. https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Martin_Newell_(computer_scientist) https://en.wikipedia.org/wiki/Martin_Newell_(computer_scient... The heavily commented PostScript source code of PizzaTool for NeWS shows Owen's OOP PostScript system in action: https://donhopkins.com/home/archive/NeWS/pizzatool https://donhopkins.com/home/archive/NeWS/pizzatool PostScript was a direct descendent of and heavily influenced by Xerox PARC's Interpress, by John Warnock and Charles Geschke, which itself was a direct descendent of JaM, which stands for "John and Martin", by John Warnock and Martin Newall. And JaM was a descendent of Evans and Sutherland's Design System, by John Warnock and John Gaffney. https://en.wikipedia.org/wiki/John_Warnock https://en.wikipedia.org/wiki/John_Warnock http://historyofinformation.com/detail.php?entryid=1213 http://historyofinformation.com/detail.php?entryid=1213 https://en.wikipedia.org/wiki/Martin_Newell_(computer_scientist) https://en.wikipedia.org/wiki/Martin_Newell_(computer_scient... https://en.wikipedia.org/wiki/Charles_Geschke https://en.wikipedia.org/wiki/Charles_Geschke https://en.wikipedia.org/wiki/Interpress https://en.wikipedia.org/wiki/Interpress https://en.wikipedia.org/wiki/Evans_%26_Sutherland https://en.wikipedia.org/wiki/Evans_%26_Sutherland Brian Reid (whose brother is Glenn Reid, author of several books on PostScript from Adobe) wrote up an excellent historical summary in 1985 on the laser-lovers mailing list of the influences and evolution of PostScript. https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist) https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist... http://glennreid.blogspot.com/ http://glennreid.blogspot.com/ Here's a post I wrote earlier: https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19874245 >DonHopkins 8 months ago [-] >Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other: https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us4h8S3Kk https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us... >By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools. There's more interesting discussion about the relationship between PostScript and Forth on c2: http://wiki.c2.com/?ForthPostscriptRelationship http://wiki.c2.com/?ForthPostscriptRelationship Here's a lot more stuff I've written about PostScript and Forth (two of my favorite topics!): https://news.ycombinator.com/item?id=11479364 https://news.ycombinator.com/item?id=11479364 https://news.ycombinator.com/item?id=13198492 https://news.ycombinator.com/item?id=13198492 https://news.ycombinator.com/item?id=13705664 https://news.ycombinator.com/item?id=13705664 https://news.ycombinator.com/item?id=13705739 https://news.ycombinator.com/item?id=13705739 https://news.ycombinator.com/item?id=18317280 https://news.ycombinator.com/item?id=18317280 https://news.ycombinator.com/item?id=18692144 https://news.ycombinator.com/item?id=18692144 https://news.ycombinator.com/item?id=18695275 https://news.ycombinator.com/item?id=18695275 https://news.ycombinator.com/item?id=18696116 https://news.ycombinator.com/item?id=18696116 https://news.ycombinator.com/item?id=19873630 https://news.ycombinator.com/item?id=19873630 https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19882301 https://news.ycombinator.com/item?id=19882301

basementcat 7y ago

Your post prompted me imagine a nightmare/utopia in which TeX was used for building user interfaces. This was followed by a vision of a window system built on ROFF.

mhd 7y ago
Someone taking a verbose format for writing text and adding feature and feature to it until it supports UI applications? Jesus, that's a horrific vision. Hope something like that will never see the light of day.
- Jailbird 7y ago
  Perhaps all that will be implemented is character cell windowing systems. And Doom. Definitely Doom.
  - DonHopkins 7y ago
    Hurray for the MGR window system! https://hack.org/mc/mgr/ https://hack.org/mc/mgr/ https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR >ManaGeR or MGR was an early windowing system originally designed and developed for Sun computers in 1984 by Stephen A. Uhler, then at Bellcore. >MGR featured overlapped, asynchronous windows and an applications interface that was both machine and network independent. >Each MGR window had support for both character terminal operations as well as basic graphics operations. It was controlled by mousing pop-up menus, by keyboard interaction, and by escape sequences written on pseudo-terminals by client software. >The system was presented at the USENIX Fourth Computer Graphics Workshop in 1987 as "MGR - a Window System for UNIX".[1] The entire MGR source code was posted to the comp.sources.unix Usenet newsgroup, Volume 17, Issue 1, in January 1989.[2] MGR was the largest posting to ever appear in comp.sources.unix: https://groups.google.com/forum/#!topic/comp.sources.unix/GGMq2FNEI1A https://groups.google.com/forum/#!topic/comp.sources.unix/GG... Also Chris Torek, Mark Weiser and others developed "Maryland Windows" at the University of Maryland Computer Science Department, based on the Gosling Emacs screen redisplay code and terminal drivers. It was very good over slow modems because it used Emacs's intelligent redisplay algorithm aka "Ultra-hot screen management package" -- the one with the skull and crossbones. https://www.donhopkins.com/home/code/display.c.txt https://www.donhopkins.com/home/code/display.c.txt Maryland Windows source code: http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/XGsf97m7fA0J https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/... Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux.

Lammy 7y ago

> I can imagine a world where PostScript would be used for building user interfaces NeXT did that in 1988: https://en.wikipedia.org/wiki/Display_PostScript https://en.wikipedia.org/wiki/Display_PostScript

DonHopkins 7y ago
What NeXT missed out on is what we now call "AJAX": the advantages of implementing the user interface toolkit and the front-end parts of the application in PostScript, so it runs right next to the user, can can implement an efficient application specific networking protocol to communicate between the client and server. NeXT didn't have any of the advantages of NeWS and AJAX when run over the network. Just the stencil/paint imaging model. But no light weight processes, local event handling, object oriented programming, etc. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation.
- DanielKehoe 7y ago
  Consider this. As we know, Tim Berners-Lee developed the first web browser on a NeXT computer, with Display Postscript to render HTML (and print it, too). Two years later, Marc Andreessen and Eric Bina developed the NCSA Mosaic web browser for the X Window System and Microsoft Windows. Another 2 years, and Brendan Eich made the Netscape Navigator web browser programmable with JavaScript. What if Sun had open sourced NeWS in the early 90s? Could NCSA or Netscape have used an open source NeWS to build a web browser that renders HTML using NeWS on X11 or Windows? With no need for JavaScript or CSS, just Postscript? Don Hopkins? Is it plausible that we’ve had 25 years of JavaScript hell because Sun management didn’t open source NeWS? Or were there insurmountable technical obstacles as well?
  - dboreham 7y ago
    Netscape succeeded because they had a 16-bit implementation. 16-bit postscript would have been a significant challenge.

gnufx 7y ago

My "hyperTeX" documents under NeWS looked pretty much the same on screen as printed, modulo hyperlinks, but I wouldn't want to write documents directly in PostScript. I'm unconvinced generally about the trades-off of markup in a non-macro programming language. Incidentally, the nascent web looked horribly primitive when you already had fairly rich networked hypermedia and missed the significance of the web architecture.