World: r3wp

Update on the work-in-progress : http://softinnov.org/tmp/test-page.zip


Both files are printed from the same Draw dialect source, using my 
printer:// scheme. The PDF file is printed through Bullzip PDF Virtual 
printer. The PS file is directly generated by the printer scheme 
(for UNIX/Cups direct printing).


Most of the PostScript support is done (see %test-page.ps), but there's 
still a lot of details to enhance/fix/add: 

o Add center/right alignement support

o Add underline style for fonts

o Fine-tune positionning and bold level.

o Fix minor differences with the GDI version.

To view the PS file, use ghostscript / gsview.

Scaling, auto-fit are also currently missing in the PS version. Landscape 
mode is also missing in both GDI and PS modes.

don't bother with underline style!  It's a relic of type setting.

There are a few good justifications schemes available for postscript

I found a justification routine (doing also alignement). I need to 
study it to see if it fit my needs : align and line-wrap at the same 
time.

word wrap or line wrap?

line wrap

there's also a very nice bar code generator for postscript.

That shouldn't be hard to code in PS. Anyway, now I just need to 
code it in Draw, and let the printer:// scheme do the work.

Btw, I need to make a bar code generator for my current project, 
so that's something I'll work on soon.

(only EAN 13 support)

http://www.terryburton.co.uk/barcodewriter/is the one I use ....

Nice library, thanks for the link.

I wrote a simple one that is available through rebol.org.

called ean13.r.. although I don't remember if that specific one has 
PS support.

Thanks Henrik, I'll study your code too.

Did anyone experimented with the printer:// scheme on Windows ? Any 
feedback ?

I'm about to release a new version of the printer lib with multiplatform 
support, so if anyone noticed something to fix or improve that I'm 
not aware of, that's the right time to report ;-).

I hoped to have time Doc, but I don't have a need, and I seem to 
have *no* spare time for playing right now. :-(

I've been pretty flat out as well, but will have a ook at it today. 
 Thanks for the work.

First issue .. the text box displays fine in the PDF, but when I 
print it

write printer:// demo-doc


the lower text box margin cuts into the bottom line of text so that 
only the top half of that line prints.

This is the same for all of the three lower text boxes

It happens here too,  I need to apply global scaling to text fonts 
too.

and not use pair! for specifying X Y scaling values but decimal! 
values.

So, this implementation is as a page description language?

you use commands like 'start-page/end-page to control paging and 
'insert port [...draw dialect...] to draw content.

'end-page might be buggy in your version.

Does text flow from one page to another?

Nope, that's too high-level, it's not a feature of Draw dialect. 
The printer scheme provides a cross-platform low-level layer to build 
such higher-level frameworks.

So, how are you doing it ? multiple pages and text flow?

Making text flow from one page to another is a job for a word-processor 
like MSWord or LaTeX. The printer scheme aims to be general purpose, 
so it can be used to print anything (not only output from word-processors).

Text can only flow inside boxes fully contained inside a page. This 
is achieved by extending Draw dialect with a new primitive : 'text-box.

What I am doing now is printing the text to a virtual draw page, 
and then when it reaches the bottom of the text box, it then flows 
to the next text box.

if the next text box is above the current text box, it assumes a 
page break and so starts a new page.

So, the text boxes are contained within the one page.

and if I run out of text boxes, it just keeps reusing the last text 
box ... for all subsequent pages

Could you send me your Draw source code ? (privately or by email, 
if it's too long)

Sure ..

What I tried to do was create a print template that the user can 
define.

My printing then uses the print template dialect to print page after 
page.

The underlying GDI API I've used does a lot more than needed, I should 
restrict its behaviour.

I see, that's the kind of usage that I was thinking about too.

pagesize A4
font Times-BoldItalic 30
linewidth 1
at 190x750 My-Name
color (black)
font Times-Roman 12
newpath at 75x725 line1
at 75x715 line2
at 75x705 line3
at 445x715 "Ph: "
at 465x715 ph
at 445x705 "Fx: " 
at 465x705 fx
at 438x680 "Date:"  font Times-Bold at 465x680 consult-date
font Times-Roman 11
newpath at 75x740 line 530x740
newpath at 75x700 line 530x700
at 75x680 Provider-Template

at 75x600 "Dear " 
at 100x600 Provider
flow-translate 0x0
flowbox 75x150 540x590 float 20
flow-translate 0x0
flowbox 75x150 540x720
gonzo 
flow consult gonzo
flow-translate 0x0
flowbox 75x150 540x720 float 10
flow-translate 0x0
flowbox 75x72 540x720 float 50
showpage

This is the "dialect" I am using to generate a multi-page letter. 
 Words like "consult-date" "provider" "My-name" are processed by 
a pre-processor to substitute the correct variables.

Looks like rebolized PostScript

flowbox 75x150 540x590 float 20  


means to put a text box that accepts text that flows into another 
box, but to start the text inside the box 20 points below any text 
above it.

yes, to make it easier to convert to postscript  and to draw.

the same dialect gets converted to draw to allow a preview.

So, you have a draw converter for this dialect ?