AltME groups: search

yes i know it runs but it looks ulgy like hell...beside that... running 
wine and Rebcode is some kind of a Honey-pot licking contest..

That relay a pitty because the alpha currently is still very intresting 
for its speed...save or not ;-)

and there was also a 'life' version i remember..

I've been on the bench related to rebcode for a year, and I was its 
most avid tester. Waiting for R3...

R3 became a higher priority, particularly when it became apparent 
that the new runtime would make rebcode even better.

Petr, in particular I was thinking of vectors, the new objects and 
a better security model. Hopefully better structs too, with rebcode 
support.

I also wanted support for more datatypes. I was looking at rebcode 
as a compilation target. It never mattered to me how it looked since 
I was only rarely going to write it out - most of my code will be 
generated.

no need to bug me, i already want all that stuff. i guess it'll be 
3.1 rather than 3.0 though. remember 3.0 is only a couple months 
away...

ah, ok, there is a Reichart to blame. Reichart - where are you?! 
:-)

he likes it a lot (liquidgl), but it's too big, so max will need 
to "distill" it a bit :)

that is, my idea (which carl agreed on, and i think others too), 
is that the app does not get a mouse click event, it gets a "button 
pressed" event. (not sure if the explanation is clear)

core with rebcode is a different thing from core with all the rebcode 
improvements that have been proposed.

even if there are only a few... it's still some time subtracted from 
other stuff. so i can't promise anything about that, especially since 
i don't know the details of everything.

Carl might be able to give you a much better answer...

Carl would have to visit us here from time to time, to get us a better 
answer :-)

It's the first version of rebcode, you'll find in those. A later 
version was released for Windows, yes.

Aaaaaiiiii that 1350042 version is a real old one ..but it has Rebcode.....

Ok, played.  2.6.50.4.2  version insert takes word! series!  so

m: does [make image! 0x0]  f: rebcode [] [apply j m []  insert j 
[1]  return j]  will assemble and run, but I get a mungled image 
when I try it.   (Can't get the 256 count thingy to assemble)

>> ex: rebcode [/local a][set.i a none eq.i a none ift [print "a 
is none"]]
>> ex
a is none

In rebcode none is same like zero so if you want to check value where 
are integers or can be none, than it's not enough. The best way how 
to solve it now is not to use such a logic, or use something like 
this:

   ex: rebcode [a /local r n no][type? r a print r   set n none type? 
   no n  eq.i r no ift [print "a is none"]]

which is quite heavy. Or find out the integer value for each datatype. 
Or is there any better way how to work with value returned by  the 
type? opcode?

type? none is in rebcode integer 28 so to test none value it's possible 
to do:

r: rebcode[a][type? t a  eq.i t 28 ift [print "a is none"]] r none

I feel, the main goal for rebcode implentation is speed, so it makes 
sense, that none is the same as zero. It would probably hit performance 
a lot, if you had the usual REBOL datatypes in rebcode.

Maybe it's confusting that something as basic as NONE? doesn't have 
a corresponding opcode.

Here's a MOS 6502 emulator written in rebcode, I made over the last 
few days:
http://www.fys.ku.dk/~niclasen/rebol/language/em6502.r

Well, I am at the command prompt, I did a do http://www.fys.ku.dk/~niclasen/rebol/language/em6502.r
and the prompt is here again. What could I do ?

To make a little test:
do http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r
do http://www.fys.ku.dk/~niclasen/rebol/language/em6502.r
ram: asm6502 "lda #&01 adc #&02"
em6502 ram 0

Those 4 lines do this: load the assembler, load the emulator, call 
the asssembler with a 6502 asm program returning 64kb ram, and finally 
run the program.

Not much to see, but the program ram. To check things, put e.g. print 
lines in the end of the emulator. Like those 2 already in there commented 
out:
print A
print P

which will print the content of the A register and the P (status) 
register.

with a PCL driver

and a new PC. that stupid machine just died. glorious day today.

setup a HP printer ( eg an old laserjet ) and set the driver to print 
to a file

the HP driver probably takes PCL and creates a bitmap and then sends 
it to the printer

There are many printer specific bugs that require a windows printer 
driver to make postscript printing work properly


Bad news for me! I'm working on a new version of a huge application 
for a customer, and I was about to rebuild their printing in a couple 
of months. I planned to use the rebol postscript dialect.

Geomol, I built a printer abstraction system called system-print 
for my apps. It's not finished, but for what it does it works sort 
of OK. You can choose printing method via a GUI and it auto-detects 
Ghostscript and uses it if necessary.

It supports currently print to file, print to LPT, print to Ghostscript, 
print to screen (as in screenshot), print to ethernet printer and 
to a custom network printer server made in REBOL for some simple 
printer sharing.

There is also a print queue system, which you can opt to use, if 
you don't want to print directly.

http://rebol.hmkdesign.dk/files/system-print-queue.png

you feed a postscript layout through a parser, which fills in dynamic 
values and then it's run through postscript.r and then it's fed through 
system-print to the appropriate printing method.

another advantage is that it's fairly simple to add a new method. 
it took 20 minutes to add Ghostscript printing via the win32pr driver 
and when it was added, I could print anything, which is a nice thing 
about this abstraction.

for those faces which have DRAW blocks, as a temporary measure.

so it saves it as a bmp in memory?

Yes, it saves as a bmp bitmap in the binary specified, so no need 
for intermediate file.

Geomol's dialect allows image! but you have to reference it by a 
word (no direct reference).

I think, if you write code, that'll produce postscript output, you 
have to know the paper size. At least the last step has to know. 
I see postscript as a language, where you have full control over, 
what you get on the paper.

Do not explicitly specify paper format. 
 Unfortunately, many programs 
force you to select a paper size. Often, it can be edited out of 
the Postscript file. Instead, let the printer decide whether it can 
print a document with specific dimensions.

kghostview test-image.ps  shows the help.gif image just down a little 
bit from the top-left of the page. I suppose it's a margin of some 
sort.

Hmm.. if I have
	offset: pagesize - img/size

then it shows the image just a little left of bottom-right corner 
of page.
Another margin ?

Anyway... just a little dabble in the postscript world..

Henrik, I can see, there's a bit difference in our versions. Maybe 
we should merge at some point? Image is in both our versions though.

Ok, what do you wanna do? Anton did a little test, that worked ok. 
I can run the test here too.

When I run your test with my version of postscript.r, I get a page 
with a gray box in upper left and the text "Page 1". It's an ok PS 
file here.

because otherwise I can't put images directly into the dialect and 
I will have to store them in a tempory place first and reference 
them with a word => much more code.

With the change, I can produce a PS file, but I still can't see the 
image. Will try some stuff...

BTW, if you don't mind: I've added a probe on the dialect code output 
in to-postscript.r. Then you can see if I'm writing something incorrect 
out.

I had a problem some time ago showing PS files, I produced. I think, 
it was some cache.

The dialect code, you produce, looks ok. I'm really not a shark with 
PS, so it doesn't mean, it's 100%, even if it looks ok to me. :)

I can't get image! datatype to work in the postscript dialect (your 
suggestion). If I have it as a word, that is being "get", it works.

I don't get The 'img variable is set to an image! type, just like 
it is when using load-image from a file or url (which I couldn't 
get to work either).

Sorry, should be:


I don't get it. The 'img variable is set to an image! type, just 
like it is when using load-image from a file! or url! (which I couldn't 
get to work either).

Henrik, did you create a dialect that takes a VID layout and produces 
a printout in PS?

actually not a dialect, it just converts a View object tree to postscript. 
it's used in the same way as to-image is on a layout.

since it works on a view object ... it should work on Rebgui as well

eg. we can submit an area to the layout engine and get a graphic 
back at a specified resolution

rich text has some bugs, which cyphre is able to fix once he gets 
time, so I hope this will be possible to hook into. i.e. it's not 
a closed part that we can't touch.

so, we can do the text formmating using VID+ and take it out as a 
graphic

I'll get to know it more when we get to build a real rich text editor

all to-postscript.r does is go through the layout tree and renders 
each object as a postscript color box with a text box on top of it. 
face values are just mapped into postscript.

Which seems to say, if you have specified a font, ignore it and just 
use helvetica!

the last one is a bar code font I use

I'm still working on my VID->Postscript thing. I will need it for 
work on a paper layout GUI later this month, so there will be some 
progress there.

It seems, that something called IPS PS3 is in printers from HP and 
Xerox, so they understand PS directly:
http://www.zoran.com/IPS-PS3


It could be interesting to find out, how many printers can print 
PS directly without a driver. Just sending to port 9100 on the printer, 
as described in the REBOL postscript docs.

A world without printer drivers is a better world! (TM)

It could be interesting to find out, how many printers can print 
PS directly without a driver.

 <- I've not yet seen one that does. Even for postscript, there is 
 apparently a need to adjust for bugs in the printer hardware.

A HP LaserJet 4000, I have access to, seem to print PS just fine 
without the need for a driver.

I managed to lock up my brothers HP Laserjet 4500 with a PDF file. 
That was interesting :-)

I will give it a try on my OfficeJet thing. Pretty old and I'm mostly 
sure it won't work. Any good PS file for the test?

A simple test page: http://www.fys.ku.dk/~niclasen/postscript/test.ps

Mass distribution printers .. the added cost of installing a PS interpreter, 
ram etc.

Most cheap printer are dumb. The power is in the driver: the computer 
does the job then send raw command to the printer controller. They 
are often called "Winprinter" because of the usually Windows only 
driver they provide (well, not so true today as it used to be a few 
years ago).


Expensive printers include processor, RAM and the firmware to understand 
the print command by themself. PCL or PS ones (but it exists other 
languages like on Kyocera printers, I have done things for that 12 
years ago).

There seems to be a problem with printing parenthesis in my postscript 
dialect. Henrik, I guess, you use this dialect. Did you come across 
this problem?

Others using this postscript dialect?

It seems, if parenthesis are not balanced in a string, the output 
is rubbish. I found in the ref manual, that some special characters 
need to be escaped with: \
I've made a new version, I'll upload soon.

I have tried, but stopped again due to problems with determining 
whether the dialect itself should create a landscape document or 
the printer driver. So I just usually make a portrait document and 
rotate everything 90 degrees.

PDF output from the PostScript dialect is ready for some test. The 
script is here:
http://www.fys.ku.dk/~niclasen/postscript/rebps2pdf.r

It works the same as the postscript.r script:
http://www.fys.ku.dk/~niclasen/postscript/postscript.r
(which has been updated, as I found some problem with comments)

Example of use:

do http://www.fys.ku.dk/~niclasen/postscript/rebps2pdf.r

write/binary %pdftest.pdf rebps2pdf load http://www.fys.ku.dk/~niclasen/postscript/pdftest.txt

Now you should have a local %pdftest.pdf file, that looks like:
http://www.fys.ku.dk/~niclasen/postscript/pdftest.pdf

I also found, that images seems to work in a weird way with the postscript.r 
script producing PostScript output. I have to test this some more. 
For now, scaling images to 72x72 should mean images in 72 dpi. Maybe 
this isn't a good way to scale?

The question is, what is the physical size of a rebol image?

Anton, that's a pretty good question.

I found a bug when specifying ImageMatrix in postscript.r

I've fixed it and uploaded a new version. Now images should work 
the same in postscript.r and rebps2pdf.r

About scaling images and physical size. I know, the image datatype 
only have size in pixels, and how much is a pixel on paper? It's 
up to the one producing the output to set that. An old measure is 
72 dpi, which is 72 dots per inch. So setting this pixel-to-dot scale 
for images, and the image will be:
(# of pixels / 72) inches in size on paper


I'm not 100% happy with the way, I've implemented the scaling of 
images, and suggestions are welcome.

The more I read and learn about the PDF format, the less fond I am 
of it. It's a bloated mess with some critical limites, as I see it.

Strange, I just tried on my PC, and I get a blank page. It works 
on my Mac. hmm

I think, there a problem. Adobe Reader give an error "Ilegal operation 
'm' inside a text object." on my PC.

Thanks, I get the error in a version 6.0. Now I have to figure out, 
if I stick to PDF 1.3 standard.

right, font metrics. Volker wrote a script to parse the .afm files.

Ver. 0.4.7 of PostScript dialect incl. PDF output uploaded:
http://www.fys.ku.dk/~niclasen/postscript/


- I included font widths in rebps2pdf.r instead of separate binary, 
and
- fixed a bug.

I'm working on a Print Markup Language for a customer, that will 
output the REBOL postscript dialect, so it can produce PostScript 
and PDF output. When producing text, it's possible to specify centered 
and right-aligned text by using the words CENTER or RIGHT after the 
text followed by the size of the area, wherein the text should be 
aligned. Example:

at 100x100 "Right-aligned text" right 400

has the same effect as:

at 500x100 "Right-aligned text" right 0


Suggestion: The dialect will be more simple, if the size is dropped. 
Then the position (from AT) is the right border of the text on the 
output. Same for CENTER, where the position will be the center of 
the text.


I know, Henrik use this dialect. What do you say? If others use this 
dialect, I would like to hear your opinions! If I change this in 
the dialect, it may mean changes to your code.

Because all content in the dialect starts with a word or a string, 
I could make the size optional. It will just mean a more complicated 
dialect, but it won't break your code.

it does not do word wrapping however. that's a problem that I've 
not yet solved.

hm, I remember something about that. I think, I tried it a while 
ago.

But what about the suggestion for a change to the dialect?

this will be useful when I will get to finish the function, perhaps 
in a month or so.

Geomol, there are some subtle bugs that I've not been able to figure 
out, causing certain layouts not to print, so I stick to a specific 
version right now.

It's a little annoying having only a 1-2 week window a year to work 
with postscript.