Manuel Mall wrote:
As far as I remember our last discussion was about who should generate the
Knuth element lists: The individual layout managers or the Line layout
manager. You argued in favour of retaining the current system and I tended
to favour the moving it up the hierarchy to the line
After just upgrading to the latest svn version I get a test case
failure. As I haven't updated for a few days I am not sure which patch
caused this.
Manuel
[junit] Testcase:
table_width.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1):
Caused an ERROR
[junit] Expected XPath
I don't know, either. It looks like the line breaker is stumbling over a
Knuth sequence without a single box due to an FOText with only
whitespace (IndexOutOfBoundsException in BreakingAlgorithm, line 367). I
guess it must have something to do with the recent changes in whitespace
handling.
On
On Thursday 02 February 2006 16:49, Jeremias Maerki wrote:
My gut feeling here is that it is now more correct than before but
there are still two trailing spaces in the area tree that I'd
expected not to be there. But then, I still haven't done my homework
concerning whitespace handling. :-(
On Thursday 02 February 2006 17:46, Luca Furini wrote:
Manuel Mall wrote:
As far as I remember our last discussion was about who should
generate the Knuth element lists: The individual layout managers or
the Line layout manager. You argued in favour of retaining the
current system and I
On 02.02.2006 12:37:13 Manuel Mall wrote:
On Thursday 02 February 2006 16:49, Jeremias Maerki wrote:
My gut feeling here is that it is now more correct than before but
there are still two trailing spaces in the area tree that I'd
expected not to be there. But then, I still haven't done my
Manuel Mall wrote:
What about using the UnresolvedElements? Just as per the block-level
space resolution, each inlineLM could append at the beginning and at
the end of its element list an UnresolvedElement storing its border,
padding and spacing information.
I don't know anything about the
I've got customers asking when the next release is planned. I think it
would be good to think about it. How about targetting for the end of
February or beginning of March? Is that enough to considerably improve
the whitespace handling situation? Another question will be what to call
the next
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38453.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Feb 2, 2006, at 15:19, Jeremias Maerki wrote:
I've got customers asking when the next release is planned. I think it
would be good to think about it. How about targetting for the end of
February or beginning of March? Is that enough to considerably improve
the whitespace handling situation?
On Feb 2, 2006, at 12:10, Jeremias Maerki wrote:
Hi guys,
Weird. The test in question passes w/o problems on my side... Just
made a diff of the complete sources, and stumbled upon this:
Index: src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java
On Friday 03 February 2006 01:30, Andreas L Delmelle wrote:
On Feb 2, 2006, at 12:10, Jeremias Maerki wrote:
snip/
I'm clueless as to where this comes from, since I don't remember
having altered this myself (so, I have absolutely no idea *why* I
would have altered it)... maybe I've just had
Thanks for the update, Jeremias!, BTW, there are a bunch of links on
the bottom:
News - Release Notes - Changes - Known Issues - FAQ
Does it make sense to include separate links in the FOOTER/README for
0.20.5 0.91 beta?
e.g.:
===
Latest Stable Release (0.20.5):
News - Release Notes
I reduced the stuff in README.html to the absolute minimum and made it
explicitely version-agnostic, so we have less redundancy and a smaller
chance that we forget to update some information when we do a release.
Doing a release is already a LOT of work (around one full day for one
person) and I
14 matches
Mail list logo
