World: r3wp

Or did that change?

henrik, does it take ps too?

I think we don't have many choices - you can to-image your layout, 
or go for external engines, using some make-docs - pdf, postscript, 
html plus css standard ...

postscript works on a different level. it's OS wide in OSX. I think 
it converts everything to PDF before printing, because all graphics 
are PDF centric.

if windows handled ps i guess we'd have a good solution. it would 
have been easier for me to write a ps maker instead of a pdf maker 
:)

gabriele, I would think it does. I have to convert docs to PS if 
I want them printed under Linux with LPR

lpr, per se, does not mandate a document format

it just spools documents to the printer

originally documents were text files

and, if you had a ps printer, ps files

how "good" is already w3c's stuff here? I mean html plus css and 
it's media (printing) capabilities? browsers are everywhere ....

then I don't know what it does, but I can pipe PS files directly 
into LPR

then, ghostscript got put in between lpr and the printer, so that 
you could always use ps even for non-ps printers

PS files are just text files

Pekr is very opposed to using ghostscript!

petr, i don't think it has ever been important for html to be a printing 
ml

I think early Netscape clients emitted PS as well.

well, if this is accurate, I don't use ghostscript at all. this 150$ 
printer here must be able to handle postscript natively then :-)

i mean, you can print an html document; but if you wanted to print 
a book, you wouldn't probably use html

some printers come with postscript emulation.

Gabriele, that's what annoys me about Rebol documentation.

It's all html and you can't print it.

Gabriele - I know, but they try to ... Graham - yes, I try to use 
what is at user's disposal already .... browser or mostly Acrobat 
Reader ....

In the early days, rebol docs came as pdfs.

that's one of the reason a pdf emitter for md3 is very important

I think HTML/CSS is not good enough for printing, even with the printing 
oriented CSS commands. It's a nightmare to match margins, and browsers 
don't interpret the settings equally.

and why i studied TeX

I was most upset seeing images cut in half by my colour printer when 
printing out the view docs.

yesterday I looked at two big printers here (not very skilled in 
that direction) and I found PCL, PJL, LPR you mentioned. What are 
PCL and PJL? Othere languages to support printing?

TeX would have reshuffled the images around so that they wouldn't 
get cut in half.

the problem is not html itself, it's that browsers are not good at 
printing

PCL is printer control language

from HP.

Its very escapist.

gotta go, later!

bye.

The problem with floating tables and images, is that if they don't 
fit in their entirety on the current page, you have to move them 
to the next page.

Gabriele - I know, browsers are just containers for other technologies. 
It will last at least one or two years, before browsers  (for most 
userbase) support  ajax, svg, css 3, etc., but they are actively 
developed and will always be at user's desktops .... there is also 
one czech product, called formfiller ( http://www.ff.cz), which 
allows (internally hopefully xml) docs.  xForms is the standard we 
should watch ...

Pekr, in your large organisation, are there really no postscript 
printers?

there are, most of them, but give me easy preview ....

did you look at my two column preview ?

yes, slow at zooming, but working .... will you be able to get any 
ps complicated doc be previewed in your viewer?

only if it is generated by the dialect.

Remember, this isn't a postscript viewer... but a viewer of a rebol 
dialect that can either output to postscript or to draw.

so if you can do it in terms of your dialect, it is previewable? 
then it is absolutly sufficient imo ....

the good thing then will be, that I will be able to localise ti, 
or change its design, if it stays for free ....

I suspect that by the time I finish it, Gabriele will have come out 
with a pdf-maker which will render mine obsolete!

The idea here is to produce postscript as the last thing, just before 
sending the data to the printer. We shouldn't produce postscript, 
that we then need to preview before printing, because we then need 
to solve the problem of converting postscript to something viewable 
on the screen. It's better to work with DRAW or whatever developers 
use to visualize their content and have preview at that level. Then 
in the end, the user wants to print and now, finally the content 
is converted to postscript to be sent to a printer.


Having a postscript printer is a huge benefit, because you can say 
goodbye to printer drivers and all the trouble, those cause. The 
REBOL postscript dialect is your driver. :-)

A postscript printer is a printer, that understands the postscript 
format. It reads the text commands, a postscript file is, and print. 
Data like images is inside the postscript file as hex or something.

Then the million dollar question: Why do printer manufacturers make 
printer drivers filling up 10s or 100s of MB on users harddiscs? 
Why do those drivers need to be so huge, if it's such a simple task 
to print (using postscript)?