Simon Pepping wrote:
snip/
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
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
Peter B. West wrote:
snip/
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
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.
snip/
While textIndent is initialized in the
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
Chris Bowditch wrote:
Peter B. West wrote:
snip/
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
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
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
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Hi Chris,
snip /
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
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
--- 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
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
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
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
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
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,
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
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
/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.
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
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.
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
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
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
/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
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
/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
/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
/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
/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
/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
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
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
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
/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
/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
/show_bug.cgi?id=28208
[PATCH] justification in PDF Renderer
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
/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
/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
/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
/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
/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
/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
J.Pietschmann wrote:
Thanks for taking the time to explain your thoughts they are appreciated.
snip/
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
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
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
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
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.
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 )
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
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
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
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
/show_bug.cgi?id=2106
broken justification with numeric umlaut entities
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED
/show_bug.cgi?id=2106
broken justification with numeric umlaut entities
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED
/show_bug.cgi?id=2106
broken justification with numeric umlaut entities
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=2106
broken justification with numeric umlaut entities
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED
58 matches
Mail list logo
