Re: Hyphetation broken with last commits
Manuel Mall wrote: Luca, why does our line breaking algorithm insist on having at least one Box in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it deal with empty paragraphs, that is paragraphs containing only Glue/Pen elements? If I remember correctly, a sequence starting with glue / penalty elements would not make the algorithm crash, but the produced ouput will take into account the width of the glues too, while it should not. This happens because there is not a previous break, whose handling would have the effect of ignoring glues and penalties between the break and the first next box. We could maybe move the leading space removal at the beginning of the breaking algorithm itself, which could then check if there are some elements left and create an empty line break if there is none. HTH, unfortunately these days I'm really really busy and I have not much time to look at this. Luca
Re: API stabilization
On Dec 16, 2005, at 08:13, Jeremias Maerki wrote: For the 0.90alpha1 release I've deprecated the Fop class' constructors with the integer parameter for renderer selection. Is it ok if I remove them before the beta release? Or does anybody still prefer the integers over the MIME type approach? No objection to removing the integer constructors here. I'm reasonably happy with the API now and don't see a big need to change anything right now. The only thing I still have on my TODO list is the split of some kind of environment or factory class (holding references to font configuration, caches, registered extensions etc.) from the FOUserAgent. Agreed, with some reservations. See recent post on fop-users: there seem to be users --well, at least one-- who require the use of multiple configurations. As long as the user-config doesn't become 'static' for all runs within the same session: +1. Cheers, Andreas
Re: Hyphetation broken with last commits
On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote: It is not a special situation at all. Simply having a nbsp; in your text is enough to trigger this regression. And yes, it is an regression caused by the fix for the disappearing empty line problem: fo:block#160;/fo:block After some debugging it is obvious to me what is happening. However, it is much less obvious how to fix it. In brief: The fix added a zero width Knuth box to the element list created for a nbsp. This was done for two reasons: a) to avoid it being removed by the removeElementsForTrailingSpaces() method. That method is wrong in the first place as it knowingly tries to remove non breaking spaces which IMO should never be removed. In Knuth's situation spaces were always suppressed at a linebreak. Therefore suppressing glues around a linebreak is built into the algorithm. For FO, we need glues that are not suppressed around a linebreak. Perhaps a boolean member 'suppress-at-line-break' of KnuthGlue? b) However, changing that method to not remove nbsp would give us Knuth paragraphs containing only Glue and Penalty elements. This then causes our implementation of the Knuth algorithm to 'spit the dummy'. Luca, why does our line breaking algorithm insist on having at least one Box in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it deal with empty paragraphs, that is paragraphs containing only Glue/Pen elements? The above proposed member would not solve this problem. The case is contradictory in itself, and quite unique. A nbsp will never occur at the end of a line by its very definition, except in this case! Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Hyphetation broken with last commits
On Dec 17, 2005, at 16:29, Manuel Mall wrote: Hi, On Sat, 17 Dec 2005 11:07 pm, Simon Pepping wrote: On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote: snip/ The case is contradictory in itself, and quite unique. A nbsp will never occur at the end of a line by its very definition, except in this case! Simon, I don't quite get it what you are trying to say. fo:block#160;/fo:block is perfectly legal and sensible in both XSL-FO (and HTML) and doesn't that mean a nbsp does occur at the end (and beginning) of a line. I guess what Simon is referring to is that if the line-breaking algorithm does its job adequately, there will be no line-break preceding/following a non-breaking-space, except when it is the first/ last character in a block. Other break-possibilities should, in theory at least, always be considered more favorable than breaking before/after the nbsp... Correct, Simon? What is contradictory or unique about this? That indeed is a bit overstating the case. It's not contradictory, but it is a rather special situation. Not taking into account the number of times such a construct is used in practice... It is more of an HTML/XSL-FO trick to make a block appear non-empty --used mainly in the context of table-cells, to have their borders drawn despite the fact that there is no visible content. Cheers, Andreas
Re: Hyphetation broken with last commits
On Sat, Dec 17, 2005 at 05:46:42PM +0100, Andreas L Delmelle wrote: On Dec 17, 2005, at 16:29, Manuel Mall wrote: Hi, On Sat, 17 Dec 2005 11:07 pm, Simon Pepping wrote: On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote: snip/ The case is contradictory in itself, and quite unique. A nbsp will never occur at the end of a line by its very definition, except in this case! Simon, I don't quite get it what you are trying to say. fo:block#160;/fo:block is perfectly legal and sensible in both XSL-FO (and HTML) and doesn't that mean a nbsp does occur at the end (and beginning) of a line. I guess what Simon is referring to is that if the line-breaking algorithm does its job adequately, there will be no line-break preceding/following a non-breaking-space, except when it is the first/ last character in a block. Other break-possibilities should, in theory at least, always be considered more favorable than breaking before/after the nbsp... Correct, Simon? That is precisely what I tried to say. What is contradictory or unique about this? That indeed is a bit overstating the case. It's not contradictory, but it is a rather special situation. Not taking into account the number of times such a construct is used in practice... It is more of an HTML/XSL-FO trick to make a block appear non-empty --used mainly in the context of table-cells, to have their borders drawn despite the fact that there is no visible content. It is not a formal contradiction, but it feels like one: nbsp should not have a linebreak around it, but here we have to solve the problem how to deal with it when it does have a linebreak preceding or following it. Simon -- Simon Pepping home page: http://www.leverkruid.nl
