DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation

2004-04-09 Thread bugzilla
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=27773.
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=27773

[PATCH] Hyphenation





--- Additional Comments From [EMAIL PROTECTED]  2004-04-09 09:28 ---
Hi Luca,

Your patch looks good. It works fine on your test fo, and it also
works fine on a test fo I had lying around.

There are a few things to note:

AreaInfo.bHyphenated is identical to (flags  BreakPoss.HYPHENATED);
ai.ipdArea = MinOptMax.add(ai.ipdArea, new MinOptMax(hyphIPD)) is
equivalent to bp.setStackingSize(MinOptMax.add(ipd, new
MinOptMax(hyphIPD))). In other words, the same information is present
in the BreakPoss, which is held by the LineLM. Unfortunately, this
information is not accessible in the addAreas method of TextLM. This
is so because posIter.next() returns the position member of the
BreakPoss, not the BreakPoss itself. I believe that is an error in
PositionIterator which eventually needs correction. For now your
solution is a good one.

Your proposed TextInfo.hypChar is also known as
LineLM.hyphProps.hyphenationChar. This information is not passed on to
childLMs and thus not known to TextLM. Storing it in TextInfo seems a
good idea; perhaps it is not even needed in hyphProps.

It is not completely clear that 

+if (ai.bHyphenated) {
+str += foText.textInfo.hyphChar;
+ai.ipdArea = MinOptMax.add(ai.ipdArea, new MinOptMax(hyphIPD));
+}

is always correct. This happens on the last AI returned by
posIter.next(), which is not necessarily the last one in the line. But
it is hard to conceive of an AI which is last in its LM and also
hyphenated; therefore it will work. Ideally, the LineLM indicates
which BP is the one ending the line; perhaps this needs correction at
some time.

Regards, Simon


DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java

2004-04-09 Thread bugzilla
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=28237.
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=28237

[PATCH] Use the commons logging LogFactory also in Fop.java





--- Additional Comments From [EMAIL PROTECTED]  2004-04-09 10:09 ---
Glen,

 (a) why place within isDebugEnabled() and isWarnEnabled()
 conditionals, why does this matter?

To be as reticent as possible. If a user uses -d but his configuration
also sets the log level to debug, he already has what he wants; skip
the command line option silently. Similarly with -q.
 
 (b) one conditional is !isDebugEnabled() with a negative but the other
 is the positive isWarnEnabled()--was this a bug?

-d and !isDebugEnabled() means that the user does not yet have debug
log level but requests it, so we have to do something. -q and
isWarnEnabled() means that the user still has warning level or a more
verbose level on but requests quiet mode (error level), so we have to
do something.
 
 (c) Finally, did you actually mean isErrorEnabled() for the latter?

No, isErrorEnabled() means error level enabled and perhaps more
verbose. We need to ensure that we are not more verbose than error
level, that is, !isWarnEnabled().

For the dumpConfiguration method of CommandLineOptions, if the user
requests -x but does not set debug log level, he sees no configuration
dump. That does not serve the user well. My patch checked that and
used a debug enabled SimpleLog in that case. Alternatively, it might
be a good idea to show the configuration at info log level; after all,
this is information that the user explicitly requested.

Regards, Simon


DO NOT REPLY [Bug 28314] New: - Alignment of the last line in a justified block

2004-04-09 Thread bugzilla
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=28314.
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=28314

Alignment of the last line in a justified block

   Summary: Alignment of the last line in a justified block
   Product: Fop
   Version: 1.0dev
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: page-master/layout
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have tried to solve the problem of the last line in a justified block, which 
sometimes is justified too, instead of being left-aligned.

This problem arises when the fo:block ends with spaces (the last TextLM's text 
ends with spaces), or with a LF followed by spaces (the last TLM's text 
contains only spaces), while if the block ends with a non-whitespace character 
it is handled right; the test fo file I'm going to attach shows these 
different situations.

So, a possible solution could be avoiding these problematic situations to 
happen: as the end of a block always implies a line break (or not?) the ending 
spaces can be removed.
This is what the proposed patch I'm going to attach does, slightly modifying 
the Block.handleWhiteSpace() method:
- define another RecursiveCharIterator, called spaceIter, initialized null
- inside the while loop, it is updated (if it's null) cloning charIter before 
nextChar() is called, and set to null again if the current character is not a 
space; so, if it is not null it points to the first element in a sequence of 
spaces
- once the loop ends, if spaceIter is not null it is used to remove thr spaces 
at the end of the block
Without any other code change, this seem to solve the problem.


An alternative approach: why doesn't the LineLM change text alignment for the 
last line?
Alignment is changed
  if (bTextAlignment == TextAlign.JUSTIFY
   (prevBP.isForcedBreak() || isFinished())) {
and in the problematic cases isFinished() returns false, so text alignment 
is not changed.

This is what happens during the LineLayoutManager.getNextBreakPoss():

   BreakPoss a || BreakPoss b
   vv
  | end of text. |

- inside the while loop, bp = curLM.getNextBreakPoss() returns the break 
possibility a, which could be used to end the line, and is saved in prevBP
- at the next iteration inside the while loop, bp = curLM.getNextBreakPoss() 
returns the break possibility b, which is not good (bBreakOK == false)
- the TLM has finished, so at the next iteration getChildLM() returns null, 
and the while loop ends
- the LLM calls setFinished(), because there are no more child LM
- now prevBP=a, bp=b, so prevBP != bp
- oddly, prevCouldEndLine(prevBP) is false
- so the reset() function is called, which calls AbstractLayoutManager.reset
(Position), which has these lines:
if (isFinished()) {
setFinished(false);
}

(in the other problematic situation it's a different TLM which returns b, 
but the LLM behaviour is quite the same)

It seems to me that the value returned by prevCouldEndLine(prevBP) is wrong, 
but I didn't investigate any further as I was quite satisfied with the result 
obtained in the other way.

Luca


DO NOT REPLY [Bug 28314] - Alignment of the last line in a justified block

2004-04-09 Thread bugzilla
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=28314.
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=28314

Alignment of the last line in a justified block





--- Additional Comments From [EMAIL PROTECTED]  2004-04-09 15:08 ---
Created an attachment (id=11199)
test fo file


DO NOT REPLY [Bug 28314] - Alignment of the last line in a justified block

2004-04-09 Thread bugzilla
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=28314.
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=28314

Alignment of the last line in a justified block





--- Additional Comments From [EMAIL PROTECTED]  2004-04-09 15:08 ---
Created an attachment (id=11200)
proposed patch