Re: [Bug 29124] - New line breaking algorithm
On Wed, Sep 01, 2004 at 10:40:16AM +0100, Chris Bowditch wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-08-31 18:44 --- FOP team, If I would apply this patch, we would get the following regressions: - When for an exceptionally difficult paragraph no set of breaking points can be found, the whole paragraph is printed on a single line. This occurs, for example, when in a narrow typesetting width only a single word or a part of it fits in a line. I would think that strange effects like this are possible today. Can you see what the output would look like in such a scenario with the current code? The current code breaks the paragraphs into lines. It makes short lines. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 29124] - New line breaking algorithm
On Sat, Aug 28, 2004 at 10:06:49AM -, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-08-28 10:06 --- Sorry again, I didn't notice that cvs error. I think it can be noticed easily in a shell that separates stdout from stderr. Otherwise it is hard to see in the output stream. I'm going to attach the right (?) patch :-) (for some strange reasons wincvs' diff shows Simon's latest changes too, I hope this is not a problem ...) For some reason the diff is made against the older revisions: retrieving revision 1.11 diff -w -u -r1.11 ContentLayoutManager.java --- layoutmgr/ContentLayoutManager.java 13 Jul 2004 00:16:22 - 1.11 +++ layoutmgr/ContentLayoutManager.java 28 Aug 2004 09:55:24 - The current revision is 1.12, dated 26 Aug. I failed to apply this patch. When I apply it to the older version of the code, I get inconsistent code. When I apply it to the newer version, I get errors by the patch program. Can you try to generate a new patch? Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 29124] - New line breaking algorithm
Simon Pepping wrote: - word spacing and letter spacing are now fully implemented, they can both have MinOptMax values; but I am still thinking about how to differentiate a user-defined zero value from a default zero value ... You cannot. A default value is a user-defined value supplied by the system to save the user the trouble of always having to enter a value. It is just a convenience, and you cannot attach a different meaning to it. You are right: default values must be respected no less than expressed values, I asked the wrong question. The point is that the XSL recommendation states that the default word-spacing value is normal, meaning The normal inter-word space, as defined by the current font and/or the UserAgent, not zero. At the moment, the SpaceVal variable in the TextInfo object used by the TLM has .getSpace().min == .getSpace().max == 0 even if the word-spacing property was not set in the fo document. So, the right question is: how can the TLM see if the word-spacing property value is normal? - text-align-last is partially implemented; text-align-last = justify works only if text-align = justify too; this is because Knuth's algorithm doesn't provide for a different alignment for the last line. TeX uses glue to achieve this, \parfillskip. It is the special amount of glue appended to the last line. In the TeXbook, p. 99, Knuth describes it as 'the special trick that allows the final line of a paragraph to be shorter than the others'. Setting \parfillskip to 0 removes this ability. Usually \parfillskip has infinite stretchability. I fear this trick works only with justified text. Knuth's book suggests a way to implement right/left and center alignment which is not just justify text and then ignore the computed adjustment: this different strategy involves using special sequences of elements representing spaces. For example, with left (or right) aligned text each space generates the sequence: glue(width 0, stretch X, shrink 0) penalty(value 0) glue(width word-space-width, stretch -X, shrink 0) If the line is not broken after the first glue element, the overall sretch of these elements is 0: so, the total available stretch of each line is always X, regardless of the number of spaces, while with the justified-text strategy the more spaces are in a line, the more stretch that line will have. The computed adjustment ratio refers to this constant value, and it is completely useless if we want to justify the last line. We could use the computed difference to calculate the space adjustment, but we don't know how many spaces there are in the line. Setting \parfillskip to 0 does not avail, as it just forces the algorithm to find lines all with the same width. Maybe, with text-align = left, right or center and text-align-last = justify we should use the justified-text strategy with stretchable and unshrinkable spaces. Regards, Luca
Re: [Bug 29124] - New line breaking algorithm
On Thu, Aug 12, 2004 at 08:23:14AM -, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-08-12 08:23 --- I'm going to attach an updated patch, including HyphContext (which I forgot to include in the previous versions, sorry) and a few changes to fix a couple of bugs. I used linux's diff between the modified files and the original ones (updated yesterday, 11 August); for some reasons (maybe I use some wrong options) wincvs's diff did not include new files and did not use the latest version of the original files, so finding lots of difference due to recent cvs commits. Perhaps you cannot include new files, because as an anonymous CVS user you cannot add files (cvs add). Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 29124] - New line breaking algorithm
On Thu, Aug 12, 2004 at 12:27:38PM +0200, Luca Furini wrote: The point is that the XSL recommendation states that the default word-spacing value is normal, meaning The normal inter-word space, as defined by the current font and/or the UserAgent, not zero. At the moment, the SpaceVal variable in the TextInfo object used by the TLM has .getSpace().min == .getSpace().max == 0 even if the word-spacing property was not set in the fo document. So, the right question is: how can the TLM see if the word-spacing property value is normal? TextInfo derives that value from the value of the word-spacing property. That must be an error in the property handling by FOP. In FOPropertyMapping 0pt is used as the default value. Apparently normal should be the default value. I am not sure how this can be done for a space property. Something similar happens for length properties, which can have the default value auto. I think normal should be a keyword. Apparently, the actual value can only be calculated at layout time, when the font is known. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 29124] - New line breaking algorithm
Simon Pepping wrote:
TextInfo derives that value from the value of the word-spacing
property.
That must be an error in the property handling by FOP.
Yes. I'll commit a fix for it tomorrow.
In
FOPropertyMapping 0pt is used as the default value. Apparently
normal should be the default value. I am not sure how this can be
done for a space property. Something similar happens for length
properties, which can have the default value auto. I think normal
should be a keyword.
Keywords are for mapping one value into another value before the values
are parsed. In this case 'normal' should be implemented as an enum.
Apparently, the actual value can only be
calculated at layout time, when the font is known.
Yes, so the consumers of the 'word-spacing' value must must check if the
value as an enum == NORMAL before using the value as a Space:
Property wordSpacing = propertyList.get(PR_WORD_SPACING);
if (wordSpacing.getEnum() == NORMAL) {
textInfo.wordSpacing = new SpaceVal(
new MinOptMax(min, opt, max), true, true, 0);
} else {
textInfo.wordSpacing = new SpaceVal(wordSpacing.getSpace());
}
regards,
finn
Re: [Bug 29124] - New line breaking algorithm
On Tue, Aug 03, 2004 at 12:41:52PM -, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-08-03 12:41 --- These are the new methods added; at the moment, I added them to the LayoutManager interface, but maybe it could be better to create a new interface implementd only by LM returning inline areas. I think it is, but that can come later. - word spacing and letter spacing are now fully implemented, they can both have MinOptMax values; but I am still thinking about how to differentiate a user-defined zero value from a default zero value ... You cannot. A default value is a user-defined value supplied by the system to save the user the trouble of always having to enter a value. It is just a convenience, and you cannot attach a different meaning to it. - text-align-last is partially implemented; text-align-last = justify works only if text-align = justify too; this is because Knuth's algorithm doesn't provide for a different alignment for the last line. TeX uses glue to achieve this, \parfillskip. It is the special amount of glue appended to the last line. In the TeXbook, p. 99, Knuth describes it as 'the special trick that allows the final line of a paragraph to be shorter than the others'. Setting \parfillskip to 0 removes this ability. Usually \parfillskip has infinite stretchability. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
