Re: keep...="always" and Knuth penalties

[Jeremias Maerki <de...@jeremias-maerki.ch>]

I've just written to the XSL SG. Hopefully, the question gets answered
this time.

On 22.06.2006 10:40:36 Peter B. West wrote:
> On Wed, 2006-06-21 at 16:50 +0200, Jeremias Maerki wrote:
> > > 
> > > Have you tried the Disposition of Comments? I don't know how accessible
> > > they are to Google.
> > 
> > They are accessible through the list archive at W3C. I've looked at
> > those I found but I found no listing of all XSL-related ones.
> 
> Jeremias,
> 
> I'm not sure that they are accessible. The only way I've ever been able
> to find them is by following links from messages in the xsl-editors
> list.
> 
> It's not a big deal for me; I'll go with always=always.
> 
> If you need it resolved, you might be best to write to the editors. Paul
> Grosso will probably respond quickly.
> 
> Peter



Jeremias Maerki

Re: keep...="always" and Knuth penalties

[Manuel Mall <ma...@apache.org>]

On Thursday 13 July 2006 22:09, Jeremias Maerki wrote:
> What I tried to propose is mostly just that. Implementing some
> shortcut that at least treats all integer values differently from
> "always" with a constant penalty value. That gives FOP the
> opportunity to relax while still allowing the rather intuitive
> "always" not to relax thus providing both kinds of behaviours.
> Relaxing "always" might not be that intuitive/expected for some
> people. Introducing a configuration option makes the whole thing just
> more difficult. This way you can just tell the user to use some
> integer instead of always if he wants the keeps to be relaxable.
>
> Treating integer values differently from "always" is the half way to
> the full implementation but still can be implemented with reasonable
> effort without compromising any future improvements.
>

I agree with Jeremias here. This seems a sensible way forward.

If down the track we have users screaming for "always" to be made 
more 'relaxed' the issue of making this configurable can be revisited.

Manuel
> The only problem I see here is that DocBook may not allow that kind
> of control over the keep values. For everyone else, that's just a
> quick search and replace in the stylesheet.
>
> On 13.07.2006 15:13:59 Chris Bowditch wrote:
> > Jeremias Maerki wrote:
> > > Fabio Gianetti made a good comment [1]. I answered like this [2].
> > > I'm currently thinking about how best to implement this. To keep
> > > it simple for the moment, we could implement "always" like before
> > > but remove/disable the overflow recovery I've implemented. That
> > > way, the content would again overflow. All integer values could
> > > be implemented as penalty=999 for the moment (thus allow some
> > > relaxing), at least until we have a good scheme about mapping
> > > integer keeps to penalty values like we started to discuss some
> > > time ago. However, this would disable the possibility to shove an
> > > element ahead n pages in the hope that there will be a page that
> > > the element fits on (the purpose of the overflow recovery). But
> > > that will be a very rare thing anyway, so I don't think there's
> > > any harm. Any objections?
> >
> > Well until integer values for keeps are implemented I object to
> > implementing always such that it generates overflow on a page. The
> > ability to error or clip gives little comfort to users either.
> >
> > Personally I prefer the Renderer to relax the
> > keep-together="always" if required. Fabio seems to suggest in his
> > post that it is implementation dependent what happens in this
> > situation. Maybe we could have a configuration option?
> >
> > <snip/>
> >
> > Chris
>
> Jeremias Maerki

Re: keep...="always" and Knuth penalties

[Jeremias Maerki <de...@jeremias-maerki.ch>]

What I tried to propose is mostly just that. Implementing some shortcut
that at least treats all integer values differently from "always" with a
constant penalty value. That gives FOP the opportunity to relax while
still allowing the rather intuitive "always" not to relax thus providing
both kinds of behaviours. Relaxing "always" might not be that
intuitive/expected for some people. Introducing a configuration option
makes the whole thing just more difficult. This way you can just tell
the user to use some integer instead of always if he wants the keeps to
be relaxable.

Treating integer values differently from "always" is the half way to the
full implementation but still can be implemented with reasonable effort
without compromising any future improvements.

The only problem I see here is that DocBook may not allow that kind of
control over the keep values. For everyone else, that's just a quick
search and replace in the stylesheet.

On 13.07.2006 15:13:59 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> > Fabio Gianetti made a good comment [1]. I answered like this [2]. I'm
> > currently thinking about how best to implement this. To keep it simple
> > for the moment, we could implement "always" like before but
> > remove/disable the overflow recovery I've implemented. That way, the
> > content would again overflow. All integer values could be implemented as
> > penalty=999 for the moment (thus allow some relaxing), at least until we
> > have a good scheme about mapping integer keeps to penalty values like we
> > started to discuss some time ago. However, this would disable the
> > possibility to shove an element ahead n pages in the hope that there
> > will be a page that the element fits on (the purpose of the overflow
> > recovery). But that will be a very rare thing anyway, so I don't think
> > there's any harm. Any objections?
> 
> Well until integer values for keeps are implemented I object to 
> implementing always such that it generates overflow on a page. The 
> ability to error or clip gives little comfort to users either.
>
> Personally I prefer the Renderer to relax the keep-together="always" if 
> required. Fabio seems to suggest in his post that it is implementation 
> dependent what happens in this situation. Maybe we could have a 
> configuration option?
> 
> <snip/>
> 
> Chris



Jeremias Maerki

Re: keep...="always" and Knuth penalties

[Chris Bowditch <bo...@hotmail.com>]

Jeremias Maerki wrote:

> Fabio Gianetti made a good comment [1]. I answered like this [2]. I'm
> currently thinking about how best to implement this. To keep it simple
> for the moment, we could implement "always" like before but
> remove/disable the overflow recovery I've implemented. That way, the
> content would again overflow. All integer values could be implemented as
> penalty=999 for the moment (thus allow some relaxing), at least until we
> have a good scheme about mapping integer keeps to penalty values like we
> started to discuss some time ago. However, this would disable the
> possibility to shove an element ahead n pages in the hope that there
> will be a page that the element fits on (the purpose of the overflow
> recovery). But that will be a very rare thing anyway, so I don't think
> there's any harm. Any objections?

Well until integer values for keeps are implemented I object to 
implementing always such that it generates overflow on a page. The 
ability to error or clip gives little comfort to users either.

Personally I prefer the Renderer to relax the keep-together="always" if 
required. Fabio seems to suggest in his post that it is implementation 
dependent what happens in this situation. Maybe we could have a 
configuration option?

<snip/>

Chris

Re: keep...="always" and Knuth penalties

["Peter B. West" <pe...@hp.com>]

[2] makes sense to me. I would make the same argument regarding
'overflow'.

Peter

On Thu, 2006-07-13 at 14:19 +0200, Jeremias Maerki wrote:
> Fabio Gianetti made a good comment [1]. I answered like this [2].
...
> 
> [1] http://lists.w3.org/Archives/Public/xsl-editors/2006JulSep/0001.html
> [2] http://lists.w3.org/Archives/Public/xsl-editors/2006JulSep/0003.html
> 

Re: keep...="always" and Knuth penalties

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Fabio Gianetti made a good comment [1]. I answered like this [2]. I'm
currently thinking about how best to implement this. To keep it simple
for the moment, we could implement "always" like before but
remove/disable the overflow recovery I've implemented. That way, the
content would again overflow. All integer values could be implemented as
penalty=999 for the moment (thus allow some relaxing), at least until we
have a good scheme about mapping integer keeps to penalty values like we
started to discuss some time ago. However, this would disable the
possibility to shove an element ahead n pages in the hope that there
will be a page that the element fits on (the purpose of the overflow
recovery). But that will be a very rare thing anyway, so I don't think
there's any harm. Any objections?

[1] http://lists.w3.org/Archives/Public/xsl-editors/2006JulSep/0001.html
[2] http://lists.w3.org/Archives/Public/xsl-editors/2006JulSep/0003.html

On 10.07.2006 14:21:35 Jeremias Maerki wrote:
> I've just written to the XSL SG. Hopefully, the question gets answered
> this time.
> 
> On 22.06.2006 10:40:36 Peter B. West wrote:
> > On Wed, 2006-06-21 at 16:50 +0200, Jeremias Maerki wrote:
> > > > 
> > > > Have you tried the Disposition of Comments? I don't know how accessible
> > > > they are to Google.
> > > 
> > > They are accessible through the list archive at W3C. I've looked at
> > > those I found but I found no listing of all XSL-related ones.
> > 
> > Jeremias,
> > 
> > I'm not sure that they are accessible. The only way I've ever been able
> > to find them is by following links from messages in the xsl-editors
> > list.
> > 
> > It's not a big deal for me; I'll go with always=always.
> > 
> > If you need it resolved, you might be best to write to the editors. Paul
> > Grosso will probably respond quickly.
> > 
> > Peter


Jeremias Maerki