Hi Simon,

Thanks for your feedback!

Sorry for the late answer, I was mostly off-line during the past week
(and will be until the end of the month anyway).

I’ve just committed a bunch of changes I made to the prototype, that
turned out to be necessary for implementing tables. Note that the
changes are quite massive; it will probably be easier to forget the old
prototype and study the new one from scratch. Thinking about tables
revealed a whole lot of issues that couldn’t be handled by the first
version. The best example is the fact that we must be able to pause the
iteration over Knuth elements, in order to have a chance to somehow
merge the contents from table cells (well, actually... more later).

I wanted to wait, before committing my changes, that I have a working
version with tables, because until then I can’t be sure that I won’t
have to put everything upside down again. In the past month already,
I brought major changes 3 times. I thought it would have been more
confusing to get a series of experimental changes, rather than
a slightly more finished piece of code in once (several classes made
a short appearance during the process, to then disappear).

Anyway, since I’m mostly offline until the end of the month I can
publish my changes, so that interested people can have a look meanwhile
if they get a chance to. Regarding tables I have an embryo of an
implementation, still way too experimental to be published. But a few
things in the current prototype that may sound strange are actually used
for tables.

If you run this new version on the example that’s posted on the wiki you
will notice that the result is different; now the 4-line version of the
first paragraph is preferred to the 5-line one. In fact this 4-line
version not only looks better, but it /is/ also better in the
algorithm’s criteria (it has less demerits). But there was a bug in the
first prototype that wasn’t taking into account the demerits of
a paragraph when considering a whole page. It’s as if both versions of
the first paragraph had zero demerits. What I’m trying to explain on the
wiki page is basically rubbish, and the latest version of the prototype
now behaves as expected.

Additional comments inline:

Simon Pepping wrote:
> Vincent,
> 
> I have finally studied your prototype. It looks very good. Your method
> is basically the same as you put forward during your GSoC work: a
> single sequence of feasible nodes, mixing both line and pagebreak
> nodes.

This has slightly evolved now. The idea was: “I have a feasible line
break, let’s see if it makes a feasible page break.”. The new idea is
more along the lines of:
“— Give me the next set of complete lines.
— Here you go, they all end on that word.
— Thanks, I’ll see if some of them make a complete page.”


> I found the programming style quite compact, and had trouble getting
> into understanding the code. The naming also did not help: A
> LineLayout class which has a member lineLayout which is a Layout
> object. A member layouts which has a member layouts. I did some
> renaming to make this clearer to myself: OneLevelLayout,
> TwoLevelLayout, and layoutsholder which holds a list, called layouts,
> of Layouts.

You reached the same conclusion as me :-) This LineLayout object was
really weird. A LineLayout is now a layout made of line-level elements
(the words and spaces of the paragraph). It holds a reference to the
block-level layout, the block context in which it was created. The line-
and page-level breaking are more clearly separated now.


> The lineLayout member of LineLayout is somewhat redundant: members
> previous and alternatives do not play a role;

This hasn’t changed I’m afraid. Previous could possibly be set to
something meaningful (if not useful). A proper class hierarchy might be
the answer, with common stuff put in an abstract class, then
specializations into a block-level branch and a line-level branch.


> lineLayout.progress.partNumber counts the lines in a paragraph, and is
> only used to skip the first layout of a paragraph in the layout
> dump.

In a longer term it will be necessary to handle widows and orphans; for
now it’s not even updated properly...


> This redundant information can be misleading when one tries to
> understand the algorithm.
> 
> The prototype now needs an input module which allows more testing. The
> module should allow one to input boxes of various height.

Unless I’m misunderstanding you, it’s already possible. You can put
boxes of a certain height in a BlockLayoutManager. See
LayoutEngine.addContentWithBlock.


> This will help discover errors in the resulting layout. When I have 
> time I will try to use a module similar to the one I used in my own 
> prototype for Knuth elements (see my website).
> 
> It would be nice if you would try to enable ms windows users to work
> with your prototype: /tmp does not exist on ms windows. Re your wiki
> page: dot files can be rendered on ms windows.

I must say that this doesn’t even appear on my priority list... It’s
possible to change the output files by modifying the Dot.createGraph
method. People will usually set that only once at the beginning, so
that’s enough I guess.
BTW on the wiki page I was more referring to the installation of the
Graphviz tool than the displaying of PostScript files; it didn’t even
occurred to me that that latter could not be straightforward :-P
Anyway, I discovered that dot can directly produce PDF files. The manual
page I consulted was not up-to-date.


Vincent

Reply via email to