Applied. Thank you, Richard.
I wonder why the Bugzilla notification take such a long time to show up.
Or maybe my spam filter swallows them and I haven't noticed, yet.
On 20.06.2005 10:08:12 richardw wrote:
> [EMAIL PROTECTED] writes:
> > jeremias2005/06/15 05:24:01
> >
> > Modified:
[EMAIL PROTECTED] writes:
> jeremias2005/06/15 05:24:01
>
> Modified:src/java/org/apache/fop/render/awt AWTRenderer.java
>src/java/org/apache/fop/render/java2d Java2DRenderer.java
>src/java/org/apache/fop/render/print PrintRenderer.java
>
Jeremias,
Yes, I'm leaning towards separating PSLM from LayoutManager at least as
a trial. I do know our RootLayoutManager (=ATH) doesn't need it, ATH is
nicely anchored to the floor, and it was *much, much* easier for me to
grok than PSLM (taking into account of course ATH's lesser
function
Glen,
this was quite interesting. Right after your change here, my local
changes started to fail. Obviously, my changes for changing BPD between
pages was the first use case for getTopLevelLM() to fetch the PSLM. But
you are likely to remove the LayoutManager interface from PSLM I took a
different
Thanks...with your IQ and my vacuum cleaner (and liposuction device, for
particularily hard-to-reach areas) we're gonna get layout looking really
*sleek*... ^u^
Glen
Luca Furini wrote:
Glen Mazza wrote:
Are you sure here? We had two versions of addALetterSpaceTo() --
the version in ILLM
Glen Mazza wrote:
Are you sure here? We had two versions of addALetterSpaceTo() --
the version in ILLM which takes a List (I didn't touch that one),
and a old (?) version from AbstractLayoutManager that takes a
KnuthElement. It is that latter version that I removed--it
wasn't being called an
e--not the
former.
Glen
- Original Message -
From: "Luca Furini" <[EMAIL PROTECTED]>
To:
Sent: Friday, June 10, 2005 2:19 PM
Subject: Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr
StaticContentLayoutManager.java LineLayoutManager.java
AbstractLayoutManager.j
Thanks for your optimization work, Glen.
Just a note: the method addALetterSpaceTo() is defined in the interface
InlineLevelLayoutManager and is still used.
It is called by LineLM.collectInlineKnuthElements(), if the last element
returned by a child LM and the first returned by the next child LM
No problem. I've fixed it.
On 10.06.2005 15:57:16 Renaud Richardet wrote:
> Bonjour
>
> Jeremias Maerki wrote:
>
> >You're right. I didn't check them when reviewing the patch. I tried
> >again but I don't get valid images.
> >
> >Renaud, would you please post the two images separately? Thank you
Bonjour
Jeremias Maerki wrote:
You're right. I didn't check them when reviewing the patch. I tried
again but I don't get valid images.
Renaud, would you please post the two images separately? Thank you.
1) I can't find the pictures anymore (changed computer, and failed to
copy those res
Glen Mazza writes:
> I think we're going to need to know Richard's last name
Wheeldon. Slightly more details are on my website: www.rswheeldon.com
> as well as have a CLA from him
I'll fax an ICLA to Apache later today.
Richard
Richard, to put what Glen wrote a little more politely: The Apache
Software Foundation established a policy after which every contributor
who submits more than just a little bugfix or patch (i.e. who is
contributing substantially), should send a signed Contributor License
Agreement to the Foundatio
ate work to Apache.
Glen
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Thursday, June 09, 2005 10:33 AM
Subject: Re: cvs commit: xml-fop/src/java/org/apache/fop/render
RendererFactory.java
> [EMAIL PROTECTED] writes:
> > jeremias2005/06/09 01:49:27
> >
2005 4:49 AM
Subject: cvs commit: xml-fop/src/java/org/apache/fop/render
RendererFactory.java
> jeremias2005/06/09 01:49:27
>
> Modified:src/java/org/apache/fop/render/awt AWTRenderer.java
>src/java/org/apache/fop/render/awt/v
You're right. I didn't check them when reviewing the patch. I tried
again but I don't get valid images.
Renaud, would you please post the two images separately? Thank you.
On 09.06.2005 16:33:59 richardw wrote:
> [EMAIL PROTECTED] writes:
> > jeremias2005/06/09 01:49:27
> >
> > Modified
[EMAIL PROTECTED] writes:
> jeremias2005/06/09 01:49:27
>
> Modified:
>src/java/org/apache/fop/render/awt/viewer/images fopLogo.gif
> logo_big.jpg
> Submitted by: Renaud Richardet
Both of these files appear to be corrupt. Can you please
Yes, you're absolutely correct. Up until now my "ROT" was pure line
count -- if just one, don't bother with the isDebugEnabled(). But now I see
the need to also check the parameter supplied. BTW, if you're making
changes to the code today if you can take care of this it would be
appreciated. El
On 06.06.2005 09:15:34 Jeremias Maerki wrote:
> operator it depends on the intelligence of the JIT compiler whether it
That should have been the Java Compiler, not the JIT compiler.
Jeremias Maerki
An explanation why the "log.isDebugEnabled()" was there and why it
should be added again (maybe not necessarily in this case since it's
only called once per page but as a general rule):
"+" operations with Strings usually results in a StringBuffer being
created the two Strings before and after the
Andreas L. Delmelle wrote:
[(*) = OT: instead of non-contextually sorting the integer values according
to the alphabetical name of the constants in question, which only _looks_
nice code-wise, but seems to serve no other purpose.
I come from an Oracle database background, so this is quite ac
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
>
Hi,
(OK, apologies for my alias turning up... Completely unintended.
here's the remainder of the response. Other comments, much longer than the
previous one...)
> On 17.05.2005 23:24:55 Andreas L. Delmelle wrote:
>
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
>
Hi,
(A very short one this time --only one clarification...)
> On 17.05.2005 23:24:55 Andreas L. Delmelle wrote:
>
> > Anyway, the more I read the parts in the XSL-FO and CSS Rec
> about borders,
> > the more I get
Hi Andreas
On 17.05.2005 23:24:55 Andreas L. Delmelle wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >
>
> Hi Jeremias and others interested in table-borders,
>
>
> (Sorry for the --again-- long post, but...)
> The following comment in the code (TC
done.
On 18.05.2005 00:58:46 Glen Mazza wrote:
> I believe you had also commented out some Maker classes in
> layoutmgr.LayoutManagerMapping for unused table LMs. Can we get rid of
> those now as well?
>
> Thanks,
> Glen
>
>
> [EMAIL PROTECTED] wrote:
>
> >jeremias2005/05/17 02:10:40
I believe you had also commented out some Maker classes in
layoutmgr.LayoutManagerMapping for unused table LMs. Can we get rid of
those now as well?
Thanks,
Glen
[EMAIL PROTECTED] wrote:
jeremias2005/05/17 02:10:40
Modified:src/java/org/apache/fop/layoutmgr/table
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
Hi Jeremias and others interested in table-borders,
(Sorry for the --again-- long post, but...)
The following comment in the code (TCLM) got me wondering...
> //Create empty grid units to hold resolved borders of
Message received and understood, code improved. I'll pay more attention
next time. Looks like peer review really works around here. Thanks, Glen.
On 13.05.2005 01:38:24 Glen Mazza wrote:
> [EMAIL PROTECTED] wrote:
>
> >jeremias2005/05/12 07:13:45
> >
> > Modified:src/java/org/apache/fop/
[EMAIL PROTECTED] schrieb:
gmazza 2005/05/12 17:54:14
Modified:src/java/org/apache/fop/layoutmgr Tag:
Temp_KnuthStylePageBreaking
PageSequenceLayoutManager.java
Log:
Copied the logic over incorrectly--fixed (even though IIRC
RetrieveMarkers
[EMAIL PROTECTED] wrote:
jeremias2005/05/12 07:13:45
Modified:src/java/org/apache/fop/layoutmgr/table Tag:
Temp_KnuthStylePageBreaking TableStepper.java
TableContentLayoutManager.java EffRow.java
Log:
Fix for ArrayIndexOutOfBoundsException wh
Glen, I know you want to practice your German, but this is still an
English mailing list. Thank you.
On 11.05.2005 23:21:50 Glen Mazza wrote:
> Danke. Morgen, vielleicht anstatt einem Patch soll ich der Zeit
> verbringen, Checkstyle in meinem Eclipse installieren.
>
> Glen
Jeremias Maerki
Danke. Morgen, vielleicht anstatt einem Patch soll ich der Zeit
verbringen, Checkstyle in meinem Eclipse installieren.
Glen
[EMAIL PROTECTED] wrote:
jeremias2005/05/11 08:29:29
Modified:src/java/org/apache/fop/layoutmgr Tag:
Temp_KnuthStylePageBreaking
On May 6, 2005, at 2:56 AM, Chris Bowditch wrote:
Andreas L. Delmelle wrote:
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Glen:
Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.)
entfernen. ...
English: Yes, we should remove the old code now.
Of course 'should',
Andreas L. Delmelle wrote:
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Glen:
Ja, jetzt sollen wir das alterer Kodierung
(pNFA() usw.) entfernen. ...
English: Yes, we should remove the old code now.
Of course 'should', got my modal verbs mixed up again :-)
Thanks f
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> > > Glen:
> > > Ja, jetzt sollen wir das alterer Kodierung
> > > (pNFA() usw.) entfernen. ...
>
> English: Yes, we should remove the old code now.
Of course 'should', got my modal verbs mixed up again :-)
Greetz
> Jeremias/Glen:
>
> could you translate this for me? Sorry but I dont speak German!
Here you are:
On 06.05.2005 09:47:33 Chris Bowditch wrote:
> Glen Mazza wrote:
>
> > Jeremias Maerki wrote:
> >
> >> Glen,
> >>
> >> I'd like you to revert that one and take a different approach if any.
> >>
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
Hi Chris,
Let me have a go...
> Glen Mazza wrote:
> >
> > Kein Problem. Bald werde ich dass machen, aber nicht
> > dieser Nacht, weil ich ziemlich muede bin.
"No prob. I'll do it soon, but not tonight, because I'm
Glen Mazza wrote:
Jeremias Maerki wrote:
Glen,
I'd like you to revert that one and take a different approach if any.
Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil
ich ziemlich muede bin.
handleBreak does really handle break-before AND break-after, so the name
was ok.
Jeremias Maerki wrote:
Glen,
I'd like you to revert that one and take a different approach if any.
Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil
ich ziemlich muede bin.
handleBreak does really handle break-before AND break-after, so the name
was ok.
Ja, Sie haben R
Glen,
I'd like you to revert that one and take a different approach if any.
handleBreak does really handle break-before AND break-after, so the name
was ok. What can be is that there is some left-over code from the
previous approach. I'm not sure but I think we don't even need the
break-* traits a
Looks good!
Glen
[EMAIL PROTECTED] wrote:
lfurini 2005/04/27 08:59:59
Modified:src/java/org/apache/fop/layoutmgr Tag:
Temp_KnuthStylePageBreaking AbstractBreaker.java
PageSequenceLayoutManager.java
Log:
Using a more clear boolean instead of a
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> --- [EMAIL PROTECTED] wrote:
> >
> > -protected void startPart(BlockSequence list)
> > {
> > +protected void startPart(BlockSequence list,
> > int localPageNumber) {
>
> "boolean isFirstPageByBlock" is probabl
Oops...
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> --- [EMAIL PROTECTED] wrote:
> >
> > -protected void startPart(BlockSequence
> list)
> > {
> > +protected void startPart(BlockSequence
> list,
> > int localPageNumber) {
>
> "boolean isFirstPageByBlock" is probably better.
>
--- [EMAIL PROTECTED] wrote:
>
> -protected void startPart(BlockSequence list)
> {
> +protected void startPart(BlockSequence list,
> int localPageNumber) {
"boolean isFirstPageByBlock" is probably better.
The meaning of "localPageNumber" to indicate the first
page created by a
Yes, I agree. I've even thought about that for tables, too. I guess
it's a matter of taste whether we do that or not. I don't think the
Rec says anything about it. Anyway, I'd do it like you did for lists,
but tables may be less important in this respect. We can add it later if
necessary.
On 15.04
I wrote:
> Creating a combined list for label and body
I forgot to mention that this work is mainly based on Jeremias' code for
tables.
There is only a significant difference while computing the first step:
+if (backupHeights[0] == 0 && backupHeights[1] == 0) {
+// this is
Hi Luca:
--- Luca Furini <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
>
> > Hi Luca,
> >
> > 1.) Can the corresponding setting of these values
> on
> > fo:root (642-643 of [1]) in PSLM now be removed?
> (I
> > think so...because what is set on fo:flow will be
> used
> > instead of fo:root.)
>
Glen Mazza wrote:
> Hi Luca,
>
> 1.) Can the corresponding setting of these values on
> fo:root (642-643 of [1]) in PSLM now be removed? (I
> think so...because what is set on fo:flow will be used
> instead of fo:root.)
I agree with you.
The method LengthBase.getBaseLength() (which is called b
Hi Luca,
1.) Can the corresponding setting of these values on
fo:root (642-643 of [1]) in PSLM now be removed? (I
think so...because what is set on fo:flow will be used
instead of fo:root.)
2.) Also, does your change below need to be added to
StaticContentLayoutManager as well?
Many thanks,
G
Thanks! That's very good and already makes things clearer for me!
On 08.04.2005 19:11:28 Luca Furini wrote:
> > BTW, would you do me a favor and add a more verbose explanation of
> > LayoutManager.getChangedKnuthElements(). That is one method I still
> > don't fully understand. What does "changed"
Jeremias Maerki wrote:
> Luca, I'd prefer if we wouldn't have to have this many casts to Block
> and BlockContainer all over the LM. Couldn't we just add methods like
> getBlockFO() and getBlockContainerFO() which do the cast? I can do this
> but I don't want to interfere with anything you might
Luca, I'd prefer if we wouldn't have to have this many casts to Block
and BlockContainer all over the LM. Couldn't we just add methods like
getBlockFO() and getBlockContainerFO() which do the cast? I can do this
but I don't want to interfere with anything you might do in those LMs
right now.
BTW,
OK, thanks.
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> No, this is by design. A GridUnit instance for an
> empty cell
> (this.cell=null) must return null for this method.
No, this is by design. A GridUnit instance for an empty cell
(this.cell=null) must return null for this method. Just right-click on
the method name in Eclipse and choose References/Project. This will
bring you to the CollapsingBorderModelEyeCatching class which is
responsible for border resolution.
No--no--no--these are *internal* errors pointing out
our own mistakes. Just for us. Not for external
users.
You know how Microsoft Word puts little squiggly red
lines under words that you misspell? It would be like
arguing that the red squiggly line should be a really
pale, hard-to-see yellow.
As I stated in a previous post, I'm not convinced that throwing an NPE
is the best choice. At the very least (IMO) this should be configurable
(and again IMO, it should default to WARN instead of ERROR).
Web Maestro Clay
On Apr 7, 2005, at 9:07 AM, Glen Mazza wrote:
Jeremias,
I do not fully unde
Jeremias,
I do not fully understand the business logic for
tables--so what I am saying here may not be relevant.
But if cell should *never* be null (i.e., the caller
of this method is very sloppily written), please let
the methods NPE, raise IndexOutOfBoundsError,
InvalidStateException, etc., so
The basic framework stands and so far seems to do its work. Now I can
get on to adding features again (display-align, borders, keeps, breaks
etc.).
At first sight, the whole thing probably looks like a big mess. I didn't
want to remove the old code just yet, because there may be several
passages t
This is all I see left that needs to move out of PSLM.
I now agree though that column balancing should stay
in PSLM, because it's a dynamic layout task and
because its implementation--unlike the rote setting up
of regions for a PageViewport--would most likely
differ between PSLM implementations (
Not an objection but a concern: I get the impression that more an more
logic wanders off into the area package which should IMO only be a data
structure plus serialization/deserialization and reference resolution.
And I believe that column balancing is clearly the LMs responsibility.
Especially wit
Team,
I'd like to recommend next that we move the
initialization (*not* population) of the
page-reference-areas, region-viewport-areas, and
region-reference-areas from PSLM to area.PageViewport
(and possibly some in area.RegionViewport). IOW,
everything from line 685 to the end of the file
gone[1
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Over all, this sounds ok. There's one point, though:
> the one with the
> column balancing. Following XP principles I'd skip
Yeah, I like XP [1]... ;)
> that because I'm
> almost sure that we can't implement column balancing
> just by calling a
>
Over all, this sounds ok. There's one point, though: the one with the
column balancing. Following XP principles I'd skip that because I'm
almost sure that we can't implement column balancing just by calling a
balanceColumns() method like your foresee. Don't try to do too many
optimizations too soon
--- [EMAIL PROTECTED] wrote:
>
> -private void createSpan(int numCols) {
> +/**
> + * Creates a new span reference area.
> + * @param bodyRegion The region-body to
> create the span for
> + * @param spanned true if a spanned region
> should be created
> + */
>
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> Please do the changes you
> propose, probably I
> will understand then.
Done. It was just a method renaming--this method was
really about laying out the side regions, not
necessarily static content, because fo:flow's areas
can be placed into a S
Thanks--also happy to see my work that didn't conflict
was carried over into the new branch.
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Done.
>
> On 19.03.2005 08:13:42 Glen Mazza wrote:
> > Jeremias,
> >
> > The XSL term for these objects appear to be "side
> > regions"[1]--I would
Sorry, but I don't get it. Please do the changes you propose, probably I
will understand then. Are there any layoutengine tests that you could
write to illustrate this?
On 19.03.2005 08:24:15 Glen Mazza wrote:
> This is old code, but it should really be
> layoutSideRegion()/RegionOuter(), correct?
Done.
On 19.03.2005 08:13:42 Glen Mazza wrote:
> Jeremias,
>
> The XSL term for these objects appear to be "side
> regions"[1]--I would recommend us using SideRegion
> instead here, and can take care of the renaming if you
> would like.
>
> Glen
>
> [1]
> http://www.w3.org/TR/2001/REC-xsl-20011
This is old code, but it should really be
layoutSideRegion()/RegionOuter(), correct? The
purpose of this method is for regions that don't have
columns, i.e., any region except fo:region-body.
fo:static-content can be directed anywhere, including
fo:region-body. (Although PSLM currently raises an
Jeremias,
The XSL term for these objects appear to be "side
regions"[1]--I would recommend us using SideRegion
instead here, and can take care of the renaming if you
would like.
Glen
[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_region-body
--- [EMAIL PROTECTED] wrote:
> jeremi
On Thu, Mar 17, 2005 at 08:48:03AM +0100, Finn Bock wrote:
> [EMAIL PROTECTED] wrote:
>
> >gmazza 2005/03/16 15:18:43
> >
> > Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java
> >StaticContentLayoutManager.java
> >AbstractLa
[EMAIL PROTECTED] wrote:
gmazza 2005/03/16 15:18:43
Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java
StaticContentLayoutManager.java
AbstractLayoutManager.java
PageSequenceLayoutManager.java
On 13.03.2005 23:30:05 Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > Go to Windows/Preferences, then Java/Editor, tab
> > "Typing", the activate
> > "Insert spaces for tabs".
> >
>
> Done.
>
> > Also, get the Eclipse plug-in for Checkstyle:
> > http://eclipse-cs.source
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Go to Windows/Preferences, then Java/Editor, tab
> "Typing", the activate
> "Insert spaces for tabs".
>
Done.
> Also, get the Eclipse plug-in for Checkstyle:
> http://eclipse-cs.sourceforge.net/
>
Done, but...
> Helps you keep in line with cod
Go to Windows/Preferences, then Java/Editor, tab "Typing", the activate
"Insert spaces for tabs".
Also, get the Eclipse plug-in for Checkstyle:
http://eclipse-cs.sourceforge.net/
Helps you keep in line with code conventions. For example, it shows you
any occurence of a tab character in the code
Oops, thanks. I've just recently switched to Eclipse
(from JEdit) and haven't been able to completely turn
them off yet.
(BTW, with Eclipse, is there a way that, even if I
*do* hit the tab character key, four spaces will be
substituted instead? There's a couple of places where
I can turn of ta
75 matches
Mail list logo
