Hi Mathias > -----Original Message----- > From: Matthias Reischenbacher [mailto:[email protected]]
> thanks for your reply. I'm not quite sure if your mentioned bugzilla entry > is really related because I'm not using fixed row heights. Perhaps Vincent > can shed some light on this. I'd be interested in knowing how a keep > condition is enforced in general (using Non-break Knuth elements?) ... The basics are pretty straightforward, especially for a keep-constraint with strength of "always". In the Knuth model, a box is /never/ a legal breakpoint, so to enforce a keep between two boxes, nothing special needs to happen. Two consecutive boxes will always be kept together, no matter what. A penalty, on the other hand, is always a legal breakpoint /unless/ it has value "infinite", in which case it prevents a break from occurring. Lastly, a glue is only a legal breakpoint if it is preceded by a box. So, to keep a glue together with a preceding box, we need to insert an infinite penalty to prevent the break. If I recall correctly, integer keep-values still behave roughly similar to "always", as it is non-trivial to "discourage" a break purely by means of auxiliary elements. Inserting a non-infinite penalty, even with an insanely high value, still generates a break-possibility that may be selected by the algorithm contrary to what one would expect (e.g. when there are regular box-glue combinations or other penalties with a lower value nearby). > and where the probable cause lies (missing break elements or incorrect break > algorithm?). As Vincent already indicated, the issue is likely located in the table-layout code, more precisely the element-list generation. However, it may simply point to a limitation in our implementation of page- and column-keeps... Since the keep is defined as a keep.within-page, a zero penalty is used, since strictly speaking, a column-break is still permitted. That said, I think you may be able to work around the issue by specifying it as keep-together.within-column="always", if that fits the use-case. HTH! Regards, Andreas --- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
