Thanks Simon. Now I understand. I've just committed the general fix for
the problem (I think), but have hard-coded the penalty value to 900 for
the moment. I think your idea might be interesting but I'm a little
clueless about the right formula to calculate an appropriate penalty
value. I'll leave
Merely FYI: slight correction needed...
On 30.07.2005 15:14:04 Andreas L Delmelle wrote:
Currently, I don't think we already have a mapping of these
object->applicable_props anywhere, ...
We do have such a map in org.apache.fop.fo.PropertySets, but I don't
get the impression that it is equi
On Sat, Jul 30, 2005 at 03:46:31PM +0200, Jeremias Maerki wrote:
> Sorry, but I have trouble understanding what you mean. Could you please
> elaborate with an example? Thanks.
>
> On 30.07.2005 13:54:25 Simon Pepping wrote:
> > On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote:
> > >
Thanks for looking it up. I've put it on the todo list on the Wiki so it
doesn't get forgotten. It's low priority anyway. It's probably a good
exercise for someone who wants to get into how the FO tree works.
On 30.07.2005 15:14:04 Andreas L Delmelle wrote:
> -BEGIN PGP SIGNED MESSAGE-
> H
On 30.07.2005 13:07:40 Andreas L Delmelle wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jul 29, 2005, at 23:25, Jeremias Maerki wrote:
>
> > Strike that. Just found a mean case where my quick hack breaks. Back to
> > frame one and a half. It's going to be a bit more difficult.
Sorry, but I have trouble understanding what you mean. Could you please
elaborate with an example? Thanks.
On 30.07.2005 13:54:25 Simon Pepping wrote:
> On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote:
> > I was under the impression that the breaker automatically favors break
> > d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 30, 2005, at 11:51, Jeremias Maerki wrote:
D'oh, right. :-) Lucky me.
Too bad, we don't generate validation warnings for misplaced
non-inherited properties. Didn't we have that discussion already this
year? I can't find it or am I imagining
On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote:
> I was under the impression that the breaker automatically favors break
> decisions that take up less space. It even goes so far that if you have
> a minimum="0pt" and an optimum="2opt" on a space-before, that it
> currently chooses
On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote:
> But I get the impression that this avoids the topic I raised. :-) I
> think this here is not about whether these special break conditions are
> favored or avoided but if they should be allowed at all.
OK. Yes, the rule you propose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 29, 2005, at 23:25, Jeremias Maerki wrote:
Strike that. Just found a mean case where my quick hack breaks. Back to
frame one and a half. It's going to be a bit more difficult.
FWIW: It occurred to me that, with a break-before="page" on the
D'oh, right. :-) Lucky me.
Too bad, we don't generate validation warnings for misplaced
non-inherited properties. Didn't we have that discussion already this
year? I can't find it or am I imagining it?
On 30.07.2005 03:47:45 Andreas L Delmelle wrote:
> On Jul 28, 2005, at 14:04, Jeremias Maerki w
On Jul 28, 2005, at 14:04, Jeremias Maerki wrote:
On 28.07.2005 13:42:08 Andreas L Delmelle wrote:
Where it comes to rowspans:
In my modified example, if you move all the text in the middle column
to the first row and make that cell span two rows, things get a bit
awkward without the proposed
Strike that. Just found a mean case where my quick hack breaks. Back to
frame one and a half. It's going to be a bit more difficult.
On 29.07.2005 23:04:08 Jeremias Maerki wrote:
> As I suspected, implementing the rule I proposed was very easy to
> implement (13 new lines).
Jeremias Maerki
On 28.07.2005 15:12:50 Chris Bowditch wrote:
> I've been following this thread with interest. From a conceptual point
> of view, I agree with Andreas. I can't see any situation where you might
> want to have cells of the same row group on separate pages. Regardless
> of how many rows a particul
I've been following this thread with interest. From a conceptual point
of view, I agree with Andreas. I can't see any situation where you might
want to have cells of the same row group on separate pages. Regardless
of how many rows a particular cell spans.
Is there nothing in the spec to give
On 28.07.2005 13:42:08 Andreas L Delmelle wrote:
> On Jul 28, 2005, at 10:10, Jeremias Maerki wrote:
>
> > On 27.07.2005 23:26:48 Andreas L Delmelle wrote:
> >> Indeed, doesn't look right. Given the value for the orphans property,
> >> one still would reasonably expect the break to occur before t
On Jul 28, 2005, at 10:10, Jeremias Maerki wrote:
On 27.07.2005 23:26:48 Andreas L Delmelle wrote:
Indeed, doesn't look right. Given the value for the orphans property,
one still would reasonably expect the break to occur before the first
cell of the second row.
...or after the first 3 lines
On 27.07.2005 23:26:48 Andreas L Delmelle wrote:
> On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:
>
> Hi,
>
> > I got a test case for tables which raises not a technical but rather a
> > interesting conceptual question. Please have a look at the attached
> > test
> > case. It defines a tabl
Sorry, forgot the attachment...
table-body4b.xml.head.pdf
Description: Adobe PDF document
On Jul 27, 2005, at 23:26, Andreas L Delmelle wrote:
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:
Hi,
I got a test case for tables which raises not a technical but rather a
interesting concept
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:
Hi,
I got a test case for tables which raises not a technical but rather a
interesting conceptual question. Please have a look at the attached
test
case. It defines a table with two columns and two rows. In the given
setup the second row crea
I was under the impression that the breaker automatically favors break
decisions that take up less space. It even goes so far that if you have
a minimum="0pt" and an optimum="2opt" on a space-before, that it
currently chooses "0pt" which is not so good, actually.
Well, we have several documented e
One thing that IMHO is still lacking in the table breaking code is
penalty values. ATM all penalties are 0. I believe the penalty value
should depend on the extra vertical size that the break contributes,
that is, on the penalty's width. I have no idea about the
multiplication constant, nor if it s
I got a test case for tables which raises not a technical but rather a
interesting conceptual question. Please have a look at the attached test
case. It defines a table with two columns and two rows. In the given
setup the second row creates an break decision with the current code that
can be argue
23 matches
Mail list logo
