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
