World: r3wp

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.

Hmm...

well, i always output pdf from programs, and the default size does 
not help much there, but i'm not saying it does harm either. if everyone 
else wants that, then go for it.

You have, of course, the benefit of knowing how the dialect works 
inside out. People new to the dialect would like to find out how 
it works by experimenting. Then it would be good to be more friendly, 
not causing error on missing parameters, similar to LAYOUT.

On balance, (and since I discovered the resuling PDF was a bit large), 
I think it's not worth me forking and complicating the dialect.

there's also the issue, that if we allow specifying a binary! instead 
of image! and interpert it as a jpeg file, then the dialect will 
have no default to use for the size, unless we go on and parse the 
jpeg header, or load the jpeg into a image! temporarily just to get 
its size. (binary! would have the added benefit to work also in Core, 
however that would only be for jpeg images)

Those are details. Any default is still better than an error (if 
trying to make the dialect forgiving and friendly). At least the 
user will see something appear, even if it has the wrong size and 
in the wrong position.

Can I use scripts of Oldes to get right encoding output of pdf from 
pdfMaker?

It seems that Rebol uses for my Win platform Win1257. 

In which encoding should I convert text for input to pdfMaker to 
get right accentuated characters in pdf generated by pdf maker?

the pdf format only supports adobe encoding, windows encoding and 
mac encoding. the pdf maker only uses windows encoding (which is 
basically latin1).

really? I cannot believe that PDF is not able to be in unicode. What 
is adobe encoding?

and which windows encoding? Maybe can janeks just set some flag or 
something which specifies his encoding in the file.

oldes: unfortunately, no. he has to specify the encoding in the font 
description. the only "built-in" encodings are Adobe, WinANSI (latin1) 
and Mac. I think adobe is a variant of latin1.

to support unicode you have to create a multibyte encoding for the 
fonts, and the spec does not give any detail on how this works.

openoffice, for example, creates n 256-character fonts instead.

that is, if you are using "Times", and you use more than 256 different 
characters, openoffice creates a pdf with two fonts, "Times1" and 
"Times2", each with at most 256 characters.

so i will either need to figure out how to create a font encoding 
description that works for utf-16 (but i guess it would require a 
huge table, and so would make the documents big), or i'll need to 
use the same technique as OO

I've just downloaded pdf-maker.r and I'd really appreciate some help 
to get going quickly. I've rotated a page +90 to get into landscape, 
but the texbox still  renders the text in the same way as portrait. 
Do I have to rotate each textbox too?


I also downloaded pdf-tables.r too. Does a  table handle a page break 
itself?


Talking of page breaks, in a long table which spans many pages, I'd 
like to render the column headings on each new page. Is there a variable 
I can track or an event I can listen for that lets me know that the 
text is about to flow to the next page.

Thanks a lot.

you may want to change the page size instead of rotating it.

also, since you refer to pdf-tables, i assume you dowloaded version 
1

hang on...

Version 1.5.0

pdf-tables lets you provide a function to create the pages, and you 
can still modify the output. so, you can create the headings separate 
from the table itself.

really? of pdf-maker?

Yes, pdf-tables, date 24-Jul-2003

in the header

ah, 1.5.0 of pdf-tables. you should have 1.24.0 of pdf-maker

sorry, checking...

pdf-maker: 1.27.1 3-Aug-2006

ah, right, that's the one with a few bugs fixed.

:-)

should be the latest 1.x version so you're fine.

ok.

5th argument to render-pages is a function that is called to make 
the scheleton of each page.

also, since the result is a block of pages, you can modify the result 
and add anything after the layout process.