World: r3wp

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)?

(Of course if the printer isn't a postscript printer, and you want 
to print a postscript file, you need a driver to convert from postscript 
to the format, the printer understands. So people without a postscript 
printer can still print from postscript-producing REBOL programs. 
They then just need a printer driver.)

Theoretically HTML+CSS should have everything you need to print with 
a fairly high degree of control, but all browser implementations 
suck.  Badly.

there's no support for text rotation or hyphenation in CSS either

Most people producing print expect WYSIWYG. HTML+CSS is not a WYSIWYG 
standard (contrary to what many seems to think). So trying to produce 
WYSIWYG output from a browser (or expecting WYSIWYG output from a 
browser) is doomed from the beginning.

hence the stupidiy of expecting traditional web apps to be able to 
do anything. :-(

and why javascript should have been promoted more for the last 10 
years.

a bit off topic: has any one noticed how often when printing HTML 
pages that the last page that comes out is just empty or useless?

How well does OO with such things?

Yes, it happens alot to me too and is a waste of paper. Good that 
many websites has that little printer-friendly-version icon.

Volker, OpenOffice doesn't include a browser (the versions I've used), 
while StarOffice did (when I used that). So opening a HTML doc in 
OO gives you the wordprocessor with the concept of paper-pages, and 
then you print, what you see.

But how good is that html->page-maker?

oops, I remembered wrong. Opening a HTML-file in OpenOffice gives 
you an HTML editor (without the concept of paper-pages). I'll make 
a test...

IIRC OO has multiple views, like pages, continuos. MAybe you can 
simply change that

Opening a tv-program site from a danish tv-station made NeoOffice 
(a Mac version of OO) loop. I'll try with www.rebol.com

geomol, is "Astronomically Slow" still the middle name of NeoOffice?

yes :D

www.rebol.com opened OK in NeoOffice, and I could change to "Print 
Layout". Right-margin is not perfect (as often with HTML, because 
it isn't a wysiwyg format), and it can probably be configured. Saving 
as PDF gave me exactly what was seen on the screen.

Volker, so my first impression is, that OO is OK to handle HTML, 
but not perfect (and how could any program be with all that misunderstanding 
of HTML out there).

H: I think there is hyphenation in CSS 3, iirc.

Some small progress .. I can now get floating text tables, and text 
that flows from one textbox on one page to the next page.  But not 
completely error free yet :(

This is in Draw .. haven't tackled this in PostScript yet.

do http://www.compkarori.com/reb/psd2draw5.r

this is an alpha dialect that just does draw at present.

I have two textboxes on the first page, and one on the second.  Text 
flows from the first page to the second, sort of justified.

A textbox is used also to centre the large titles on each page.

I have no idea why the small text looks as though it is in bold.