World: r3wp

this would also mean that the table's columns need to have a different 
width across pages. ie column 1 in page 1 has a different width from 
column 1 in page 2.

Nope.

I think that could be useful. As tables get longer (and need to be 
broken across pages) it becomes more probable that it has data with 
a very wide range of widths. In that case, reproportioning the table 
for each page makes sense. But perhaps when crowding between cells 
occurs because of very wide entries, simply wrapping text within 
cells would allow the column width to remain the same for the whole 
table.

On the whole, I would prefer to have consistent column widths, but 
there might be cases where that's really annoying. I would probably 
put that as a lower priority feature for now.

how would you expect vertical alignment to be handled when a cell 
gets split into two for page breaking?

Mmm.... that depends on the whim of the user. Splitting some types 
of data might be misleading.

Would you indicate that the table is split for a page break (by not 
drawing the bottom line of the table on the first page, and not drawing 
the top line on the second page etc.)

?

that's a different issue.

a data table like the one you're thinking about most likely has one 
line of text for each row. that would be split at row boundaries 
only.

Yes, but I think it's connected because it allows one to be more 
aware that the cell might have been split.

i was thinking initially to allow two modes of splitting cells: cut 
and split.

cut would work like the cell was just cut with scissors.

I think it's safer to keep each row together with itself by default.

split would instead create two cells from the original one.

however, there is a race condition with cut. so i'm going to always 
do split.

What's the purpose of split ?

Also, cut and split - it's difficult to distinguish the difference. 
Need better words.

Really ? So it's easier to do split ?

cut would not cut it at a random place. the difference is borders 
and margins (and padding)

So - split is your preferred method over cut, but what about the 
option to move the entire row to the next page if it doesn't quite 
fit on this one ?

that is a matter of how big it is the row.

if it's half a page it's probably much better to split it in two

How to control all these variables !!! It's a big job, isn't it ?

notice that tables can be used for many things, for example to layout 
a numbered list, with the number in the first cell and the text in 
the second

yes it is. :)

the total fit algorithm can do most of this. the problem are the 
"minor" details like vertical alignment.

basically i must find all possible breakpoints in each row. the problem 
is what to do with vertical alignment: if you have a cell that should 
be aligned in the middle, and there's a bigger cell that gets split, 
how does the smaller one get aligned?

As soon as you said that, I thought of a default threshold cell size 
which decides between splitting and moving to next page. And then 
this can be overridden by the user, who can move the threshold between 
0% and 100%,  0% indicating always split, and 100% indicating always 
move.

That's not a nice problem. :-(  I think if the user has some control 
of the variables (eg. maybe threshold), then they can influence what 
happens there.

Perhaps certain cells can be set to "never split" ?

(or certain rows)

that is possible using penalties.

I think that might be the simple answer, actually. It is only when 
the software makes a blunder with intelligent splitting that it becomes 
a problem. If the user can force a row to always remain together 
that would solve most of those problems.

a paragraph of two lines already has a big penalty for being split. 
so generally it is kept together.

basically you're saying: either you allow vertical alignment, or 
cell splitting.

which is one possible solution.

(Ok, so the algorithm looks for the lowest penalties first.)

the algorithm produces the layout with the least total demerits.

Yes, I think it will be the easiest and simplest solution.

(in some cases it doesn't, because it would require too much time, 
but the user decides this, by setting the tolerance)

(That's not to say people won't be looking for more complex interactions, 
but I think the simplest way solves most complaints the quickest.)

ok, i will think more about the problem (still hope to find some 
kind of nice solution), and see what others think too.

Cool, good luck.

What do the current LaTeX to DPF programs do?

Reichart, I'm still learning about TeX, but I'll guess, LaTeX to 
PDF take output from LaTeX (a TeX document) and convert it to the 
PDF format. To see output from LaTeX, you still need a TeX engine 
to view the document in the final form. Convert it to PDF, and you 
just need a PDF viewer.

About tables? TeX only handles very simple tables. Absolutely not 
enough to get QML tables there.

(you can do almost everything with TeX by using tricks, but you basically 
need to layout the table manually. it is not able to do that automatically 
- something that we need to do instead.)

That was what I figured.

update: added preliminary table support.

(the table dialect is still very basic, just for testing. table layout 
seems to work well, uses the total-fit algorithm and should create 
optimal layouts in most usual cases. there are boundary cases where 
it can fail, but i hope we won't need to worry about them. check 
test.pdf for an example of a table.)

Somehow I lost the link to the PDF-Maker test site. Would someone 
please post it.