DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-29 09:09 ---
Applied the patch in a rewritten form.

Re: Justification and line breaking

[Simon Pepping]

On Tue, May 25, 2004 at 09:56:25AM +0100, Chris Bowditch wrote:
> Luca Furini wrote:
> 
> >You are completely right; by the way, what other child LMs could the LLM
> >have?
> 
> I'm just guessing, but I think anything that can appear inline, i.e. 
> hyperlinks, leaders, etc. Block level stuff like Tables and graphics can 
> not be children of the LLM.

I agree, all LMs for which generatesInlineAreas() returns true. That
is more or less the definition of LineLM, see its constructor. Note
that you also have to deal with descendants below children,
e.g. childLMs in an inlineLM. Other LMs may hide their content and
return a block to LineLM. For example, fo:inline-container (I guess
ICLayoutManager) may contain blocks, but hides them in a single block
from the LineLM (I am guessing a bit; have never dived so deep into
the details of these FOs; I compare them to TeX's vbox construct.)

I will see if I can get some more info on the possible descendants of
a LineLM.
 
> >I thank all that spent some time looking at it and testing it, and I
> >apologize if I have not been able to clearly explain what my aim was.
> 
> No need to apologize or thanks us, your efforts are most appreciated.

I agree.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Justification and line breaking

[Simon Pepping]

On Tue, May 25, 2004 at 09:51:28AM +0100, Chris Bowditch wrote:
> Luca Furini wrote:
> 
> >JThe method startParagraphs dereferences only knuthParagraphs and
> >textIndent, so maybe there is a missing line concerning their 
> >initialization.
> 
> I have proved that textIndent is definitely null when it is not specified 
> on the block.
> >  ...
> >  bTextAlignmentLast = blockProps.textAlignLast;
> >  textIndent = blockProps.firstIndent; /* here it is */
> >  hyphProps = propMgr.getHyphenationProps();
> >  ...

LineLayoutManager:
protected void initProperties(PropertyManager propMgr) {
BlockProps blockProps = propMgr.getBlockProps();
textIndent = blockProps.firstIndent;
}

blockProps is initialized in the constructor of LineLM.

PropertyManager:
public BlockProps getBlockProps() {
BlockProps props = new BlockProps();
props.firstIndent = this.propertyList.get(PR_TEXT_INDENT).getLength();
return props;
}

If this.propertyList is not null, then get(PR_TEXT_INDENT) always
returns a value; if it is not specified by the user, the default value
is returned. This is true for all properties.

LengthProperty:
public Length getLength() {
return this;
}

Property:
public Length getLength() {
return null;
}

getLength(), however, may return a null value. It only returns a
non-null value if the property returned by get(PR_TEXT_INDENT) is a
LengthProperty. This should be true; I do not know a reason why it is
not true in your code.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Convenience branches. Was: Justification and line breaking

[Peter B. West]

Chris Bowditch wrote:
Peter B. West wrote:

Simon, yes!  That's what branching is there for.  People seem to be 
afraid of it, but it is an enormously useful tool for just such 
situations.  I think it's always a good idea to tag the tree 
immediately before a branch.

Hi Peter,
its not that I am afraid of branches, they have their uses, but I feel 
the project is at the wrong stage in its development for another branch 
right now. Branches invariably mean splitting development focus. Right 
now I want to focus on fixing the High priority issues with layout so we 
can do a release. If we flail around for another year or so then FOP may 
be dead in the water as other projects overtake it.
Let's sketch a procedure for things like this.  Someone proposes such a 
large patch again.  We look at and realize that it can have a 
significant impact, but is worthwhile considering.  The time frame for 
sorting it out might be anything from a week to a month or two.

Tag the tree.  Let's call it paragraph_patch.  Tell the person proposing 
the patch - let's say Luca for illustration - to build his patch again 
based on the paragraph_patch.  Luca checks out the tree using that tag. 
 When he has it in a state to be examined, he submits the patch, noting 
that his work is based on paragraph_patch.  Those interested in testing 
the patch create a branch, say paragraph_test, at the tag-point, 
paragraph_patch, checkout paragraph_test, and apply the patch.  Is there 
any problem in applying the patch?  No, because everyone is working with 
known and common versions of the files.  Is there any impact on ongoing 
commits to HEAD?  No.  The committers (and Luca) still have valid HEAD 
trees on their machines, still track and contribute to the ongoing HEAD 
development.

Let's say that Andreas commits some changes which affect Luca's work. 
Luca wants to merge them in.  He asks for a merge.  Impact on HEAD?  Ask 
Andreas if his changes have settled down.  Announce that the tree will 
be tagged at time X.  Tag the tree; paragraph_merge_pt_1.  That's it.

Meanwhile, Luca requests that the paragraph_test tree be tagged 
(before_merge_pt_1).   Disruption to HEAD - none.  He locally merges 
from paragraph_merge_pt_1 into paragraph_test, and starts to sort out 
the conflicts.  When he is done, he prepares a new patch against 
paragraph_test, which he submits.

Committers who are tracking his work apply the patch to their copies of 
the paragraph_test tree.  Disruption to HEAD - none.  Patch errors - 
none.  When the patch is ready to be applied to HEAD, the process of 
merging in from HEAD is repeated, relative to the last merge tag in 
HEAD.  Committers announce that a merge into HEAD is pending, ask that 
commits to HEAD be suspended until this is done, and tag the HEAD tree; 
before_paragraph_merge.  Luca merges locally into HEAD, and prepares a 
patch against HEAD, which he submits.  This is committed and the HEAD 
tree tagged after_paragraph_merge.  The paragraph_test branch is now 
defunct.

Note that this description covers the whole development cycle of a 
major, potentially disruptive patch, through to integration into HEAD.

Compare that to the dramas we have just been through (and are still 
going through - there seem to be two versions of HEAD out there on two 
committers' machines.)  The responsibility for developing the patch 
rests primarily on the author and secondarily on the committers who 
perform testing and feedback.  Had a procedure like this been in place, 
would the progress of Luca's patch have been more, less or equally 
disruptive?

Obviously such a procedure is only *necessary* in unusual cases, but it 
makes sense to know how it is done, and it even makes sense to practise 
doing it on short cycle changes, so that things flow smoothly when the 
big issues come along.

Just a suggestion.
Peter
--
Peter B. West 

Re: Justification and line breaking

[Chris Bowditch]

Luca Furini wrote:
You are completely right; by the way, what other child LMs could the LLM
have?
I'm just guessing, but I think anything that can appear inline, i.e. 
hyperlinks, leaders, etc. Block level stuff like Tables and graphics can not 
be children of the LLM.

I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?

Completely: I submitted the patch to get a first feedback, comments,
suggestions ...
I thank all that spent some time looking at it and testing it, and I
apologize if I have not been able to clearly explain what my aim was.
No need to apologize or thanks us, your efforts are most appreciated.
I'll work on this patch for some more time, and I'll let you know of the
progress.
Thank you, please let us know if you need any assistance or further feedback,
Chris

Re: Justification and line breaking

[Chris Bowditch]

Luca Furini wrote:
JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their initialization.
I have proved that textIndent is definitely null when it is not specified on 
the block.


While textIndent is initialized in the TLM constructor (but this was already
in the code, it's not a change of mine):
I assume you mean the LLM constructor?
  ...
  bTextAlignmentLast = blockProps.textAlignLast;
  textIndent = blockProps.firstIndent; /* here it is */
  hyphProps = propMgr.getHyphenationProps();
  ...
and if blockProps.firstIndent returns null? Which it appears to be if the user 
doesnt specify on a block.

I hope this can help you; thanks for testing my patch.
After adding an IF test around the code that uses textIndent to avoid NPE, I 
then get the following error:

25-May-2004 09:11:43 org.apache.fop.layoutmgr.LineLayoutManager getNextBreakPoss
WARNING: No set of breaking points found with maxAdjustment = 1.0
Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:385)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
at org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss(FlowLayou
tManager.java:81)
Thanks,
Chris

Re: Justification and line breaking

[Chris Bowditch]

Peter B. West wrote:

Simon, yes!  That's what branching is there for.  People seem to be 
afraid of it, but it is an enormously useful tool for just such 
situations.  I think it's always a good idea to tag the tree immediately 
before a branch.
Hi Peter,
its not that I am afraid of branches, they have their uses, but I feel the 
project is at the wrong stage in its development for another branch right now. 
Branches invariably mean splitting development focus. Right now I want to 
focus on fixing the High priority issues with layout so we can do a release. 
If we flail around for another year or so then FOP may be dead in the water as 
other projects overtake it.

Chris

Re: Justification and line breaking

[Luca Furini]

Simon Pepping wrote:

> I changed the constructor call as well. I changed the logger calls
> from getLogger() to log. log is a member of
> AbstractLayoutManager. These are changes applied by Glen, and
> apparently Luca made his diff before they were applied.

Yes; more exactly, I forgot to apply these changes to the code I was
already working on.
To avoid this kind of problems, I will try to keep my code updated.

> I am not surprised that your complex document did not run well. If I
> understand the situation well, then the patch works for LineLM with
> TextLM childLMs. It does not work with any other childLM. I expect the
> other childLMs to use the null implementation of getNextKnuthElement()
> and therefore to contribute no areas.

You are completely right; by the way, what other child LMs could the LLM
have?

> I do not believe that the patch is mature for committing to the trunk
> code. See above. Luca, do you share my view?

Completely: I submitted the patch to get a first feedback, comments,
suggestions ...

I thank all that spent some time looking at it and testing it, and I
apologize if I have not been able to clearly explain what my aim was.

I'll work on this patch for some more time, and I'll let you know of the
progress.

Regards
Luca

Re: Justification and line breaking

[Luca Furini]

Chris Bowditch wrote:

> Here is the stack trace, which is the same for both documents:
> [...]
>
> Any thoughts would be appreciated.

JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their initialization.

KnuthParagraphs (the ArrayList whose item are the different
linefeed-separated paragraphs) is initialized just before calling
startParagraph:

  ...
  // it's the first time this method is called
  knuthParagraphs = new ArrayList(); /* here it is */
  breakpoints = new ArrayList();

  // convert all the text in a sequence of paragraphs made
  // of KnuthBox, KnuthGlue and KnuthPenalty objects
  Paragraph knuthPar = new Paragraph();
  knuthPar.startParagraph();
  ...

While textIndent is initialized in the TLM constructor (but this was already
in the code, it's not a change of mine):

  ...
  bTextAlignmentLast = blockProps.textAlignLast;
  textIndent = blockProps.firstIndent; /* here it is */
  hyphProps = propMgr.getHyphenationProps();
  ...

I hope this can help you; thanks for testing my patch.

Regards
Luca

Re: Justification and line breaking

[Chris Bowditch]

Simon Pepping wrote:

No exceptions. I ran Luca's test fo files successfully.
Strange how you and I always get such different results. It doesnt run with 
any file despite changing the language to "en". I always get NPE on LLM:249. 
Looking at the code it would appear to be a mistake as NPE will occur if 
text-indent is not specified on any block. I tried placing a IF statement 
around this line, but got a NPE elsewhere.

I dont understand how you can run Luca's files. The NPE seem to be limited to 
LLM and TLM, which I copied complete from Luca's patch. Did you manage to 
apply the patch file with LLM/TLM, or did you copy the complete files? There 
must be some differences in our code, or am I going mad?!?


I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?
I have to agree that the patch is far from ready. I in no way mean to cast a 
bad light on Luca's work. Luca must be congratulated for his efforts thus far, 
but we cannot accept a patch that will take the redesign effort backwards. 
With more testing and the bugs fixed, this patch will take the redesign 
forwards with a much cleaner approach to line breaking. I hope Luca will be 
happy to work on his patch some more locally.

If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.
I have to agree with Glen on this point, -1 for creating another branch. I 
have replied in more detail in another posting.

Chris

Re: Justification and line breaking

[Peter B. West]

Glen Mazza wrote:
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
Errr--I wouldn't want additional branches in CVS just
for the sake of a patch--they tend to become
permanent.  Luca working on his local machine, or
using something on SourceForge may be a better idea. 
It's just Monday right now--we can wait a few more
days.
Glen, branches are only as permanent as you make them.  They're a tool, 
and with the CVS-aware IDEs out there, they are increasingly easy to 
use.  (Until we're Subverted, anyway.  Not a comment on the product 
itself, just the expected level of third-party support.)

Peter
--
Peter B. West 

Re: Justification and line breaking

[Peter B. West]

Simon Pepping wrote:
...
I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?
If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.
Simon, yes!  That's what branching is there for.  People seem to be 
afraid of it, but it is an enormously useful tool for just such 
situations.  I think it's always a good idea to tag the tree immediately 
before a branch.

Peter
--
Peter B. West 

Re: Justification and line breaking

[Glen Mazza]

--- Simon Pepping <[EMAIL PROTECTED]> wrote:
Chris wrote:
>  
> > Is anyone else on the team planning on making
> large commits over the next 
> > couple of days? I would be grateful if you could
> hold off for a couple of 
> > days whilst the problems with this large patch are
> resolved. I dont want to 
> > have to re-apply the changes. Let me know if this
> causes any problems
> 

OK--I'll hold off myself.  But from my experience
working with Finn's several huge patches, applying
these things incrementally can work wonders.

> If I see it right, then Luca should work on his
> patch some
> more. 

Sounds like it, from Chris' explanation.

> Perhaps others could help with that work if he
> would want
> that. In such a situation it may be a good strategy
> to commit the
> patch to a branch of the HEAD of the trunk, so that
> it can be
> developed without problems with other work.
> 

Errr--I wouldn't want additional branches in CVS just
for the sake of a patch--they tend to become
permanent.  Luca working on his local machine, or
using something on SourceForge may be a better idea. 
It's just Monday right now--we can wait a few more
days.

Glen

Re: Justification and line breaking

[Simon Pepping]

Chris,

On Mon, May 24, 2004 at 01:57:34PM +0100, Chris Bowditch wrote:
> Hi Luca,
> 
> I have managed to apply your patch. Testing has not gone well. Firstly, I 
> had trouble compiling, due to BLM using the old constructor for LLM with 
> FObj as the first argument. This is easily corrected, but I would have 
> expected a change to BLM in your patch file. Also I found a few calls to 
> getLogger in the LMs, which dont compile. I hit the problem of not being 
> able to call getLogger in the LM code myself recently. So I added a 
> getLogger method to AbstractLM.

I changed the constructor call as well. I changed the logger calls
from getLogger() to log. log is a member of
AbstractLayoutManager. These are changes applied by Glen, and
apparently Luca made his diff before they were applied.
 
> Once compiled I tried testing with a complex document, but that fell over. 
> Previously it was working, albeit without markers. I then tried one of your 
> more simple test cases and that fell over too. Here is the stack trace, 
> which is the same for both documents:
> 
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
> ineLayoutManager.java:249)
> at 
> org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
> tManager.java:351)
> at 
> org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
> outManager.java:202)
> 
> Any thoughts would be appreciated.

No exceptions. I ran Luca's test fo files successfully.

Note that the test files erroneously specify the language as "eng";
this should be "en".

I am not surprised that your complex document did not run well. If I
understand the situation well, then the patch works for LineLM with
TextLM childLMs. It does not work with any other childLM. I expect the
other childLMs to use the null implementation of getNextKnuthElement()
and therefore to contribute no areas. This does not explain that it
causes an exception, though.
 
> Is anyone else on the team planning on making large commits over the next 
> couple of days? I would be grateful if you could hold off for a couple of 
> days whilst the problems with this large patch are resolved. I dont want to 
> have to re-apply the changes. Let me know if this causes any problems

I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?

If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

RE: Justification and line breaking

[Andreas L. Delmelle]

> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]

Hi Chris,


> Is anyone else on the team planning on making large commits over the next
> couple of days? I would be grateful if you could hold off for a
> couple of days
> whilst the problems with this large patch are resolved. I dont
> want to have to
> re-apply the changes. Let me know if this causes any problems
>

Not me, for the moment... The table-related adjustment turns out to be a bit
more complicated than I initially thought. (have a few other questions
regarding this, but these are going into a separate thread)


Cheers,

Andreas

Re: Justification and line breaking

[Chris Bowditch]

Hi Luca,
I have managed to apply your patch. Testing has not gone well. Firstly, I had
trouble compiling, due to BLM using the old constructor for LLM with FObj as
the first argument. This is easily corrected, but I would have expected a
change to BLM in your patch file. Also I found a few calls to getLogger in the
LMs, which dont compile. I hit the problem of not being able to call getLogger
in the LM code myself recently. So I added a getLogger method to AbstractLM.
Once compiled I tried testing with a complex document, but that fell over.
Previously it was working, albeit without markers. I then tried one of your
more simple test cases and that fell over too. Here is the stack trace, which
is the same for both documents:
Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
Is anyone else on the team planning on making large commits over the next
couple of days? I would be grateful if you could hold off for a couple of days
whilst the problems with this large patch are resolved. I dont want to have to
re-apply the changes. Let me know if this causes any problems
Chris

Re: Justification and line breaking

[Chris Bowditch]

Hi Luca,
I have managed to apply your patch. Testing has not gone well. Firstly, I had 
trouble compiling, due to BLM using the old constructor for LLM with FObj as 
the first argument. This is easily corrected, but I would have expected a 
change to BLM in your patch file. Also I found a few calls to getLogger in the 
LMs, which dont compile. I hit the problem of not being able to call getLogger 
in the LM code myself recently. So I added a getLogger method to AbstractLM.

Once compiled I tried testing with a complex document, but that fell over. 
Previously it was working, albeit without markers. I then tried one of your 
more simple test cases and that fell over too. Here is the stack trace, which 
is the same for both documents:

Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
Is anyone else on the team planning on making large commits over the next 
couple of days? I would be grateful if you could hold off for a couple of days 
whilst the problems with this large patch are resolved. I dont want to have to 
re-apply the changes. Let me know if this causes any problems

Chris

Re: Justification and line breaking

[Luca Furini]

Chris Bowditch wrote:

> I'm just starting to look at your patch now. First thing that strikes
> me, and this was pointed out to me before I became a committer. Please
> try to avoid commenting out large chunks of code. If the code is no
> longer needed please delete it. If we need to go back to the old code,
> we can always get the previous versions from CVS.

Ok, sorry.

> Second thing, are you just ignoring word spacing and letter spacing at the
> moment? I think one of the other FOP Dev's hit the problem of "how do we
> tell if property was specified or is it just the default" before? Hopefully
> they will speak up with a work around. If we do go without the letter
> spacing property, then they really ought to stay as NotYetImplemented in the
> FOPropertyMapping and just put come comments into the code to explain why
> it cant be implemented ATM.

No, both properties are implemented (the letter spacing only partially).
When the word spacing is not .min == .max == 0 it is used to define the
inline progression dimension of a space; otherwise, a default value is used
instead.
Letter spacing is used too, but at the moment only its .opt value is used,
so letter spacing will be the same in every line of the paragraph. The
problem is that Knuth's algorithm doesn't explicitly take into account
letter space.

Luca

Re: Applying Large Patches (was Re: Justification and line breaking)

[Luca Furini]

Chris Bowditch wrote:

> I think the easiest solution will be for
> Luca to supply his complete LineLayoutManager.java and
> TextLayoutManager.java (the two files that have more than
> 1000 lines changed) Would you mind attaching them to the patch Luca?

Ok, I'm going to do it.
By the way, the code I was working on was not the latest one, but I did not
modify files changed later (maybe the XMLrenderer, but it's a small change).

Luca

Re: Applying Large Patches (was Re: Justification and line breaking)

[Chris Bowditch]

Jeremias Maerki wrote:
Chris,
I've just upgraded my sources and tried to apply the same patch within
Eclipse to see what happens. I get two parts of the patch that Eclipse
claims to be unable to apply correctly. But this only makes up a few
lines in all. Maybe if Luca would send you the whole
LineLayoutManager.java, too, you could sort out the rest manually.
Eclipse IMO has a very good patch facility. You'd probably get farther
that way.
On the other side, I've got no idea why the patch doesn't work 100%.
Luca seems to have used the latest sources when doing the patch.
Thanks for the quick reply Jeremias. I think the easiest solution will be for 
Luca to supply his complete LineLayoutManager.java and TextLayoutManager.java 
(the two files that have more than 1000 lines changed) Would you mind 
attaching them to the patch Luca?

Thanks,
Chris

Re: Applying Large Patches (was Re: Justification and line breaking)

[Jeremias Maerki]

Chris,

I've just upgraded my sources and tried to apply the same patch within
Eclipse to see what happens. I get two parts of the patch that Eclipse
claims to be unable to apply correctly. But this only makes up a few
lines in all. Maybe if Luca would send you the whole
LineLayoutManager.java, too, you could sort out the rest manually.

Eclipse IMO has a very good patch facility. You'd probably get farther
that way.

On the other side, I've got no idea why the patch doesn't work 100%.
Luca seems to have used the latest sources when doing the patch.

On 21.05.2004 14:05:29 Chris Bowditch wrote:
> FOP Devs,
> 
> I'm trying to apply Luca's patch and running into problems. The hunks in the 
> first 9/10 files get applied okay, but when the patch program gets to 
> LineLayoutManager, it only reconises 6 hunks, the seventh is very big and for 
> some reason the patch program thinks it has found the start of another file 
> and errors with "File not found. Skip this file [n]: "
> 
> Has anyone else got any experience of working with such large and patches? Any 
> advice on how to proceed would be appreciated.



Jeremias Maerki

Applying Large Patches (was Re: Justification and line breaking)

[Chris Bowditch]

FOP Devs,
I'm trying to apply Luca's patch and running into problems. The hunks in the 
first 9/10 files get applied okay, but when the patch program gets to 
LineLayoutManager, it only reconises 6 hunks, the seventh is very big and for 
some reason the patch program thinks it has found the start of another file 
and errors with "File not found. Skip this file [n]: "

Has anyone else got any experience of working with such large and patches? Any 
advice on how to proceed would be appreciated.

Thanks,
Chris

Re: Justification and line breaking

[Chris Bowditch]

Hi Luca,
May I start by thanking you for your hard work in submitting the patch for 
Knuth's Line breaking algorithm.

I'm just starting to look at your patch now. First thing that strikes me, and 
this was pointed out to me before I became a committer. Please try to avoid 
commenting out large chunks of code. If the code is no longer needed please 
delete it. If we need to go back to the old code, we can always get the 
previous versions from CVS.

Second thing, are you just ignoring word spacing and letter spacing at the 
moment? I think one of the other FOP Dev's hit the problem of "how do we tell 
if property was specified or is it just the default" before? Hopefully they 
will speak up with a work around. If we do go without the letter spacing 
property, then they really ought to stay as NotYetImplemented in the 
FOPropertyMapping and just put come comments into the code to explain why it 
cant be implemented ATM.

I'll comment again once Ive done some testing. Thanks,
Chris

Re: Justification and line breaking

[J.Pietschmann]

Peter B. West wrote:
Do you know of a web-accessible version of the paper, or summary of the 
algorithm?
Try the TeX book, available as TeX-source from your nearest
CTAN server. The description is, umm, somewhat obscure, you
should get the commented TeX source (the .web files) as well.
J.Pietschmann

Re: Justification and line breaking

[Luca Furini]

Peter wrote:

> Do you know of a web-accessible version of the paper, or summary of the
> algorithm?

Unfortunately I don't.
In the bugzilla issue I'm going to try and summarize it.

Regards
Luca

DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems





--- Additional Comments From [EMAIL PROTECTED]  2004-05-20 08:25 ---
Thanks for the link Simon.

Although this patch may be redundant now with Luca's proposal on the way.

Re: Justification and line breaking

[Simon Pepping]

On Wed, May 19, 2004 at 12:08:50PM +0200, Luca Furini wrote:
> 
>Hi all
> 
> So, I have tried to implement Knuth's line-breaking algorithm [1], which
> calculates breaking points after having gathered information about a whole
> paragraph.
> Here are a few advantages of this algorithm:
> - first of all, the output is very beautiful; there is not a big
>   difference in width between spaces in consecutive lines, and the max
>   space width is smaller than before
> - the interaction between LLM and TLM is quite the same; the TLM returns a
>   different kind of objects, much smaller
> - the TLM code is simplified a bit, as it has no more to handle leading
>   spaces, or calculate flags (which IMO are rather line-related than
>   text-related)
> - the LLM now can quite easily handle properties such as text-indent,
>   text-align-last, word-spacing and letter-spacing

Wow. No question that this is a desirable thing to have. I thought
that it would be several releases away before we could address this.
But if you have a viable solution, by all means show it to us.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems





--- Additional Comments From [EMAIL PROTECTED]  2004-05-19 18:39 ---
1. See XSL-PR/slice7.html#suppress-at-line-break, whose default value
   is 'auto'. Block.handleWhiteSpace cannot handle this because it
   runs at the refinement stage.

2. This point is about code level. When you take a step back, you
   cannot see the point.

Re: Justification and line breaking

[Chris Bowditch]

Luca Furini wrote:
I am still thinking about justification and the more general problem of
line-breaking, and I have come to think that it's quite "strange" that the
LineLayoutManager should make choices about breaking points using only the
information provided by the TextLayoutManagers, while it should have a
wider knowledge of all the text.
(I see bug 28706 as an example of this strangeness: the LLM wants the TLM
to say if there is other text after the returned BreakPoss, but the TLM
doesn't know of the other TLMs' text)
bug 28706 is still a bit of mystery to me, well at least the disappearing 
text, as I dont have an example of it.

At the moment, lines are built one at a time, and in "normal" cases only
underfull lines are taken into account: as both bpDim and availIPD have
.min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen
one is simply the last "short" BP returned by a TLM.
Even if bpDim had .min != .max, the choice would be made between a few
alternatives for the current line, without considering what will happen
next; this could generate an output alternating tight and loose lines,
which is not very beautiful.
So, I have tried to implement Knuth's line-breaking algorithm [1], which
calculates breaking points after having gathered information about a whole
paragraph.
Here are a few advantages of this algorithm:
- first of all, the output is very beautiful; there is not a big
  difference in width between spaces in consecutive lines, and the max
  space width is smaller than before
- the interaction between LLM and TLM is quite the same; the TLM returns a
  different kind of objects, much smaller
- the TLM code is simplified a bit, as it has no more to handle leading
  spaces, or calculate flags (which IMO are rather line-related than
  text-related)
- the LLM now can quite easily handle properties such as text-indent,
  text-align-last, word-spacing and letter-spacing
Could I open a bugzilla issue and attach a patch? It would be quite a raw
patch, as I took some short cuts to make it work and there could be some
useless variables, anyway it works and could be used to show the quality
of the output. I have tested it with text-only blocks, so I don't know
what could happen in more complex situations.
this sounds like a really good idea, and would be very pleased if you could 
open a new bug in bugzilla and attach your patch. It will probably need a 
lengthy review involving plenty of testing and cleaning up.

Chris

Re: Justification and line breaking

[Peter B. West]

Luca,
Do you know of a web-accessible version of the paper, or summary of the 
algorithm?

Peter
Luca Furini wrote:
   Hi all
I am still thinking about justification and the more general problem of
line-breaking, and I have come to think that it's quite "strange" that the
LineLayoutManager should make choices about breaking points using only the
information provided by the TextLayoutManagers, while it should have a
wider knowledge of all the text.
(I see bug 28706 as an example of this strangeness: the LLM wants the TLM
to say if there is other text after the returned BreakPoss, but the TLM
doesn't know of the other TLMs' text)
At the moment, lines are built one at a time, and in "normal" cases only
underfull lines are taken into account: as both bpDim and availIPD have
.min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen
one is simply the last "short" BP returned by a TLM.
Even if bpDim had .min != .max, the choice would be made between a few
alternatives for the current line, without considering what will happen
next; this could generate an output alternating tight and loose lines,
which is not very beautiful.
So, I have tried to implement Knuth's line-breaking algorithm [1], which
calculates breaking points after having gathered information about a whole
paragraph.
Here are a few advantages of this algorithm:
- first of all, the output is very beautiful; there is not a big
  difference in width between spaces in consecutive lines, and the max
  space width is smaller than before
- the interaction between LLM and TLM is quite the same; the TLM returns a
  different kind of objects, much smaller
- the TLM code is simplified a bit, as it has no more to handle leading
  spaces, or calculate flags (which IMO are rather line-related than
  text-related)
- the LLM now can quite easily handle properties such as text-indent,
  text-align-last, word-spacing and letter-spacing
Could I open a bugzilla issue and attach a patch? It would be quite a raw
patch, as I took some short cuts to make it work and there could be some
useless variables, anyway it works and could be used to show the quality
of the output. I have tested it with text-only blocks, so I don't know
what could happen in more complex situations.
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Justification and line breaking

[Luca Furini]

   Hi all

I am still thinking about justification and the more general problem of
line-breaking, and I have come to think that it's quite "strange" that the
LineLayoutManager should make choices about breaking points using only the
information provided by the TextLayoutManagers, while it should have a
wider knowledge of all the text.
(I see bug 28706 as an example of this strangeness: the LLM wants the TLM
to say if there is other text after the returned BreakPoss, but the TLM
doesn't know of the other TLMs' text)

At the moment, lines are built one at a time, and in "normal" cases only
underfull lines are taken into account: as both bpDim and availIPD have
.min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen
one is simply the last "short" BP returned by a TLM.
Even if bpDim had .min != .max, the choice would be made between a few
alternatives for the current line, without considering what will happen
next; this could generate an output alternating tight and loose lines,
which is not very beautiful.

So, I have tried to implement Knuth's line-breaking algorithm [1], which
calculates breaking points after having gathered information about a whole
paragraph.
Here are a few advantages of this algorithm:
- first of all, the output is very beautiful; there is not a big
  difference in width between spaces in consecutive lines, and the max
  space width is smaller than before
- the interaction between LLM and TLM is quite the same; the TLM returns a
  different kind of objects, much smaller
- the TLM code is simplified a bit, as it has no more to handle leading
  spaces, or calculate flags (which IMO are rather line-related than
  text-related)
- the LLM now can quite easily handle properties such as text-indent,
  text-align-last, word-spacing and letter-spacing

Could I open a bugzilla issue and attach a patch? It would be quite a raw
patch, as I took some short cuts to make it work and there could be some
useless variables, anyway it works and could be used to show the quality
of the output. I have tested it with text-only blocks, so I don't know
what could happen in more complex situations.

Regards
Luca

[1] D. E. Knuth and M. F. Plass, "Breaking paragraphs into lines"; I found
this essay in D. E. Knuth, "Digital typography", published by CSLI
Publications

DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems





--- Additional Comments From [EMAIL PROTECTED]  2004-05-17 07:42 ---
Hi Simon,

thanks for your additional comments.

On your first point regarding trailing spaces, just to be clear, are you 
saying there shouldnt be trailing spaces according to the XSL-FO 
specification, or is this your opinion? Either way, you may be right, I just 
want to understand this problem from a specification point of view. After all 
there is a lot of talk about whitespace handling in the spec, and my 
understanding was that this is all dealt with in Block.handleWhiteSpace and so 
any whitespace left after that is intentional by the user, and by preserving 
it FOP is conforming with the spec.

On your second point, I'm afraid I still dont follow completely. You are 
analysing the problem from a code perspective and seeing a possible flaw in 
the logic. I understand that, and your reasoning looks good. However, I am 
taking a step back and saying I do not see the word "spaces" disappearing. 
Dont forget that patch 28314 is applied to CVS, so if that patch is the cause 
of the word disappearing I'm a little puzzled why it doesnt disappear when I 
run the test. If you have a different test case, then please attach it. Is 
anyone else observing this anomaly?

Chris

DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems





--- Additional Comments From [EMAIL PROTECTED]  2004-05-14 21:37 ---
Chris,

A trailing space at the end of the last line of a paragraph is
certainly a problem; it simply should not be there. While it does not
cause much harm, it is better to avoid it. It does point to a slight
problem in the logic of the code. The addition of the else branch
remedies that problem.

The word 'spaces' is there allright without the patch. The addition of
the else branch has nothing to do with it. The argument refers back to
patch 28314, where the word 'spaces' disappeared unless a change was
applied which added bp to vecInlineBreaks. I argue that I am not
completely happy with this change, and prefer to review the return
value of prevCouldEndLine, such that it returns false if prev is the
last item in vecInlineBreaks:

if (vecInlineBreaks.get(vecInlineBreaks.size() - 1) == prev) {
return false;
}

With this addition to prevCouldEndLine, instead of adding bp to
vecInlineBreaks, the disappearance of the word 'spaces' is avoided as
well.

Simon

DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems





--- Additional Comments From [EMAIL PROTECTED]  2004-05-11 11:01 ---
Hi Simon,

I can see the trailing space in the second paragraph as you describe. However, 
both occurences of the word 'spaces' exists both in PDF output and the Area 
Tree.

I am wondering if adding the else branch as you suggested to fix (1) actually 
causes issue (2). If this is the case, I may be inclined to reject this patch, 
because I'm not sure if (1) is genuinely a bug or not. I may be wrong here, as 
I am not up on all the details of the spec, but if you add spaces at the end 
of some text which is then dealt with by whitespace handling rules, in this 
case, multiple spaces collapsed into 1, then wouldnt you expect these to 
appear in the output? Perhaps the real bug here is the spaces collapsed in the 
third paragraph do not generate a single trailing space?



Chris

DO NOT REPLY [Bug 28706] - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems





--- Additional Comments From [EMAIL PROTECTED]  2004-04-30 08:16 ---
Created an attachment (id=11392)
Simon's patch

DO NOT REPLY [Bug 28706] New: - [PATCH] More justification problems

[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=28706>.
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=28706

[PATCH] More justification problems

   Summary: [PATCH] More justification problems
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: page-master/layout
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Simon Pepping comments copied from bug 28314:

1. The patch introduces a trailing space in some cases. This can be
   seen in the area tree dump, in the second block in your test FO
   file. This problem can be remedied by adding an else branch, which
   removes all BPs after prevBP from vecInlineBreaks if we do not
   reset.

2. The disappearance of the word 'spaces' is due to the fact that in
   this case bp has not yet been added to vecInlineBreaks, so that
   prevCouldEndLine is applied on prevBP only, in which case it
   returns true immediately. We want it to return false in this case
   so that reset is called and bp is not silently dropped. The problem
   can be remedied by testing against this condition before checking
   for suppressibility. I prefer that above your adding bp to
   vecInlineBreaks, of which the side effects in other cases are
   unknown. prevCouldEndLine could then be written as:

private boolean prevCouldEndLine(BreakPoss prev) {
if (!isFinished()) {
return false;
}
if (vecInlineBreaks.get(vecInlineBreaks.size() - 1) == prev) {
return false;
}
return allAreSuppressible(prev);
}

My attached patch does the above. It also does away with
prevCouldEndLine by inserting all the conditions directly in the code
and reusing allAreSuppressible.

Simon

Re: Justification

[Chris Bowditch]

J.Pietschmann wrote:

Simon Pepping wrote:

Summarizing, you mean that

1. the layout system should calculate the justification and add
   corresponding word and space areas to the area tree;


Eh, not quite. The problem is that the actual justification can
only be done after page number citations have been resolved.
Justification has now been implemented without the need for creating separate 
text areas for each word and without the renderer having to compute the split 
positions/spacing itself. Overall I'm rather pleased with Luca's solution. 
Although its yet to be applied to the postscript renderer, and it may not be 
so elegant there, because I'm not sure if postscript has commands for varying 
spaces between words.

However, I realise that justification doesnt work for page citations, or 
leaders. But as I have said before its great that it works for 90% of the text!



Chris

Re: Justification

[J.Pietschmann]

Simon Pepping wrote:
Summarizing, you mean that

1. the layout system should calculate the justification and add
   corresponding word and space areas to the area tree;
Eh, not quite. The problem is that the actual justification can
only be done after page number citations have been resolved.
Furthermore, as you noted, for certain output formats justification
can be left to the viewer in some circumstances (remember reference
aligned leaders - I don't think there is any format which can deal
with this in justified text).
I'd like to have the following:
- The layout does whitespace processing, computes line and word
  breaks and creates a corresponding area tree.
- The renderers call a layout routine doing the justification before
  rendering the line.
In case the output format can deal with the needed justifications at
hand itself, the renderers may emit the appropriate commands to the
output without calling the layout routing for justification, as a form
of optimization.
2. the area hierarchy should be revised to make it as light-weight as
   possible, to minimize resource consumption.
Oh, certainly, with priority on the Area objects which occur
most often and lock up the largest amount of memory.
J.Pietschmann

Re: Justification (was: [Bug 28130] - Errors in the calculation of adjustment factors)

[Simon Pepping]

Jörg,

Summarizing, you mean that

1. the layout system should calculate the justification and add
   corresponding word and space areas to the area tree;

2. the area hierarchy should be revised to make it as light-weight as
   possible, to minimize resource consumption.

This is an interesting idea, that can be worked out.

Recently, I heard that PDF would be able to do line justification by
itself if the target line length is given; it pads the spacing in the
line to achieve the target length. I do not know much about it; I do
not even know which PDF component would have this capability. If there
is any truth in it, it would mean that FOP could leave justification
to the renderer. But probably that would only be valid for PDF
output.

Regards, Simon

On Sat, Apr 17, 2004 at 10:16:54PM +0200, J.Pietschmann wrote:
> Chris Bowditch wrote:
> >Just want to add that I realise changing TextLM.addAreas isnt the only 
> >other change required to get jusitification working. The Renderers will 
> >need changing too, but I'm against the renderers computing their own 
> >splits, just give them each word as its own area if justification is on.
> 
> This caused some problems in the maintenance branch code, although
> the mistakes made there can be avoided.
> The biggest problem is that lots of WordArea objects are created
> which hang around some time and which also inherit a *lot* of
> unnecessary (for them) fields from Area. I think some refactoring
> of the Area hierarchy could be in order. The current state in the
> maintenance branch is roughly like this:
>   Box (not many attributes)
>+ Space
>|   + DisplaySpace
>|   + InlineSpace (well, shoud be here, but actuall isn't)
>+ Area (position, border, padding, children, heigth, width etc.)
>+ BlockArea (content heigth&width etc.)
>|+ LineArea
>|+ etc.
>|
>+ InlineArea
> + WordArea (ugh, maybe this was TextArea instead)
> | + etc.
> + some non-word inline areas
> Many inline areas can't have border, padding, background and
> perhaps some other traits, and all the space is wasted in objects
> which are instantiated *very often*. This added up to significant
> ressource problems.
> I'm still not quite sure what's the best approach to fix this.
> In C++, it certainly would be multiple inheritance. In Java,
> we could try using interfaces and some delegation:
>  interface Area
>  interface BlockArea extends Area
>  interface InlineArea extends Area
>  interface BorderPaddingBackgroundArea extends Area
>  interface NonBorderPaddingBackgroundArea extends Area
>  interface Space extends Area
>  class AbstractArea implements Area
>  class AbstractBlockArea implements BlockArea extends AbstractArea
>  class AbstractInlineArea implements InlineArea extends AbstractArea
>  class LineArea implements NonBorderPaddingBackgroundArea
>extends AbstractBlockArea
>  class WordArea implements NonBorderPaddingBackgroundArea
>extends AbstractInlineArea
>  class PageNumberReferenceArea extends WordArea
>  ... and so on ...
> (Well, because AbstractBlockArea is supposedly abstract, what class
> represents ordinary block areas? We need a good name here :-) Note
> that the real block area class may have traits which are not
> applicable to for example the line area class or the table row area
> class.)
> The code for accessing the border, padding and background traits will
> be duplicated in all classes implementing the BPBA interface, but given
> that the traits are combined in a single class, this shouln't be much
> of a problem, should it?
> Some inline areas may not have children, this could lead another set
> of interfaces.
> 
> A potentially second problem are the space non-areas. In the maintenance
> branch code, display (block) space and inline space just have a height
> (bpd) or a width (ipd), respectively. I'm not sure whether this is
> sufficient, but perhaps it is.
> 
> Regards
> J.Pietschmann

-- 
Simon Pepping
home page: http://www.leverkruid.nl

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 14:25 ---
Hi Luca,

I had another look at your proposal and ive decided its probably okay to 
delete the IF statement for emDiff < -33000. We are keeping the case that is 
supposed to be the work around for the issue described in the comments. So in 
theory we shouldnt hit the issue. Ive run a few test cases and the 
justification seems to work nicely.

However there seems to be an outstanding issue of text-align-last. In your 
test cases, setting text-align="justify" does not justify the last line, but 
in examples\fo\basic\simple.fo, the last lines are justified even though only 
text-align="justify" is specified.

For now, Im happy to apply your patch. Thanks

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 12:17 ---
Hi Chris, I'm here again.

I have done some tests, and it seems to me that a second Tw operand inside the 
array
  ... Tm 4 Tw [(first fragment ) 0 1 Tw (second fragment of text)] TJ
affects EVERY space in the array, not only the ones in the following string.

This is quite counter-intuitive, but you can see this if you look at the pdfs 
genereted in the two ways we proposed: with your patch it seems that the first 
space in the second line (which belongs to the first fragment of text) is as 
long as the other spaces (which belongs to the second fragment), while with 
mine it is visibly longer.

On this subject, I have a few doubts:
- is this behaviour (spaces in a same line are sometimes different) 
acceptable? Surely it is easier, as the LineLM has to compute only one 
adjustment factor which every TextLMs involved in the line building uses.
- if this is ok, then there are problems with fragments of text without spaces 
(this can happen with the last word before a linefeed treated as space, or the 
first after); maybe in these cases we could use letter spacing instead of word 
spacing.

Luca

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 07:30 ---
Hi

The text upside-down depends on a missing "-" that I forgot to correct in the 
patch:
  [then branch of the if]
  pdf.append("1 0 0 -1 " + ...
^^

Now I'm trying to understand what happens with your suggested change.

Luca

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 12:55 ---
Hi Luca,

Im looking at your patch now. I tried removing the IF statement and the effect 
is one part line of text in your 2nd sample is flipped upside down!

Instead I tried keeping the IF statement there, but setting the word spacing 
in both bits, e.g.

if (emDiff < -33000) {
closeText();

pdf.append("1 0 0 1 " + (rx / 1000f) + " " + (bl / 1000f) + " 
Tm "
   + (text.getTSadjust()/1000f) + " Tw [" + startText);
textOpen = true;
} else {
pdf.append(Float.toString(emDiff));
pdf.append(" " + (text.getTSadjust()/1000f) + " Tw ");
    pdf.append(startText);
}

This is closer, but the justification is very slightly out on the 2nd 
paragraph. Ill take another look later. Thanks for all your efforts

Chris

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 10:36 ---
Created an attachment (id=11151)
fo file having a line whose text comes from 2 different TextLMs

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 10:34 ---
There is still a problem concerning the way the PDFRenderer behave when the 
text of a line comes from different TLM (I'm going to attach a test fo file 
showing this problem).

[from PDFRenderer.renderText(), /*** comments added ***/]
  ...
  if (!textOpen || bl != prevWordY) {
  /*** this is done for the first fragment ***/
  /*** and it's OK ***/
  closeText();

  pdf.append("1 0 0 -1 " + (rx / 1000f) + " " + (bl / 1000f) + " Tm "
 + (text.getTSadjust()/1000f) + " Tw [" + startText);
  prevWordY = bl;
  textOpen = true;
  } else {
  // express the space between words in thousandths of an em
  int space = prevWordX - rx + prevWordWidth;
  float emDiff = (float) space / (float) currentFontSize * 1000f;
  // this prevents a problem in Acrobat Reader and other viewers
  // where large numbers cause text to disappear or default to
  // a limit
  if (emDiff < -33000) {
  /*** this would be OK, but it is not done ***/
  closeText();

  pdf.append("1 0 0 -1 " + (rx / 1000f) + " " + (bl / 1000f) + " Tm "
 + (text.getTSadjust()/1000f) + " Tw [" + startText);
  textOpen = true;
  } else {
  /*** this is done for the following fragments ***/
  /*** and it is not correct because it uses the***/
  /*** space adjustment of the first fragment!! ***/
  pdf.append(Float.toString(emDiff));
  pdf.append(" ");
  pdf.append(startText);
  }
  }
  ...

So the resulting pdf code contains:
  ... 4.869 Tw [(fragment 1) 0.0 (fragment 2)] TJ
  \--/
 |
 space adjustment for the FIRST fragment
instead of:
  ... 4.869 Tw [(fragment 1)] TJ
  ... 1.853 Tw [(fragment 2)] TJ

I have tried to fix this commenting out the "if" and the "else" branch, so 
that each fragment uses its own space adjustment, and it works.
But the comment says that the if was done to prevent a problem, so I fear that 
that problem could arise againg, removing the if.

Luca

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-04-05 14:08 ---
Created an attachment (id=11136)
test fo file

DO NOT REPLY [Bug 28208] - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-04-05 14:06 ---
Created an attachment (id=11135)
suggested patch

DO NOT REPLY [Bug 28208] New: - [PATCH] justification in PDF Renderer

[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=28208>.
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=28208

[PATCH] justification in PDF Renderer

   Summary: [PATCH] justification in PDF Renderer
   Product: Fop
   Version: 1.0dev
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Copied Luca's Furini's PDF Renderer patch for justification from resolved bug 
28130

Re: Justification in HEAD

[J.Pietschmann]

Chris Bowditch wrote:
I lean somewhat to the first strategy, because memory is usually more
of a problem then bare performance. 
This appears to be a contradiction, did you mean the last strategy?
Well, I meant the second (free memory as early as possible).

J.Pietschmann

Re: Justification in HEAD

[Chris Bowditch]

J.Pietschmann wrote:

Thanks for taking the time to explain your thoughts they are appreciated.



One point is that I didnt think Line BPs were kept past the call to 
addArea methods, which is AT construction and well before rendering. The 
TSAdjust properties is on the TextArea object which is part of the AreaTree.

Summarizing: we have a bunch of strategies:
- Keep data associated with adjustable spaces from layout for rendering,
 thereby avoiding recalculation
This is what I'm going to do. Merely because from my company's point of 
view performance is more important than memory. We specialize in 
generating lots of 1-10 (approx) page documents. I also believe this is 
the solution that I am proposing to implement.

- Discard the data as early as possible, thereby reducing peak memory
 usage
- Use something in between: copy into a compact representation, or
 discard part of the data.
I lean somewhat to the first strategy, because memory is usually more
of a problem then bare performance. 
This appears to be a contradiction, did you mean the last strategy?

I also have the gut feeling this
approach makes integration of leader expansion easier.
Of course, if someone implements several possiblities and runs benchmarks,
or even makes it a user choice, I wont object.
Chris

Re: Justification in HEAD

[J.Pietschmann]

Chris Bowditch wrote:
An interesting idea... but hasnt this already been done in more detail 
in TextLM.getNextBreakPoss? So why should the renderer have to do it 
again (although in less complexity)? I would rather have layout do this, 
otherwise this logic would have to live in every renderer.

There is a tradeoff between avoiding recomputing the word width and
carrying it around for probably some significant time.


I dont understand this bit fully. Are you saying its inefficient to 
carry around data items such as dAdjust, TSAdjust, etc? I would 
definitely say it is better than re-computing them in the renderer.
As you noticed, the TextLM.getNextBreakPoss examines the content
character by character for calculating the break possiblities,
thereby also keeping track of accumulated text width for the line.
The break possiblities, or something else, could be marked whether
they delimit adjustable space, refer to the x-offset or something
equivalent and the text snippet and all passed to the renderer,
thereby avoiding reparsing the line for adjustable space and
recalculating offsets/widths. The point is that this data could
as well be discarded after the line break is finalized. The most
convenient way to keep it around until rendering without copying
is as a list of small objects. Because redering doesn't start until
a full page is laid out, this would lock up a significant amount
memory. Whether it matters, compared to other problems, is yet to be
determined.
Summarizing: we have a bunch of strategies:
- Keep data associated with adjustable spaces from layout for rendering,
 thereby avoiding recalculation
- Discard the data as early as possible, thereby reducing peak memory
 usage
- Use something in between: copy into a compact representation, or
 discard part of the data.
I lean somewhat to the first strategy, because memory is usually more
of a problem then bare performance. I also have the gut feeling this
approach makes integration of leader expansion easier.
Of course, if someone implements several possiblities and runs benchmarks,
or even makes it a user choice, I wont object.
J.Pietschmann

Re: Justification in HEAD

[Chris Bowditch]

Simon Pepping wrote:

The trouble is renderText is being presented with a whole line at a 
time. It should be presented with smaller chunks if it is going to be 
able to add the TSAdjust space to each word space.


Do you need to break the line is as many separate text areas as there
are word spaces ( + 1 )?
Well yes, but I'm open to alternative ideas.

 

I also believe dAdjust is computed incorrectly. I'm going to change the 
dAdjust in LineLM.makeLineBreak to be targetWidth - realWidth instead of 
(targetWidth - realWidth) / realWidth. Have you got any ideas why 
dAdjust is computed this way?


I guess it is supposed to be a relative, not an absolute length
difference, so that it can be used as a factor. I have not followed
the calculations in that much detail.
Well thats what I thought, but relative factors still need to produce 
absolute results and realWidth isnt available to use as a multiplier in 
the TextLM.addAreas method.

Chris

Re: Justification in HEAD

[Chris Bowditch]

J.Pietschmann wrote:

Thanks for your responses, they are useful in helping my thought process.

Well, the line may be parsed while rendering, which means you don't have
to create area objects, roughly:
  StringTokenizer tok=new StringTokenizer(...);
  while( tok.hasMoreTokens ) {
String word = tok.nextToken();
renderText(x,y,word);
x+=width(word);
x+=adjustedSpaceWidth;
  }
An interesting idea... but hasnt this already been done in more detail 
in TextLM.getNextBreakPoss? So why should the renderer have to do it 
again (although in less complexity)? I would rather have layout do this, 
otherwise this logic would have to live in every renderer.

There is a tradeoff between avoiding recomputing the word width and
carrying it around for probably some significant time.
I dont understand this bit fully. Are you saying its inefficient to 
carry around data items such as dAdjust, TSAdjust, etc? I would 
definitely say it is better than re-computing them in the renderer.

Chris

Re: Justification in HEAD

[J.Pietschmann]

Simon Pepping wrote:
Do you need to break the line is as many separate text areas as there
are word spaces ( + 1 )?
Well, the line may be parsed while rendering, which means you don't have
to create area objects, roughly:
  StringTokenizer tok=new StringTokenizer(...);
  while( tok.hasMoreTokens ) {
String word = tok.nextToken();
renderText(x,y,word);
x+=width(word);
x+=adjustedSpaceWidth;
  }
There is a tradeoff between avoiding recomputing the word width and
carrying it around for probably some significant time.
J.Pietschmann

Re: Justification in HEAD

[Simon Pepping]

Chris,

On Mon, Jan 12, 2004 at 10:22:00AM +, Chris Bowditch wrote:
> Simon Pepping wrote:
> 
> >I am not sure whether it is necessary to break up the
> >text area into pieces.
> 
> The trouble is renderText is being presented with a whole line at a 
> time. It should be presented with smaller chunks if it is going to be 
> able to add the TSAdjust space to each word space.

Do you need to break the line is as many separate text areas as there
are word spaces ( + 1 )?
 
> I also believe dAdjust is computed incorrectly. I'm going to change the 
> dAdjust in LineLM.makeLineBreak to be targetWidth - realWidth instead of 
> (targetWidth - realWidth) / realWidth. Have you got any ideas why 
> dAdjust is computed this way?

I guess it is supposed to be a relative, not an absolute length
difference, so that it can be used as a factor. I have not followed
the calculations in that much detail.
 
Good luck. 

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Justification in HEAD

[Chris Bowditch]

J.Pietschmann wrote:

Unfortunately, ther is more to justification than just expanding spaces.
In the long term, you'll have to deal with leader expansion as well as
start and end space for inlines and perhaps letter spacing.
Leaders are particularly nasty because of they mey be aligned. It may
be necessary to insert spaces in order to get alignment, but still
avoiding inserting unnecessary spaces.
Yes you are right. But my aim is to get some basic functionality working 
 first and then iteratively refine the functionality to improve 
compliance. The refinement could happen after a release. Doing a release 
will encourage patches from new users and the refinement process should 
then snowball.

If we aim for 100% compliance from the outset then we'll never 
accomplish anything.

I'm going to change this to set TSAdjust to dAdjust.


Is this really a good idea?
Dont worry Im going to make the changes that I think are reqd to achieve 
basic justification, and then do some local testing. After which well 
decide what to do. Is there something else Im missing?

Chris

Re: Justification in HEAD

[J.Pietschmann]

Chris Bowditch wrote:
The renderer should add this to the X offset for every piece of text it 
places in the renderText method. It is missing ATM, but it is easy 
enough to add.
Unfortunately, ther is more to justification than just expanding spaces.
In the long term, you'll have to deal with leader expansion as well as
start and end space for inlines and perhaps letter spacing.
Leaders are particularly nasty because of they mey be aligned. It may
be necessary to insert spaces in order to get alignment, but still
avoiding inserting unnecessary spaces.
For example in
 foofoo bar

I'm going to change this to set 
TSAdjust to dAdjust.
Is this really a good idea?

J.Pietschmann

Re: Justification in HEAD

[Chris Bowditch]

Simon Pepping wrote:

Thanks for taking the time to reply. It is very useful to discuss this 
with someone who has an idea of how layout works.

This loop only counts word spaces. 
Yes, I know, but I believe it should do more than that.

Later the member iTSadjust is set
on the text area: t.setTSadjust(iAdjust / iWScount). It seems that
this is supposed to take care of space stretching, I do not know
how. 
The renderer should add this to the X offset for every piece of text it 
places in the renderText method. It is missing ATM, but it is easy 
enough to add.

I guess the renderer should know how to use this information. In
my test runs, it is equal to 0, which explains the lack of
justification. 
TSAdjust is set to zero because iAdjust is always zero in 
TextLM.addAreas. And this is always zero because it is based on a 
difference between min/opt/max of the ipdArea, but these are always the 
same in TextLM.getNextBreakPoss. I'm going to change this to set 
TSAdjust to dAdjust.

I am not sure whether it is necessary to break up the
text area into pieces.
The trouble is renderText is being presented with a whole line at a 
time. It should be presented with smaller chunks if it is going to be 
able to add the TSAdjust space to each word space.

The real calculations are happening much earlier, in the
getNextBreakPoss loop. In LineLayoutManager.makeLineBreak, ipdAdjust
and dAdjust are calculated based on the length of the line, and set as
members on the new linebreak position. 
I also believe dAdjust is computed incorrectly. I'm going to change the 
dAdjust in LineLM.makeLineBreak to be targetWidth - realWidth instead of 
(targetWidth - realWidth) / realWidth. Have you got any ideas why 
dAdjust is computed this way?

In the ensuing addAreas loop,
LineLayoutManager.addAreas fetches these again from the linebreak
position and sets them on the layout context. From there they are
fetched by the above calculation and used in calculating iTSadjust --
with little succes at the moment.

ipdAdjust seems to be for scaling between min, opt and max. dAdjust
seems to be the scaling for justification.
Yes I think you're right.

These are my thoughts on the process.
The whole thing is much clearer now Ive talked it over with you. Thanks 
once again,

Chris

Re: Justification in HEAD

[Simon Pepping]

Chris,

On Fri, Jan 09, 2004 at 05:20:42PM +, Chris Bowditch wrote:
> Chris Bowditch wrote:
> 
> The problem isnt that TextLM.getNextBreakPoss isnt finding BPs, problem 
> is with addAreas, which, just skips over all the BPs and creates a 
> single TextArea. This is evident from the following at the start of 
> TextLM.addAreas:
> 
> /* On first area created, add any leading space.
>  * Calculate word-space stretch value.
>  */
> while (posIter.hasNext()) {
> LeafPosition tbpNext = (LeafPosition) posIter.next();
> ai = (AreaInfo) vecAreaInfo.get(tbpNext.getLeafPos());
> if (iStart == -1) {
> iStart = ai.iStartIndex;
> }
> iWScount += ai.iWScount;
> }

This loop only counts word spaces. Later the member iTSadjust is set
on the text area: t.setTSadjust(iAdjust / iWScount). It seems that
this is supposed to take care of space stretching, I do not know
how. I guess the renderer should know how to use this information. In
my test runs, it is equal to 0, which explains the lack of
justification. I am not sure whether it is necessary to break up the
text area into pieces.

The real calculations are happening much earlier, in the
getNextBreakPoss loop. In LineLayoutManager.makeLineBreak, ipdAdjust
and dAdjust are calculated based on the length of the line, and set as
members on the new linebreak position. In the ensuing addAreas loop,
LineLayoutManager.addAreas fetches these again from the linebreak
position and sets them on the layout context. From there they are
fetched by the above calculation and used in calculating iTSadjust --
with little succes at the moment.

ipdAdjust seems to be for scaling between min, opt and max. dAdjust
seems to be the scaling for justification.

These are my thoughts on the process.

Regards, Simon

-- 
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl
public key: http://www.leverkruid.nl/personal/sp.asc
fingerprint: E3BF 7295 9AA8 8B8A C01A  219D FAAC 088C 6B28 F549

Re: Justification in HEAD

[Chris Bowditch]

Chris Bowditch wrote:



The child LM of Line LM is Text LM. It appears that when dealing with 
just plain text paragraphs, i.e. no fo:inlines or fo:wrapper changing 
fonts within a line, etc, then there is almost a 1:1 relationship 
between Line LM and Text LM. So when renderText is called on the 
renderer it is presented with a whole line of text, and there is no 
opportunity to insert extra spaces. Unless the renderer is going to 
break this string and place individual characters, but that to me seems 
wrong.

So question is should TextLM.getNextBreakPoss be splitting the line into 
individual words? 
Actually after reading the above I realised it was wrong - apologies for 
wasting bandwidth with my babbling.

The problem isnt that TextLM.getNextBreakPoss isnt finding BPs, problem 
is with addAreas, which, just skips over all the BPs and creates a 
single TextArea. This is evident from the following at the start of 
TextLM.addAreas:

/* On first area created, add any leading space.
 * Calculate word-space stretch value.
 */
while (posIter.hasNext()) {
LeafPosition tbpNext = (LeafPosition) posIter.next();
ai = (AreaInfo) vecAreaInfo.get(tbpNext.getLeafPos());
if (iStart == -1) {
iStart = ai.iStartIndex;
}
iWScount += ai.iWScount;
}
there are no conditions in the while to break out. If no one has any 
better ideas/suggestions then i'll look at changing this next week.



Chris

Justification in HEAD

[Chris Bowditch]

Fellow FOP Devs,

I've been thnking about how to implement Justified text in HEAD, and 
would appreciate some suggestions/comments on my thought process.

I know Joerg posted something on this back in November in which he said 
the missing piece was the renderer not resizing the spaces, but the 
problem is deeper than this.

The child LM of Line LM is Text LM. It appears that when dealing with 
just plain text paragraphs, i.e. no fo:inlines or fo:wrapper changing 
fonts within a line, etc, then there is almost a 1:1 relationship 
between Line LM and Text LM. So when renderText is called on the 
renderer it is presented with a whole line of text, and there is no 
opportunity to insert extra spaces. Unless the renderer is going to 
break this string and place individual characters, but that to me seems 
wrong.

So question is should TextLM.getNextBreakPoss be splitting the line into 
individual words? Which can then be placed by the renderer with the 
space adjustment required for justification. I believe this is similar 
to how it works in the maintenance branch. Although I'm sure TextLM is 
keeping lines together for a good reason.

Chris

DO NOT REPLY [Bug 2106] - broken justification with numeric umlaut entities

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106

broken justification with numeric umlaut entities

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-02-11 19:46 ---
*** Bug 16955 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 2106] - broken justification with numeric umlaut entities

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106

broken justification with numeric umlaut entities

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-02-07 11:25 ---
*** Bug 16870 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 2106] - broken justification with numeric umlaut entities

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106

broken justification with numeric umlaut entities

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-07-19 06:28 ---
Fixed in CVS maintenance branch

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 2106] - broken justification with numeric umlaut entities

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106

broken justification with numeric umlaut entities

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[Bug 2106] New: - broken justification with numeric umlaut entities

[bugzilla]

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106

*** shadow/2106 Mon Jun 11 04:23:36 2001
--- shadow/2106.tmp.25363   Mon Jun 11 04:23:36 2001
***
*** 0 
--- 1,118 
+ ++
+ | broken justification with numeric umlaut entities  |
+ ++
+ |Bug #: 2106Product: Fop |
+ |   Status: NEW Version: 0.17|
+ |   Resolution:Platform: PC  |
+ | Severity: Normal   OS/Version: Windows NT/2K   |
+ | Priority: Other Component: pdf renderer|
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]|
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ a line having a word with a numeric entity is wrongly indented.
+ It seems that the width of escaped characters like Ü is not
+ computed. The following fo-code should produce two identical
+ paragraphs:
+ 
+ --
+ 
+ 
+ http://www.w3.org/1999/XSL/Format";>
+   
+ 
+ 
+   
+   
+   
+ 
+   
+  
+ 
+ 
+   
+ 
+   
+   Seite 
+   
+ 
+ 
+ 
+   
+
+   
+ 
+ 
+ 
+ 
+   
+ rendering error with numeric entities
+   
+ 
+ 
+   
+ Die genau umgekehrte Kurslinie zielte dorthin, wo sich - befände man sich 
+ nicht im Frieden und wäre die Raumpiraterie kein ausgerottetes Übel - 
+ ein möglicher Angreifer, unsichtbar für das Auge und auch mit den 
+ besten und teuersten elektronischen Mitteln kaum zu orten, so lange auf Position 
+ gehalten hätte, bis ihm der Augenblick zum Angriff günstig erschien. 
+ Das war eine in den Kämpfen des Bürgerkrieges erprobte Taktik - und 
+ später war sie von Ahmed Khan zur höchsten Perfektion entwickelt 
+ worden. Bei all seinen Überfällen hatte der aus den VOR stammende 
+ Deserteur, der sich mit einer gemischten Bande anderer Halunken zusammengetan 
+ hatte, das Moment der Überraschung auf seiner Seite gehabt. Anders war es 
+ nicht zu erklären, daß selbst schnelle Schiffe seiner 
+ verhältnismäßig plumpen Aggression zum Opfer fielen.
+   
+ 
+   
+ Die genau umgekehrte Kurslinie zielte dorthin, wo sich - befände man sich nicht 
+ im Frieden und wäre die Raumpiraterie kein ausgerottetes Übel - ein möglicher 
+ Angreifer, unsichtbar für das Auge und auch mit den besten und teuersten 
+ elektronischen Mitteln kaum zu orten, so lange auf Position gehalten hätte, bis 
+ ihm der Augenblick zum Angriff günstig erschien. Das war eine in den Kämpfen des 
+ Bürgerkrieges erprobte Taktik - und später war sie von Ahmed Khan zur höchsten 
+ Perfektion entwickelt worden. Bei all seinen Überfällen hatte der aus den VOR 
+ stammende Deserteur, der sich mit einer gemischten Bande anderer Halunken 
+ zusammengetan hatte, das Moment der Überraschung auf seiner Seite gehabt. Anders 
+ war es nicht zu erklären, daß selbst schnelle Schiffe seiner verhältnismäßig 
+ plumpen Aggression zum Opfer fielen.
+   
+ 
+  
+
+ 
\ No newline at end of file

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]