Jeremias Maerki wrote:
Hi Jeremias,
I finally have Knuth's Digital Typography and let myself enlighten by
his well-written words. In [1] Simon outlined different strategies for
page-breaking, obviously closely following the different approaches
defined by Knuth. At first glance, I'd say that
--- Chris Bowditch [EMAIL PROTECTED] wrote:
As for the plan to implement a new page-breaking
mechanism: I've got to
do it now. :-) I'm sorry if this may put some
pressure on some of you.
I'm also not sure if I'm fit already to tackle it,
but I've got to
do it anyway. Since I don't
I'd rather not work on HEAD directly because after creating the basics
for the new mechanism the whole thing will probably not work for some
time (probably 2-4 weeks). But I'd like to be able to check in early so
people can review. I expect that the life time of the branch will not
exceed 8 weeks.
Just a sanity check here, the XSL specification seems
to suggest always the first-fit strategy for page
breaking *except* where keeps are explicitly
specified. Am I correct here? And, if so, is what
you're planning going to result in an algorithm that
will help us do this?
Thanks,
Glen
---
Where did you find such a suggestion? I'd be interested to know if
there's a hint in this direction in the spec. I thought it was up to the
implementation to decide the strategy.
I think the way we're now taking in our discussion suggests that we're
not going to do a first-fit strategy at all. If
I'm unsure here. My interpretation comes from two
places:
1.) Section 4.8, the last paragraph of [1]:
The area tree is constrained to satisfy all break
conditions imposed. ***Each keep condition must also
be satisfied***, except when this would cause a break
condition or a stronger keep
Thanks. I think this has only to do with the rules to handle keeps and
breaks and how to resolve conflicts. I don't think, however, that these
parts create a restriction which tells us what page-breaking strategy to
pursue. We could probably run with a first-fit strategy and still
fulfill the
Yes, I'm not in Simon's league here--I know very
little about TeX--so I'll defer to you two on this
issue. Just try to make sure that the final algorithm
will help us support the keep-* properties.
Thanks,
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Thanks. I think this has only to do
On 02.03.2005 17:05:55 Glen Mazza wrote:
Yes, I'm not in Simon's league here--I know very
little about TeX--so I'll defer to you two on this
issue.
I'm also still struggling. :-)
Just try to make sure that the final algorithm
will help us support the keep-* properties.
Yes, the algorithm
Jeremias Maerki wrote:
processing time and additional memory requirements. This
leads me to the question if we shouldn't actually implement
two page-breaking strategies (in the end, not both right
now). For a speed-optimized algorithm, we could even think
about ignoring side-floats.
On Tue, Mar 01, 2005 at 03:02:38PM +0100, Jeremias Maerki wrote:
As for the plan to implement a new page-breaking mechanism: I've got to
do it now. :-) I'm sorry if this may put some pressure on some of you.
I'm also not sure if I'm fit already to tackle it, but I've got to
do it anyway. Since
On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
Jeremias Maerki wrote:
processing time and additional memory requirements. This
leads me to the question if we shouldn't actually implement
two page-breaking strategies (in the end, not both right
now). For a
On 01.03.2005 22:25:12 Simon Pepping wrote:
On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
Jeremias Maerki wrote:
processing time and additional memory requirements. This
leads me to the question if we shouldn't actually implement
two page-breaking strategies (in
13 matches
Mail list logo
