DO NOT REPLY [Bug 29124] - New line breaking algorithm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29124. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29124 New line breaking algorithm --- 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. I hope I did not forget anything this time! :-) Luca
DO NOT REPLY [Bug 29124] - New line breaking algorithm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29124. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29124 New line breaking algorithm --- Additional Comments From [EMAIL PROTECTED] 2004-08-12 08:25 --- Created an attachment (id=12400) patch file (fourth edition, including HyphContext and bug fixes)
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
