World: r3wp

new update - check out test.pdf ;)

Very nice looking ! :)

URL?

http://www.colellachiara.com/soft/PDFM2/test.pdf

new update - now uses the total-fit algorithm for page breaking too. 
(major improvement wrt TeX). only works if columns have the same 
width (so there's no example of it in test.pdf yet)

new update - para alignments and a few other things. break-lines 
now always succeeds, at worst producing "ugly" output.

see test.pdf for an example of typesetting a long text into columns, 
with headers etc. (doesn't break just after a header and things like 
this)

I see the headers. I notice at the end of the second page, the final 
hyphenated word "improve-" does not continue on the next page.

first page you mean? it is intended, the textbox does not have enough 
space for all the text.

the current bug (which i'm going to fix now) is the "Introduction" 
not being hypenated in the small column in page 4.

Gab, this really looks great!! Getting the same output like TeX but 
without this chaotic installation and config stuff is very cute...

new update - finally fixed break-lines (more on this below), added 
widow/orphan penalties and setting of parameters like tolerance, 
interline glue and looseness (the latter allows increasing or decreasing 
the number of lines of a paragraph).

what the problem was with break-lines: as some of you probably know, 
when TeX cannot break a paragraph with a given stretch tolerance, 
it produces overfull boxes, assuming that in such a case manual intervention 
is desirable.

pdf maker can't do this, because manual intervention is in general 
not desirable. (i.e. an app that uses the pdf maker to produce invoices 
should not expect the user to manually fix the layout if there are 
problems)

so, contrary to TeX, it should produce underfull boxes, like any 
word processor would do.

initially i was first attempting to break lines with the normal tolerance, 
then increasing it if that failed. the problem with this approach 
is that the time needed by break-lines grows quickly with the tolerance; 
if we want it to never fail, we need to give it an infinite tolerance, 
which means considering all possible breaks, which takes forever.

so, i changed break-lines so that it never failed, but could insert 
emergency breaks if it was impossible to break the para with the 
given tolerance.

however, i underestimated the problem, since that was a source of 
infinite bugs... i wasn't doing it right.

after many attempts, i decided to think about how the algorithm was 
really supposed to work, so found a good way to implement emergency 
breaks... now i finally fixed all bugs with it and it is working 
fine.

note, that the result when using emergency breaks is not optimal. 
they are only used to allow break-lines to produce a result in all 
cases. increasing the tolerance is the only way to get optimal results.

Can Greek and Roman fonts be mixed?

not yet. that will be possible when i implement unicode support (and 
you'll need a font with all the chars you want).

will there be a method to use custom fonts?

Do you think it will be very long before you implement unicode support? 
Unicode support seems to be holding up most of what I need to do 
at present.

henrik: yes, but can't say when. (hopefully very soon)

louis: no eta at this point, but again, hopefully very soon.

new update - paragraph margins; as a side effect this now allows 
drop caps and paragraph shapes (check out the circle paragraph in 
the second page).

Looks very good.

What about pagination?

I mean, page numbering with footers etc...

Very cool looking now.

Does REBOL have to support unicode before PDF-Maker can support unicode?

I am extremely interested in this project. Thank you Gabriele for 
all the work and expertise going into this. It looks great!

Gabriele can use my script for unicode conversions: http://box.lebeda.ws/~hmm/rebol/projects/ucs2/latest/ucs2.r

With the utf-8 converter it must be enough as it's enough to make 
SWF files in my Rebol/Flash dialect

luis: no, rebol does not need unicode support.

oldes: i have an utf8 parser too. however it's not that easy because 
the PDF format does not support unicode directly. you have to create 
custom fonts. i have to study this in detail, but i noticed that 
OpenOffice generates a font for each set of 256 characters.

graham: for footers with the current chapter/section etc. i'm going 
to do the same as TeX (should be rather easy to implement). i have 
to think how to resolve them and page numbers into text though, but 
in simple cases it's quite easy to do (the more general case will 
need some thinking)

at worst we'll do like LaTeX and use n passes to resolve page number 
references.

How about this for an idea: you allocate space for each page reference 
as if it's the largest likely page, eg 9999. As each page reference 
is resolved, you get some space back, but that reclaimed space becomes 
"dead" whitespace (probably placed at the end of the page, or distributed 
amongst other whitespace), and it does not cause an earlier  page-break. 
So the page reference resolution will not affect the pagination.

but then you're no more getting an optimal solution. :)

my plan is to eventually add a "simple" text mode for use when you 
care for speed instead of quality.

That's true....

So an application would operate in simple" mode most of the time, 
but final render would use the expensive algorithm that requires 
n passes.

yes... if you're typesetting a book, you'll want the quality; if 
you're typesetting an invoice, you won't care about justification 
with the total-fit algorithm (although, the total-fit algorithm could 
still help to break pages when there are tables)

An invoice usually wouldn't be more than one or two pages ! :)

OTOH it would be highly practical with custom fonts, such as OCR 
fonts for invoices. also tables are very useful.

Any chance of being able to create pdf forms ?

not on my list. maybe in the future.

so... noone willing to write the user docs?