World: r3wp

Isn't that one of the formats for Acrobat Forms ? There should be 
several types, like xfdf and the like .... but I'm not 100% sure.

Yes ... it is.  But documentation seems lacking, and it appears to 
be deprecated by Adobe.

update: many bugfixes

I didn't notice much different in test.pdf. Probably small differences 
there. I keep looking at that circle and wondering if the centre 
can be positioned so that there's as much text on the first row as 
the final row.

the bugs were not visible in test.pdf, but they were in various qml 
documents. :) i will upload the new qml-ed very soon.

circle: i didn't spend much time on it. it's done by just setting 
the margins of each line so that it looks like a circle. :)

Ah :)

update: images; embedding gfx into text. (see last page of test.pdf)

You can also 
display" graphics:"

and after that, there is a box. is this correct?

very nice, by the way :-)

yes. not great gfx i know, but shows that it works ;)

i should add something instead of that box... maybe i should convert 
something from draw.

is the image of you compressed in some way?

nope. that's why it's big

I guess compression is hard to do?

well... run-length or similar should not be a big problem (will be 
slow, but maybe the result of compress does work after removing header)

but jpg is nothing i want to write in rebol ;)

would take minutes to compress anyway...

one possibilty would be: pass jpg file name, not image!; parse jpeg 
file for jpeg data; embed jpeg data in the pdf

if compress does work, that could be applied to everything else too, 
so the resulting file would be surely smaller.

but i guess i'm not so lucky that compress is compatible...

you could use edgar's image-magic examples and use image magic if 
pro licence and image magic is found... its going to be Extremely 
fast.

max: sure but you still have to parse the resulting jpeg data

(embed jpg file saved from rebol and converted to jpeg with image-magic)

it would be nice if compress had more modes that are "strategically" 
made to be compatible with various types of binaries where such compressed 
data is embedded.

also every image to jpg is not a good idea (users may not want that, 
if the image is not a photo but a drawing for eg)

i will eventually have a look at this... for now, i'm happy with 
them being uncompressed :)

yes!  compress/RLA  compress/ZIP  compress/GZIP  compress/JPEG   
 compress/MP3

(and compress/TAR)

isn't the current compress, a gz compression lacking some headers?

I seem to remember someone building a wrapper around compress to 
cope with this issue... yes... but its sooo long ago... maybe it 
was something else.

maybe a compression group would be in order...

i think compress is from zlib

Oldes made a zlib compressor/decompressor. I found it in my cache:
	public/box.lebeda.ws/~hmm/rebol/zlib/latest/zlib.r

but it's not there on the web, apparently. Try check for his latest 
website.

But it's Rebol?pro version (using a dll) http://oldes.multimedia.cz/rebol/zlib_latest.rip

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 ...