Hacker News Reader

Hacker News

Comment by crooked-v | Hacker News Reader

Parent Full thread

crooked-v

> 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.

View on HN

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.

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

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...

>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/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

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.

The Acorn Archimedes had anti-aliased text using 8 grey levels on a 4 or 8 bit display, on computers with 0.5MB RAM in 1990... http://telcontar.net/Misc/GUI/RISCOS/#text so in theory it could have been practical for Sun ...

If your display only has gray levels, then anti-aliasing is easy since you don't need to worry about rendering text over non-white backgrounds, and you don't need to worry about a colormap. But 8 bit displays with colormaps make it much harder to support anti-aliased text practically, especially over arbitrary backgrounds (because it would look terrible as well as being slow).

NeWS used a color cube with only a certain number of grays, and those were only useful for anti-aliasing black text against a white background (or the other way around), and you didn't have a lot of colors to choose from for antialiased color text or against colored backgrounds. It's much easier to render anti-aliased text in 24 bits, or with pure gray scale, since you aren't restricted to an 8 bit color palette, and you can efficiently mathematically blend colors together, instead of looking up rgb values in a colormap, blending to get the ideal desired color, and then searching for the nearest color to each pixel in the colormap (or indexing the color cube for the nearest color) (which won't be very near, and will look flat and washed out without dithering).

Better visually to render the whole image with antialiased text in full 24 bits, then use error diffusion dithering over the entire image at once (to avoid flat washed out regions, and distribute the error over space) to make an 8 bit palletized version, but that's quite slow and memory intensive.

Of course your application (like a monochrome PostScript previewer) could switch in an all-gray ramp colormap for efficiently rendering and beautifully displaying anti-aliased text, but then all the other windows on the screen would be shown in the wrong colormap, and the colormap would flash back and forth when you moved your focus between windows.

Ah, yes, Acorn didn't try to anti-alias properly over varying backgrounds. ArtWorks did full anti-aliasing but it was quite a lot slower to render https://en.wikipedia.org/wiki/ArtWorks

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.

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...

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.

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.

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

>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

>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/Homoiconicity

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

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

http://historyofinformation.com/detail.php?entryid=1213

https://en.wikipedia.org/wiki/Martin_Newell_(computer_scient...

https://en.wikipedia.org/wiki/Charles_Geschke

https://en.wikipedia.org/wiki/Interpress

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...

http://glennreid.blogspot.com/

Here's a post I wrote earlier:

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/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

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=13198492

https://news.ycombinator.com/item?id=13705664

https://news.ycombinator.com/item?id=13705739

https://news.ycombinator.com/item?id=18317280

https://news.ycombinator.com/item?id=18692144

https://news.ycombinator.com/item?id=18695275

https://news.ycombinator.com/item?id=18696116

https://news.ycombinator.com/item?id=19873630

https://news.ycombinator.com/item?id=19874245

https://news.ycombinator.com/item?id=19882301

And have the same dpi as whatever's used to print them!

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.

Reply on news.ycombinator.com