Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Glen Mazza]

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 
functionality.)  I'd like us to try it and see what happens for a while, 
we can easily move it back if it's a disaster.   Groovy things may 
happen that I can't predict right now.


[As an aside, fo:flow and fo:static-content are of course both 
considered flows by the spec.  For that reason, I think we might end up 
having both StaticContentLayoutManager and FLM extend a new 
AbstractFlowLayoutManager class (which will in turn extend whatever SCLM 
and FLM currently extend--BlockStackingLayoutManager I think.) Right 
now, it would just have a getPSLM() method in common--but perhaps more 
will come into it over time.]


As for the change you mention, you may have misunderstood my concern.  
It is most fine and fantastic if the Breaking code needs the PSLM *as* a 
PSLM--whatever the processing calls for--I'm just leery of having it 
need PSLM *as a LayoutManager* in particular.  Something like PSLM 
getPSLM() and not LayoutManager getPSLM().  I.e., I would like PSLM to 
be able to implement (or not implement) any of 50 different things, and 
still have the breaking code work fine with it.


Your code looks good.  Go ahead and promote PageViewportProvider if you 
like (no, not my taste, but you code your way and I'll code mine. ;-) I 
might recommend though, as above, having the method 
getPageViewportProvider() be kept within the PSLM, not the PSLM's 
PageBreaker.  I'd like to keep things a little less restrictive right 
now as some code may move back and forth, and so letting the Breaker 
code have a PSLM may be useful at this time--so instead we could have a 
PageBreaker.getPSLM(), and from there let the AbstractBreaker code call 
pslm.getPageViewportProvider().


[Another option, given that getTopLevelLM() up until now isn't doing 
anything, is just returning the childFLM object from PageBreaker's 
getTopLevelLM(), and then calling childFLM.getPSLM() from that.  This 
has the elegance of allowing access to the PSLM from StaticContentLM's 
Breaker inner class as well (getTopLevelLM().getPSLM()) and other 
breaker objects.  This change would also better give us the option of 
moving PageBreaker to FLM (akin to its sibling SCLM -- albeit with 
functions back to PSLM to get the separator areas) should it end up 
making more sense.]


Many thanks,
Glen


Jeremias Maerki wrote:


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 route and made the PageViewportProvider available differently.
I hope that was acceptable and still as clean as possible. I was also
thinking about promoting the PageViewportProvider in PSLM to a full
class. But I left it out for now.

 

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Jeremias Maerki]

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 route and made the PageViewportProvider available differently.
I hope that was acceptable and still as clean as possible. I was also
thinking about promoting the PageViewportProvider in PSLM to a full
class. But I left it out for now.

On 14.06.2005 04:54:09 gmazza wrote:
> gmazza  2005/06/13 19:54:09
> 
>   Modified:src/java/org/apache/fop/layoutmgr
> PageSequenceLayoutManager.java
>   Log:
>   Switched to null for PageBreaker.getTopLevelLM().
>   Not being used by the page-breaking process.
>   
>   Revision  ChangesPath
>   1.67  +2 -2  
> xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
>   
>   Index: PageSequenceLayoutManager.java
>   ===
>   RCS file: 
> /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java,v
>   retrieving revision 1.66
>   retrieving revision 1.67
>   diff -u -r1.66 -r1.67
>   --- PageSequenceLayoutManager.java  9 Jun 2005 02:39:55 -   1.66
>   +++ PageSequenceLayoutManager.java  14 Jun 2005 02:54:09 -  1.67
>   @@ -157,7 +157,7 @@
>}
>
>protected LayoutManager getTopLevelLM() {
>   -return pslm;
>   +return null;  // unneeded for PSLM
>}
>
>protected LinkedList getNextKnuthElements(LayoutContext context, 
> int alignment) {


Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Glen Mazza]

[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 work currently anyway.)
 
 

Correction: *don't* work.

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[The Web Maestro]

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', got my modal verbs mixed up again :-)
Thanks for the translation. Am I the only non-german speaking 
committer on the FOP project?!?

Chris
No... and you're quite right, that 'official' FOP business should be in 
English. But niceties tend to go back and forth in this group, and I 
don't mind. It adds a bit of spice IMHO.

In any case, I tend to use Babelfish or Google's Language Tools when I 
come across something I don't completely understand... In addition, I 
wrote it off as not really being important, as it was written in 
German. I don't say that to be particularly snobbish... but if it were 
important, I figured it would've been in English.

Regards,
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Chris Bowditch]

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 for the translation. Am I the only non-german speaking committer on the 
FOP project?!?

Chris

RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Andreas L. Delmelle]

> -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,

Andreas

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Jeremias Maerki]

> 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.
> >>  
> >>
> > 
> > Kein Problem.  Bald werde ich dass machen, aber nicht dieser Nacht, weil 
> > ich ziemlich muede bin.

English: No problem. I'll do that soon, but not tonight because I'm
rather tired.

> >> handleBreak does really handle break-before AND break-after, so the name
> >> was ok.
> > 
> > 
> > Ja, Sie haben Recht.  Leider habe ich nur die ehemalige 
> > PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen, 
> > dass "break-before" die einzel Benutzung war.

English: Yes, you're right. I'm afraid I've read but the former
PSLM.prepareNormalFlowArea(), and erroneously assumed that only "break-before"
was used.

> >> What can be is that there is some left-over code from the
> >> previous approach.
> > 
> > 
> > Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen.  
> > Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht 
> > nur 560 LVK sein!

English: Yes, we should remove the old code now. Last January, PSLM was
about 930 lines of code, but soon it'll be but 560!


Jeremias Maerki

RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Andreas L. Delmelle]

> -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 quite tired."

> > Ja, Sie haben Recht.  Leider habe ich nur die ehemalige
> > PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen,
> > dass "break-before" die einzel Benutzung war.

(I think it should be 'gelernt' here... but ok, Glen was tired :-) )

"Yes, you're right. Unfortunately, I've only read the former
PSLM.prepareNormalFlowArea(), and inferred from there that "break-before"
was the only use."


> > Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen.
> > Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht
> > nur 560 LVK sein!

"Yes, and now we will remove the older code (pNFA() etc.). Last January,
PSLM was about 930 LOC, but soon there will be only 560 LOC left!"


Cheers,

Andreas

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Chris Bowditch]

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.

Ja, Sie haben Recht.  Leider habe ich nur die ehemalige 
PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen, 
dass "break-before" die einzel Benutzung war.

What can be is that there is some left-over code from the
previous approach.

Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen.  
Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht 
nur 560 LVK sein!
Jeremias/Glen:
could you translate this for me? Sorry but I dont speak German!
Chris
Danke,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Glen Mazza]

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 Recht.  Leider habe ich nur die ehemalige 
PSLM.prepareNormalFlowArea() gelesen, und von da irrtumlich gelernen, 
dass "break-before" die einzel Benutzung war.

What can be is that there is some left-over code from the
previous approach. 

Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen.  
Letztes Januar war PSLM ungefaehr 930 LVK, aber bald wird es vielleicht 
nur 560 LVK sein!

Danke,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Jeremias Maerki]

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 anymore because this is already handled during the
creation of element lists. Break-before and break-after are normalized
to the startOn value held by BlockSequence.

On 05.05.2005 06:54:08 gmazza wrote:
> gmazza  2005/05/04 21:54:08
> 
>   Modified:src/java/org/apache/fop/layoutmgr Tag:
> Temp_KnuthStylePageBreaking
> PageSequenceLayoutManager.java
>   Log:
>   More clarifications to PSLM.
>   
>   Revision  ChangesPath
>   No   revision
>   No   revision
>   1.50.2.22 +33 -34
> xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
>   
>   Index: PageSequenceLayoutManager.java
>   ===
>   RCS file: 
> /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java,v

>   -// otherwise, we simply need a new page
>   -handleBreak(bIsFirstPage ? list.getStartOn() : 
> Constants.EN_PAGE);
>   +// otherwise, we may simply need a new page
>   +handleBreakBefore(bIsFirstPage ? list.getStartOn() 
> : Constants.EN_PAGE);




Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Glen Mazza]

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 (our pluggable
LM's allowing for a different PSLMs to be used). 
Also, CB will most probably have
interactive/corresponding effects with other Spans
and/or pages--another signal that this is PSLM's
responsibility.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 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 with the Knuth approach this can't even
> be done otherwise. I
> don't know what the others think.
> 
> On 30.03.2005 02:49:08 Glen Mazza wrote:
> > 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], with the remaining few lines of
> > createPageAreas() moved to makeNewPage().  
> > 
> > This is all boilerplate routine setup--predefined
> > margin widths, etc-- independent of layout
> mechanisms,
> > and I suspect this work can be more cleanly and
> > orderly implemented in area.PageViewport anyway.
> > 
> > Replacing this logic in PSLM eventually will be
> more
> > flow-mapping logic, both of the future fo:flow-map
> and
> > even our current 1.0 requirements to be able to
> place
> > fo:flow data into any of the region areas. 
> (Perhaps
> > the column balancing as well, if the Span object
> > cannot handle it by itself.)  This is more of
> PSLM's
> > responsibilities, and it will be quite large
> enough in
> > accomplishing all of them.  But PSLM should more
> or
> > less be able to just call curPage = new
> > PageViewport(), and get a PageViewport with
> already
> > initialized child region areas.  The coding to
> create
> > this IMHO will be a distraction if kept in PSLM.
> > 
> > Any objections?
> > 
> > Thanks,
> > Glen
> > 
> > [1] http://tinyurl.com/4qca3
> > 
> > --- [EMAIL PROTECTED] wrote:
> > >
> > > gmazza  2005/03/29 16:06:30
> > > 
> > >   Modified:src/java/org/apache/fop/area Tag:
> > >
> Temp_KnuthStylePageBreaking
> > > PageViewport.java
> > >src/java/org/apache/fop/layoutmgr
> > > Tag:
> > >
> Temp_KnuthStylePageBreaking
> > >
> > > PageSequenceLayoutManager.java
> > >   Log:
> > >   Removed the curSpan instance variable -- now
> > > obtainable via curPage.
> > >   
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Jeremias Maerki]

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 with the Knuth approach this can't even be done otherwise. I
don't know what the others think.

On 30.03.2005 02:49:08 Glen Mazza wrote:
> 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], with the remaining few lines of
> createPageAreas() moved to makeNewPage().  
> 
> This is all boilerplate routine setup--predefined
> margin widths, etc-- independent of layout mechanisms,
> and I suspect this work can be more cleanly and
> orderly implemented in area.PageViewport anyway.
> 
> Replacing this logic in PSLM eventually will be more
> flow-mapping logic, both of the future fo:flow-map and
> even our current 1.0 requirements to be able to place
> fo:flow data into any of the region areas.  (Perhaps
> the column balancing as well, if the Span object
> cannot handle it by itself.)  This is more of PSLM's
> responsibilities, and it will be quite large enough in
> accomplishing all of them.  But PSLM should more or
> less be able to just call curPage = new
> PageViewport(), and get a PageViewport with already
> initialized child region areas.  The coding to create
> this IMHO will be a distraction if kept in PSLM.
> 
> Any objections?
> 
> Thanks,
> Glen
> 
> [1] http://tinyurl.com/4qca3
> 
> --- [EMAIL PROTECTED] wrote:
> >
> > gmazza  2005/03/29 16:06:30
> > 
> >   Modified:src/java/org/apache/fop/area Tag:
> > Temp_KnuthStylePageBreaking
> > PageViewport.java
> >src/java/org/apache/fop/layoutmgr
> > Tag:
> > Temp_KnuthStylePageBreaking
> >
> > PageSequenceLayoutManager.java
> >   Log:
> >   Removed the curSpan instance variable -- now
> > obtainable via curPage.
> >   



Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Glen Mazza]

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], with the remaining few lines of
createPageAreas() moved to makeNewPage().  

This is all boilerplate routine setup--predefined
margin widths, etc-- independent of layout mechanisms,
and I suspect this work can be more cleanly and
orderly implemented in area.PageViewport anyway.

Replacing this logic in PSLM eventually will be more
flow-mapping logic, both of the future fo:flow-map and
even our current 1.0 requirements to be able to place
fo:flow data into any of the region areas.  (Perhaps
the column balancing as well, if the Span object
cannot handle it by itself.)  This is more of PSLM's
responsibilities, and it will be quite large enough in
accomplishing all of them.  But PSLM should more or
less be able to just call curPage = new
PageViewport(), and get a PageViewport with already
initialized child region areas.  The coding to create
this IMHO will be a distraction if kept in PSLM.

Any objections?

Thanks,
Glen

[1] http://tinyurl.com/4qca3

--- [EMAIL PROTECTED] wrote:
>
> gmazza  2005/03/29 16:06:30
> 
>   Modified:src/java/org/apache/fop/area Tag:
> Temp_KnuthStylePageBreaking
> PageViewport.java
>src/java/org/apache/fop/layoutmgr
> Tag:
> Temp_KnuthStylePageBreaking
>
> PageSequenceLayoutManager.java
>   Log:
>   Removed the curSpan instance variable -- now
> obtainable via curPage.
>   

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java StaticContentLayoutManager.java

[Glen Mazza]

--- 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 SideRegion instead (e.g., if the
fo:flow is given a flow-name of "xsl-region-before".) 

> Are there any layoutengine
> tests that you could
> write to illustrate this?

No we don't support this functionality yet, but once
we  do, we will be in better conformance with the 1.0
spec and in much better shape for the upcoming XSL 1.1
fo:flow-map.  I don't see it as much affecting the
work right now--there isn't much coding difference
between the regions (all have ipd, bpd, etc. to
populate content), outside of the fact that
fo:region-body can also have columns.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java StaticContentLayoutManager.java

[Jeremias Maerki]

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?  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
> exception if the fo:page-sequence's fo:flow is not
> directed to the fo:region-body, but actually I don't
> think there is anything wrong with that.)  I can make
> the change IIC here.
> 
> Thanks,
> Glen
> 
> --- [EMAIL PROTECTED] wrote:
> >private void layoutStaticContent(int
> > regionID) {
> >   -Region reg =
> > currentSimplePageMaster.getRegion(regionID);
> >   +RegionOuter reg =
> >
> (RegionOuter)currentSimplePageMaster.getRegion(regionID);



Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java StaticContentLayoutManager.java

[Glen Mazza]

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
exception if the fo:page-sequence's fo:flow is not
directed to the fo:region-body, but actually I don't
think there is anything wrong with that.)  I can make
the change IIC here.

Thanks,
Glen

--- [EMAIL PROTECTED] wrote:
>private void layoutStaticContent(int
> regionID) {
>   -Region reg =
> currentSimplePageMaster.getRegion(regionID);
>   +RegionOuter reg =
>
(RegionOuter)currentSimplePageMaster.getRegion(regionID);

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Glen Mazza]

--- 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 code conventions. For
> example, it shows you
> any occurence of a tab character in the code base.
> That's how I find
> these so fast.
> 

1.) Are you defining these rules manually within
Eclipse?  I can do that, also I can get the default
"Sun Checks" working within the IDE, but when I
attempt to import our checkstyle3.1.1-head file it is
failing (needs a DTD for validation).

2.) More generally, all three checkstyle files
("checkstyle.cfg", "checkstyle.header", and
"checkstyle3.1.1-head") we have in the FOP HEAD root
directory don't seem to work with the new checkstyle
3.5 download.  One of them is a .properties file (not
an XML file that checkstyle wants), the other lacks a
DTD and hence fails on validation (although the DTD
for 3.5 appears radically different than the 3.1.1
XML), and the third appears to be nothing but a copy
of the Apache license.  Is anyone still using these? 
Else, I'll drop them, put them in the attic for
someone to recreate with the new 3.5 DTD whenever
desired.  Unless I'm misunderstanding things here, I
wouldn't want anyone else to be confused that these
three files have any relevance to modern versions of
Checkstyle.

Thanks,
Glen



> On 13.03.2005 18:29:48 Glen Mazza wrote:
> > 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 tabbing when Eclipse is doing the
> > indentation, but AFAICT not when I hit the tab key
> > myself.)
> > 
> > Thanks,
> > Glen
> > 
> > 
> > --- [EMAIL PROTECTED] wrote:
> > > jeremias2005/03/13 02:52:28
> > > 
> > >   Modified:src/java/org/apache/fop/layoutmgr
> > >
> > > PageSequenceLayoutManager.java
> > >   Log:
> > >   Removing illegal tab characters.
> > >   
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Jeremias Maerki]

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 base. That's how I find
these so fast.

On 13.03.2005 18:29:48 Glen Mazza wrote:
> 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 tabbing when Eclipse is doing the
> indentation, but AFAICT not when I hit the tab key
> myself.)
> 
> Thanks,
> Glen
> 
> 
> --- [EMAIL PROTECTED] wrote:
> > jeremias2005/03/13 02:52:28
> > 
> >   Modified:src/java/org/apache/fop/layoutmgr
> >
> > PageSequenceLayoutManager.java
> >   Log:
> >   Removing illegal tab characters.
> >   



Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

[Glen Mazza]

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 tabbing when Eclipse is doing the
indentation, but AFAICT not when I hit the tab key
myself.)

Thanks,
Glen


--- [EMAIL PROTECTED] wrote:
> jeremias2005/03/13 02:52:28
> 
>   Modified:src/java/org/apache/fop/layoutmgr
>
> PageSequenceLayoutManager.java
>   Log:
>   Removing illegal tab characters.
>