Re: [Bug 29124] - New line breaking algorithm

2004-09-01 Thread Simon Pepping
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

2004-08-28 Thread Simon Pepping
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

2004-08-13 Thread Finn Bock
[Luca Furini]
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?
Take a look at the way WORD_SPACING is assigned now in PropertyManager. 
I assume some other MinOptMax value should be used when the enum value 
is NORMAL but I don't know exactly where the value should come from.

Anyway, I hope this is a step in the right direction.
regards,
finn


Re: [Bug 29124] - New line breaking algorithm

2004-08-12 Thread Luca Furini

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

2004-08-12 Thread Simon Pepping
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

2004-08-12 Thread Simon Pepping
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

2004-08-12 Thread Finn Bock
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

2004-08-10 Thread Simon Pepping
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