World: r3wp

well I have not had any success with it

and it only supports uncompressed bitmaps

Oh, an alternative idea then.

Scan in as whatever .. turn it into an eps.

take the vid data and write it over the eps .... where you want the 
data ..and send to postscript printer.

that might work

Actually, what I am doing for infant growth charts is to take the 
pdf forms ... turn them into postscript ... add some growth data 
as postscript lines and then print them

I guess I can do the same for electronic forms.

Yes, that's what I can do .. it's the same thing.

But the end users won't be able to do this ...

So, it would be good to find a solution suitable for an enduser.

So, the eps idea might be the better way to do it.

quick question about images.

eg.

==
i1: load %image.jpg
i2: i1
i2/size: 300x300
save/png %a.png i2
===

why does the image comes out distorted?


what is the correct way to 'resize' an image and save it in a different 
format?

i1: load %image.jpg

save/png %a.png layout/tight [image 300x300 i1]

unfortunately you can only do nearest neighbor scaling

layout/tight?

is there such a refinement?

yes in rebol/view 1.3.x. not in 1.2.x

I am on /view 1.3.x ....but have an error..

===
** Script Error: Invalid argument: type: face
offset: 0x0
size: 300x300
span: none
pane: [make object! [
        type: 'face
        offs...
** Where: halt-view
** Near: save/png %a.png layout/tight [image 300x300 i1]
==

thought it could do that directly, but then:

save/png %a.png to image! layout/tight [image 300x300 i1]

yes..that works!

but it eats memory. beware of that :-)

original: %image.png  ; INPUT FILE
resized: %resized.png ; OUTPUT FILE
new-size: 300x300


save/png resized draw make image! new-size compose [image (load original) 
0x0 (new-size - 1x1)]

; examine results
view layout [image (load original) image (load resized)]

The above uses AGG scaling via the DRAW dialect. If you are converting 
many images, it should be faster than using LAYOUT all the time (and 
the code is shorter).

Henrik: PDF Maker 1 has been used extensively with images. And they'll 
be back in v2 very soon. The only drawback is lack of any compression, 
so the resulting PDF file is rather big (if the source image is big).

gabriele, that sounds good :-)

wow, where does the 'draw command come from !!! hehe am I the only 
one who didn't even know it was there?  I guess its there since draw 
was added to view!

is there a way to alter the sampling algorythms used in draw?

faster/better quality and up and down sizing all have optimised algorythms. 
 There is no universal algorythm for resizing, not even the slower 
ones.  Some have sweetspots in various conditions.

draw native has been added with AGG

I just miss being able to create proper thumbnails with draw AGG

Being able to save JPGs is my only outstanding image-related request, 
but I know that isn't likely to happen.

Gregg, why not? Is the code too large for Carl to include it, or 
is it something else?

licensing ?

http://www.extremetech.com/article2/0,3973,389261,00.asp

graham, I think that was overthrown in 2004

http://www.groklaw.net/article.php?story=20060526105754880

correction: 2006

So, did they pay Sony $15M back ?

There should be no legal issue with Independent JPEG Group's version: 
http://www.ijg.org/
From the README:


It appears that the arithmetic coding option of the JPEG spec is 
covered by
patents owned by IBM, AT&T, and Mitsubishi.  Hence arithmetic 
coding cannot
legally be used without obtaining one or more licenses. 
 For this reason,
support for arithmetic coding has been removed 
from the free JPEG software.
(Since arithmetic coding provides only 
a marginal gain over the unpatented
Huffman mode, it is unlikely 
that very many implementations will support it.)
So far as we are 
aware, there are no patent restrictions on the remaining
code.

I'm not a law expert, so I might be wrong.

I don't think there would be any problems with the law, only a matter 
of the size of the implementation.

I do believe it was a size issue, Graham.

How to properly invoke event after window opens.
Or the exact my problem is:

I need to display layout face for web browser plugin. And then after 
it is displayed update some one of subfaces and show them.

It is no problem to do so for new windows outside first one in web 
browser page if opening with /new, but I want to do it for main window 
in browser page.

In such cases it looks like /new does not help - nothing is executed 
after view/new main-win.

Do you mean you want to show windows inside the main window ? Or 
are you happy with panels ? eg:

view layout [btn "code" [my-panel/pane: layout/tight [size 400x400 
backcolor teal title "Code"] show my-panel] btn "documentation" my-panel: 
box 400x400 edge [size: 2x2 color: coal]]

In my case I have panel and some faces what I want to update *after* 
main window is opened.

Ok, order of operations should be:
1)   VIEW main-window
2)   SHOW  subfaces

Not after a button is pressed.

Ok, instead of
	VIEW main-window
you can write
	VIEW/NEW main-window
	DO-EVENTS

Which means you can also write:
	VIEW/NEW main-window
	my-panel/text: "new text here.."
	SHOW my-panel
	DO-EVENTS