I think it would be better to report this item in a patch of
its own. It really is a new issue.
Ok, sorry.
I'm going to do as you suggest.
Luca
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
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
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
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
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
Simon, thanks for all the information.
At the moment, I am working on LeafNodeLM (now fo:leader works)
and InlineStackingLM.
I think I'll be able to post a second patch next week.
Regards
Luca
Simon Pepping wrote:
- word spacing and letter spacing are now fully implemented, they can
both have MinOptMax values; but I am still thinking about how to
differentiate a user-defined zero value from a default zero value ...
You cannot. A default value is a user-defined value supplied
Simon Pepping wrote:
Nested inline and other LMs: The output contains errors, see the
comments in the text. The errors occur when hyphenation is set to
true.
Fixed: there were errors in the method addALetterSpaceTo of LeafNodeLM and
InlineStackingLM.
I also found a bug in the
Arnd Beißner wrote:
In the example, line 2 is neither the last nor the only line of a block,
and it's also not a line ending in U+000A, so it should be justified.
Section 7.15.10 of the recommendation states that the property
text-align-last Specifies the alignment of the last line-area child
Simon Pepping wrote:
You mention that you have not implemented the Knuth algorithm for
ContentLM. Would it be difficult to do that?
No, I have almost done.
I think I will be able to attach a patch including this fix this
afternoon.
Regards
Luca
Simon Pepping wrote:
Still to be done:
- Resolve the regressions mentioned above.
As concerns leader with use content, patch created and successfully tested.
The ContentLM calls getNextKnuthElements on his child InlineStackingLM, uses
the returned elements to calculate the pattern width and
Simon Pepping wrote:
1. InlineStackingLM implements InlineLM. LineLM extends
InlineStackingLM and thus implements InlineLM. IMHO it should
not. Implementing InlineLM should be equivalent to
generatesInlineAreas returning true.
You are right, it's quite strange, but the LineLM still uses a
Jeremias Maerki wrote:
Luca,
is your CLA on its way?
I sent it by fax a few minutes ago (sorry for the delay).
Do I have to send it by mail too?
Regards
Luca
Glen Mazza wrote:
The title centers correctly in 0.20.5, but is left-justified in 1.0.
[...]
Luca, are you looking at this issue of text alignment in general?
Yes, this happens when the text is short and the algorithm is not able to
find a set of breaking points: the fallback method can't
Jeremias Maerki wrote:
No, I don't think Luca has write access, yet. I know by now that the CLA
is recorded but the account hasn't been created, yet, although I've
already sent a reminder.
I have just received the e-mail confirming the creation of my account.
I am now reading the
Glen Mazza wrote:
[BTW, I'm considering getting that Digital Typography
book by Knuth you had mentioned earlier. Do you
recommend it? (I was thinking that given all the time
I spend on FOP I should start looking a little more at
the scientific aspects of this work.)]
I think it's very
I have tried to add some comments to the Knuth[Element, Box, Glue,
Penalty] classes.
As I am not sure they are clear enough (I'm not even sure they are written
in a proper English! :-) ) I'd like to hear your opinions before
committing them.
Regards,
Luca
Index: KnuthBox.java
Simon Pepping wrote:
Indeed. Something like ICLM is needed, which creates an inline area
containing the block areas.
A block inside another block
fo:blockNormal text fo:blockinner block/fo:block normal text./fo:block
creates 3 different paragraphs:
- Normal text
- inner block
- normal text.
Finn Bock wrote:
1) What is the purpose of 2 glues for a normal space in END and START
alignment:
new KnuthGlue(0, 3 * wordSpaceIPD.opt, 0, , false));
new KnuthPenalty(0, 0, false, , true));
new KnuthGlue(wordSpaceIPD.opt, - 3 * wordSpaceIPD.opt, 0, , true));
The purpose is to give each
I have the great pleasure to announce that Jeremias Maerki has
been elected as an ASF member at the last member's meeting
during ApacheCon.
Congratulations!
Luca
Finn Bock wrote:
(starting from the second question)
And why not adjust the spacing within the user specified min/max for
START and END alignment?
Should the user desire adjusted spaces, wouldn't it be better for him to
specify justified alignment? :-)
Seriously, the recommendation (at 7.16.2
Finn Bock wrote:
I tend to read that to mean that word spacing may be pushed beyond the
specified range by justification. And I would think that unjustified
alignment still has the option of using the word-spacing range but
ofcourse has to stay within the range.
I'm not convinced ...
The
Finn Bock wrote:
Ok, so it isn't really needed when the algorithm is implemented in java.
Just by having the previous node linked from within bestActiveNode is
enough to keep the inactive nodes alive.
So inactiveList can be removed.
You are right, I'm going to remove it.
Thanks!
Regards,
Glen Mazza wrote:
Luca, I think we should be using getWidth() instead of
getW(), correct?
Yes, it would be much clearer!
I'm going to rename:
getW() - getWidth()
getY() - getStretch()
getZ() - getShrink()
getP() - getPenaltyValue()
The last name is quite long: I first thought of
Finn Bock wrote:
I've been playing around with the knuth line breaking code and made a
slight refactoring of it. [...]
These improvements could also be applied to the existing code, so I
think the more interesting point is the quality of the refactoring
job.
I think this is a very good
Jeremias Maerki wrote:
If someone has an idea about the ArrayOutOfBoundsException, all the
better. I'm currently trying to debug that thing.
It's because of this line in LineLM.addAreas():
iCurrParIndex = 0;
If a block has properly handled preserved linefeeds, it will generate more
than
Finn Bock wrote:
I would pass the element on the immidiate parent, which recursively
passes them on the top-level LM in the direction. For inline, the
toplevel would be LineLM and for blocks it would be the PageLM.
Ok, I misunderstood what you wrote, now I think we were saying the same
thing
I noticed a strange behaviour concerning margins that could be related to
the inheritance of start-indend and end-indent, which was discussed a few
weeks ago.
It seems that in some situations the margins are subtracted twice from the
available inline progression dimension.
In the little fo file
Jeremias Maerki wrote:
[Glen Mazza]
So Luca is correct that both fo:simple-page-masters
should generate the same overall margins of 50 pt.
each, no?
No. :-)
Ok, now I am convinced you are right.
Thanks for all your explanations, I always found this part of the
recommendation quite obscure!
Simon Pepping wrote:
+=== Space specifiers ===
+
+When the space specifiers resolve to zero around a page break, we are
+in the same situation as that of a word space in line breaking. It is
+represented by the sequence `box - glue - box`.
I add just a few thoughts about this subject.
If there
Jeremias Maerki wrote:
However, Luca's example
does not fully resolve in my brain. The penalty, for example, must not
be infinite or it will not be eligible for break possibility. A legal
break is defined by Knuth as a number b such that either
(i) xb is a penalty item with pb infinity, or
Jeremias Maerki wrote:
Anyway, I'd like to ask if we could hold to a brainstorming conference
call on page breaking either Sunday evening or next Monday or Tuesday
somewhere between 8:00 and 24:00 CET. Of course, on my wish list there
are Simon, Finn and Luca. I'm happy to call either of you on
Jeremias Maerki wrote:
Luca, do you think your total-fit approach may be written in a way to
handle changing available IPDs and that look-ahead can be disabled to
improve processing speed at the cost of optimal break decisions?
I think that a first fit algorithm could be implemented in two
34 matches
Mail list logo