World: r3wp

Carl should use pdf-maker to generate PDFs of the online docs

Is qtask using pdf-maker?

no. initially, we wanted to use it for wikis (ie. see my qml to pdf 
code), but the fact that the pdf was not an exact replica of the 
html output was not considered acceptable.

I tried this 

			append new-page compose/deep [
				textbox 10 10 100 100 [
					image 0 0 40 40 (load %247logo.png)
				]
			]
and not seeing any image in the pdf ..

graphic commands such as image are separate from text commands. inside 
a text "context", you can use box or vbox to enter a graphic "context". 
(also, you don't need the compose, as the dialect will try to evaluate 
arguments anyway.)

So:

    textbox 10 10 100 100 [
        box [image 0 0 40 40 load %247logo.png]
    ]


The difference between BOX and VBOX is that the former is treated 
like a character, while the latter is treated like a paragraph. (So 
you can have the former in the middle of a text line.)

ok, I'll try it again .. just with the above I got an error about 
expecting an image so I added the compose

Unless there's a bug, that should work...

When I use this command, I don't get an image, and my 13 page pdf 
stops at the first page

this is the end of the file 

endstream
endobj
8 0 obj
<< /Type /Pages /Kids [6 0 R] /Count 1 >>
endobj
1 0 obj
<< /Type /Catalog /Version /1.4 /Outlines 2 0 R /Pages 8 0 R >>
endobj
2 0 obj
<< /Type /Outlines /Count 0 >>
endobj
3 0 obj
[/PDF /Text /ImageC]
endobj
xref
0 9
0000000000 65535 f 
0000005180 00000 n 
0000005259 00000 n 
0000005305 00000 n 
0000000009 00000 n 
0000000111 00000 n 
0000000208 00000 n 
0000000414 00000 n 
0000005123 00000 n 
trailer
<< /Size 9 /Root 1 0 R >>
startxref
5341
%%EOF

there's no png there...

ah, sorry, box requires more args, checking...

box width height depth [...gfx commands...]

depth controls the offset relative to the text baseline, for eg. 
the letter 'q' has a positive depth because the stem goes below the 
text baseline.

ok, trying again

append new-page compose/deep [
				textbox 10 10 100 100 [
					box 60 60 10 [image 0 0 40 40 load %247logo.png]
				]
			]

Doesn't work either

similar 

justify with margins mrgns box iw lh 0 [
                image xbl ybl - ih + lh iw ih img
            ] space 2

uh... while testing this, i got this:

>> i: load http://www.rebol.com/graphics/reb-logo.gif
connecting to: www.rebol.com
== GIF89a\ufffd
>> load read/binary http://www.rebol.com/graphics/reb-logo.gif
connecting to: www.rebol.com
Segmentation fault

linux?

of course

ah, wait, that was probably my fault... (yes, linux, i guess it should 
not segfault though)

this works for me:


b: layout-pdf [[textbox [box 60 60 10 [image 0 0 40 40 load http://www.rebol.com/graphics/reb-logo.gif]]]]

the image comes at the bottom though, which does not look correct, 
so I'm probably forgetting something...

Interesting .. I get nothing

right... i don't do a coordinate transformation, that's the reason 
for xbl and ybl in the above snippet

you get xbl (X Bottom Left), ybl, xtr, ytr bound within the graphic 
block

Copyright (c) 2001-2005, Gabriele Santilli

is that pdf-maker1 or 2 ?

http://www.colellachiara.com/soft/PDFM2/pdf-maker.html

Gabriele Santilli <[giesse-:-rebol-:-it]>
17-Nov-2006, 2.34.0

v2 was done between 8-Aug-2006 and 17-Nov-2006

Ok, got it

got the image.

b: layout-pdf [[textbox ["Image: " box 60 60 10 [image xbl ybl 40 
40 load http://www.rebol.com/graphics/reb-logo.gif] " inside text"]]]

That puts the image inside the text correctly. v2 should also give 
you an error when the dialect is wrong, while v1 did just fail silently.

so this syntax doesn't work with pdf maker 1 ?

so I got the silent fail

no. v1 does not flow text automatically across pages, does not allow 
putting graphics within text, does not have the TeX engine, and so 
on.

v1 also does not evaluate arguments to dialect commands so you have 
to use compose etc.

ah... I've been using V1

I have this ...

if not value? 'layout-pdf [ *do %pdf-maker.r ]

v1 is very stable, v2 has never been exstensively tested. so it's 
not a easy choice i guess :)

so Cheyenne already had v1 loaded and didn't load v2 for me !

I'd suggest that perhaps this is because you never managed to write 
the user documentation!

I should have a layout-pdf2 .... so I can use both

v1 had much less docs than v2 :-)

Hmm... quantively or qualitatively?

I think the main reason is that v2 was never really "finished" and 
published as such. it's missing many little things (though, it should 
do all that v1 does and more... it is slower though as it's missing 
optimization and the ability to turn off the TeX engine when you 
don't need it)

a lot of people managed to use V1 .. I've never seen anyone use V2

well... the "tutorial" for v1 mostly works for v2 as well, as it 
only covers very basic functionality.

text and bezier curves :)

(but more importantly... why do you guys always expect me to do all 
the work? :P )