On 18.06.2006 13:26:00 Manuel Mall wrote:
On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
I just realized we should think about the right moment to release
1.0. I guess the number of fixed bugs would suggest a new release
rather sooner than later. I originally thought about going for
On 18.06.2006 22:54:41 J.Pietschmann wrote:
Jeremias Maerki wrote:
I just realized we should think about the right moment to release 1.0.
I think 1.0 should implement page masters with different
body width in the same page sequence.
Ok, if we want that 1.0 won't be out before September.
On 18.06.2006 20:50:31 Simon Pepping wrote:
On Sun, Jun 18, 2006 at 07:26:00PM +0800, Manuel Mall wrote:
On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
look a little deeper into the issue. I suspect both items will
require substantial changes in the layout engine which are probably
On 18.06.2006 20:57:51 Simon Pepping wrote:
On Sun, Jun 18, 2006 at 07:36:45PM +0800, Manuel Mall wrote:
I had a quick fiddle in one area and changed the Knuth penalty generated
for a keep...=always from INFINITE to INFINITE-1. In my few test
cases that seem to have resolved the issue.
Jeremias Maerki wrote:
On 18.06.2006 13:26:00 Manuel Mall wrote:
snip/
Calling a release 1.0 is IMO quite a significant step which shouldn't
been taken lightly. What we are saying in doing so is: Here is
something we believe is ready for production use.
Yes, but neither should we put
Jeremias Maerki wrote:
On 18.06.2006 20:50:31 Simon Pepping wrote:
snip/
So maybe we need a feature freeze and bug fixing period?
Not only that. We need a Wiki page listing all issues everyone wants to
see fixed/handled before a 1.0 release. We can then decide on which
subset we are
FYI: I'm planning to refactor the breaking algorithm in order to
implement floats. I'll see what can be done in this area. Just keep in
touch.
Vincent
Manuel Mall a écrit :
On Monday 19 June 2006 16:45, Jeremias Maerki wrote:
On 18.06.2006 20:57:51 Simon Pepping wrote:
On Sun, Jun 18,
On Monday 19 June 2006 20:25, Jeremias Maerki wrote:
On 19.06.2006 13:38:56 Manuel Mall wrote:
On Monday 19 June 2006 16:45, Jeremias Maerki wrote:
On 18.06.2006 20:57:51 Simon Pepping wrote:
On Sun, Jun 18, 2006 at 07:36:45PM +0800, Manuel Mall wrote:
snip/
Or should we use a
On 19.06.2006 14:45:02 Manuel Mall wrote:
snip/
What is still unclear to me is if it is worthwhile to implement this two
pass approach, i.e. use INFINITE penalties first and relax later, or if
it is good enough for 99.99% of cases just to start with INFINITE-1
penalties for mandatory
Manuel Mall wrote:
What is still unclear to me is if it is worthwhile to implement this
two pass approach, i.e. use INFINITE penalties first and relax later, or if
it is good enough for 99.99% of cases just to start with INFINITE-1
penalties for mandatory keeps?
I think the second pass is
Dear Fop developers,
after a while and some thinking, here is my concept for extensible
image handlers for fop, or even better for xmlgraphics. If desired, I
can implement this concept for xmlgraphics / fop with support for
imageio, jimi and batik.
Image handling is a three-step
On 19.06.2006 16:52:25 Max Berger wrote:
Dear Fop developers,
after a while and some thinking, here is my concept for extensible
image handlers for fop, or even better for xmlgraphics. If desired, I
can implement this concept for xmlgraphics / fop with support for
imageio, jimi and
On 19.06.2006 15:45:36 Luca Furini wrote:
Manuel Mall wrote:
What is still unclear to me is if it is worthwhile to implement this
two pass approach, i.e. use INFINITE penalties first and relax later, or if
it is good enough for 99.99% of cases just to start with INFINITE-1
penalties
Indeed, the problem is your use of table-cells which are not defined by
table-column elements. The current FOP Trunk code doesn't fail anymore
in this constellation and outputs an informative warning. But I still
suggest you define those table-column elements for each column. RTF
could probably
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=39840.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=39840.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=39840.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=39840.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=39840.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
19 matches
Mail list logo
