Re: PageAndLineBreaking/UnifiedApproach

[Peter B. West]

Simon Pepping wrote:
...

The fact that the prototype is written in Ruby does not help. I have
never worked with Ruby before, so I have to get used to new
syntax. More importantly, I do not have good tools for Ruby. When I
try to understand code, I do not only read it. I also make extensive
use of a debugger. This allows me to see what the code actually does
to variables, in this case e.g. how the code fills the various layouts
variables, and links them back to earlier layouts. Is there a plugin
for Ruby in Eclipse that allows me to do this? Or is there another
useful tool that can help me here?


I haven't used Ruby myself, but it may be worth-while to check NetBeans. 
There is quite a lot of support for Ruby finding its way into NB. Check 
this page from the wiki. http://wiki.netbeans.org/RubyDebugging


--
Peter B. West 
Folio 

Re: PageAndLineBreaking/UnifiedApproach

[Vincent Hennebert]

Hi Simon,

Thanks for your feedback :-)

Simon Pepping wrote:
> Hi,
> 
> Vincent has made a very interesting initiative with his unified
> approach to page and line breaking. I always felt that it was too
> ambitious, but Vincent has taken the leap, and proved himself right by
> providing a prototype. I tested the prototype with some texts of
> myself, and the results looked good. The dot files illustrating the
> results are a very nice feature. Now I am trying to understand his
> approach in more detail. I have little time, so I am going slowly.
> 
> The fact that the prototype is written in Ruby does not help. I have

Yeah, I realise that this may not be very helpful to people who want to
study it. The reason I wrote it in Ruby is that it’s much more flexible
than Java, and allows to concentrate on what you have to do rather than
how you will do it. Plus it has good I/O methods that allow to quickly
produce debugging information. Considering that I rewrote it almost from
scratch two times before getting it right, I believe I made a good
choice. Had I written it in Java, I would have spent all my time in
Eclipse’s refactoring wizards.

However, I’m in the process of rewriting it in Java, for the exact
opposite reason that I wrote it in Ruby first: to go further I need the
guides provided by Java’s strong type checking system. I need to know
exactly which methods are abstract and need to be re-defined, what are
the types of the parameters, etc. Actually even I have difficulties to
read my prototype now.

I’m about to implement (simplified) tables in the prototype; given that
it’s one of the most complex kinds of layout objects, if I can get them
working that should definitely validate the whole approach (see below,
however). And while Ruby’s flexibility and loose type checking was very
helpful at the beginning, it’s too hazardous when it comes to handle the
additional complexity of tables. Hence why I’m re-writing the prototype
in Java. Even with that re-write I will still have saved time overall.


> never worked with Ruby before, so I have to get used to new
> syntax. More importantly, I do not have good tools for Ruby. When I
> try to understand code, I do not only read it. I also make extensive
> use of a debugger. This allows me to see what the code actually does
> to variables, in this case e.g. how the code fills the various layouts
> variables, and links them back to earlier layouts. Is there a plugin
> for Ruby in Eclipse that allows me to do this? Or is there another
> useful tool that can help me here?
> 
> I think it would be useful if it can be proven in some way that this
> approach allows one in principle to take side floats into
> account. That is, different line widths on a page, based on offset on
> the page. And also calculate the demerits of alternative placements of
> such a side float, such as on this page or on the next one. No actual
> implementation but the firm conviction that such an extension fits
> into the framework.

This is a very good suggestion. I decided to go for tables since it’s
also quite complex, plus contrary to side floats they are already
implemented in the current code base, so that will allow to more easily
compare both approaches. But keeping side floats in mind should allow to
avoid fundamental mistakes. Not sure I’ll be able to implement them in
the prototype (at some point I’ll have to start the real implementation
:-) ), but I’ll for sure give them a thought.


Cheers,
Vincent


-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting