DO NOT REPLY [Bug 45151] Building FOP from sources requries ant 1.7
https://issues.apache.org/bugzilla/show_bug.cgi?id=45151 Jeremias Maerki [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremias Maerki [EMAIL PROTECTED] 2008-06-17 01:00:39 PST --- Requirement for Ant 1.7 noted on the compiling page. The README file already points to this page. Thanks for the hint! http://svn.apache.org/viewvc?rev=668533view=rev (the change will be propagated to trunk and the website soon) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45146] duplicate license.txt constrains ClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=45146 Jeremias Maerki [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremias Maerki [EMAIL PROTECTED] 2008-06-17 01:06:57 PST --- Thanks for the hint. This is now fixed in the 0.95 branch: http://svn.apache.org/viewvc?rev=668550view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: svn commit: r668570 - /xmlgraphics/fop/branches/fop-0_95/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java
On Jun 17, 2008, at 10:54, [EMAIL PROTECTED] wrote: Author: jeremias Date: Tue Jun 17 01:54:07 2008 New Revision: 668570 URL: http://svn.apache.org/viewvc?rev=668570view=rev Log: Wrong line number reported in the case of a line overflow. Too fast for me... :-) Cheers Andreas
Re: PageAndLineBreaking/UnifiedApproach
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
Re: PageAndLineBreaking/UnifiedApproach
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 http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Interleaved page and linebreaking branch
Hi Simon, FWIW, I don’t think what you did in your branch should be thrown away completely. Some of the issues you solved in this branch might be mostly (if not directly) translatable in my own approach. When I start a real implementation I have good hope that I will be able to take back some of those changes. More on this later, obviously. Simon Pepping wrote: Hi, Chris recently mentioned my interleaved page and linbreaking branch as an active branch. I have not been very active recently. One reason is that I got stuck with block containers. FOP's approach is to collect Knuth elements for a block list, doing line breaking at the same time, and then do the page breaking. I do a similar thing, but do line breaking not in the collection phase but in the page breaking phase. For block containers this has the consequence that its block lists have to be collected in the overall collection phase, but that its page breaking has to be postponed to the overall page breaking phase. I was not very successful in separating these two phases. And I started to question this idea, because in the end we want to integrate element collection and page and line breaking, not separate them. The other reason is that Vincent is working on his approach, which is a step further towards the eventual goal. Therefore it makes no sense to work further on my own approach, the more so since he can spend much more time to his approach. The final reason is that I can spend far less time on FOP coding during this summer. I will spend what time I have on supporting Vincent's approach. Regards, Simon Cheers, Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
