World: r3wp

And yes, Rebol's compress is some older version of zlib compression 
- I use Rebol's compress function to create compressed SWF files, 
but in some cases Rebol is not able to decompress zlib binaries (so 
I use the dll)

thanks oldes, i'll probably ask you more when i get to this :)

I'm embedding JPGs into SWF files without problem, there is not required 
any special operation on the JPG's data to embedd. With the other 
formats I have to count pallete and use Rebol's compress (zlib) to 
embedd such an image (gif or png). It's not so fast, but it does 
what I need (and I don't mind if it takes a second more time to compile)

Is the PDF format so different? SWF and PDF are now in the same stable 
= Adobe

(I mean embedding images into the PDF, to make it clear, the format 
is different of course)

pdf wants the dct data, not the whole jpg binary, afaik. the data 
in the jpg header go to the image object dictionary.

hmm, rereading the spec, it may work just putting the jpg file there. 
i will try that, eventually. :)

update: changes to tables, now can calculate the column widths automatically. 
(it does so *much* better than web browsers.)

I see your embedded image. Very nice. Can you explain briefly how 
the column width calculation is better ?

classic example: you are doing a definition list with a table, so 
you have a column with words and a column with the description.

this means that the description is usually long, while the first 
column only has a word or two.

what you get in web browsers is that if you have two words in the 
first column, they are very likely to be broken into two lines

i.e. the first column is forced to be very small by the second column 
having long text

in the pdf maker, two words in the first column would not be broken, 
since shrinking a column with text that is already more that one 
line is better than shrinking a column with text which can fit in 
one line.

Ah.. I have experienced this problem. That is a good improvement.

I'm looking for a definition-list example in the test document ...

it's not there, but the pdf-emitter for qml creates them :)

.. but doesn't appear to be one. Maybe you could add it ?

Ok.

let me add one for you...

You want to show off your technology don't you ? :)

:) it's uploading...

...done. last page of test.pdf.

Looks great. Good work.
http://www.colellachiara.com/soft/PDFM2/test.pdf

The link above just crashed my Firefox

But it's working now, strange

Maybe the acrobat driver wasn't running. In any case, nice work Gabriele.

It must be related to acrobat as I have same problems with other 
PDF documents sometimes if I open them in Firefox - I must say that 
I don't like PDFs at all

oldes, depends on the viewer. I use PDF's under OSX all the time. 
:-)

Of course, PDF is the main format for everything on Mac:-)

so you shouldn't hate PDF, but the viewer :-)

I know people who are able to send me PDF where is only one image 
(they are Mac users of course)

But maybe you are right.

some day someone will write a PDF viewer for REBOL that will rival 
Preview.app for mac, so things will be good. :-)

Gabriele, I have patched pdf-maker.r  1.27.1  of  3-Aug-2006  to 
make the dialect a little easier with images.
Starting at line 1051, the changed lines are commented:

| 'image (
                push new
                gfx: none

                insert tail new/contents new: make default-space []

            ) opt [opt 'at [copy val1 2 number! | set val1 pair!] (if pair? val1 
            [val1: reduce [val1/x val1/y]] new/translate: val1)] ; <-- now translation 
            is optional, and can be a pair too

            opt [opt 'size [copy val1 2 number! | set val1 pair!] (if pair? val1 
            [val1: reduce [val1/x val1/y]] new/scale: val1)] ; <-- now scale 
            is optional, and can be a pair too
            any [
                'rotated set val1 number! (new/rotate: val1)

              | 'skew [copy val1 2 number! | set val1 pair!] (if pair? val1 [val1: 
              reduce [val1/x val1/y]] new/skew: val1) ; <-- now accepts a pair
            ]  set val1 [image! | file! | word!] (
                if word? val1 [val1: get val1]
                if file? val1 [val1: load val1]

                ;if none? new/translate [new/translate: [0 0]] ; <- default position 
                (could set this to "current layout position")

                if none? new/scale [new/scale: reduce [val1/size/x val1/size/y]] 
                ; <- default size

                insert insert tail used-images val2: join "Img" length? used-images 
                val1
                gfx-emit [to-refinement val2 'Do]
                new: pop gfx: none
            )

(5 changed lines.)

Aha... images are not compressed. Two images of 1.34 MB made a 67MB 
pdf ... Onward pdf-maker-2 ... :)

so 0 0 1 1 are reasonable defaults? hmm.

Sorry, defaults for what ?
The above changes allow eg:
	layout-pdf [ [ image logo.gif ] ]
	layout-pdf [ [ image 20x150 200x96 logo.gif ] ]

image logo.gif would be at position 0 0 and 1 mm high, 1 mm wide 
(unless there's another transformation involved)

the reason i don't accept pairs is consistency; since values are 
decimal, and pair is integer only, i don't allow them to avoid confusion 
and complicating the rules even more (in v2 this would be even more 
complicated because of evaluation)

I agree the above code is more complicated. You could, however, easily 
add a small helper rule to accept 2 numbers or a pair.

With the above patch, this:
	layout-pdf [ [ image logo.gif ] ]

shows the image with the size of  100x24 mm.

When rendered by Adobe Reader at 100%, that appears about 3.5 times 
larger in each direction than
	view layout [ image logo.gif ]


Actually, it would be better to multiply by the pixels/mm  ratio. 
Let me have a look...

still, 0 0 does not seem a reasonable default for the position to 
me, unless you want the image to cover the whole page. anyway, "You 
could, however, easily add a small helper rule to accept 2 numbers 
or a pair": it's not so in v2 (because of evaluation), and I don't 
intend to do anything except necessary bug fixes for v1 :)

there's also to say, that the layout-pdf dialect is still meant to 
be rather low level. a human would write in QML or makedoc or some 
high level dialect, not layout-pdf; thus the defaults for image would 
be useless (even if a human was to write it, they'd only cover some 
10-20% of the cases, since not all images have the same dpi, and 
99% of the time you don't want the image at the bottom left corner 
of the page).

I see, and I understand and accept your position regarding the "low-level-ness" 
of the dialect.

Sorry for the confusion, but I left the line setting the default 
position commented so you could uncomment it *if* you already had 
a "current layout position" variable handy. I thought any position 
would be better than no position.

note, of course you are free to do these changes and distribute them. 
v1 is public domain actually :) (not even bsd)

Ah, but I don't want to do it if you don't think it's a good idea.

I was thnking of having pdf-maker as an output format for bubble-doc.