FOText: Several obsolete methods?

[Jeremias Maerki <de...@greenmail.ch>]

I've just stumbled upon these two methods in FOText:

createBlockPointers()
getPrevFOTextThisBlock()
getNextFOTextThisBlock()
getAncestorBlock()

The latter three are never referenced. I assume these could be removed?

Jeremias Maerki

Re: Consolidating LayoutManager's and AbstractBreaker's getNextKnuthElements() methods

[Glen Mazza <gm...@apache.org>]

Jeremias Maerki wrote:

>Given that the EOL phase for 1.3.1 ends March 2006 [1][2] and given
>FOP's estimated time for the next serious release JDK 1.3 compatibility
>may really be no big concern. But I know that many people (mostly
>running server applications) are still stuck with JDK 1.3 we would do
>them a disservice by requiring 1.4 too soon. But leave the JDK 1.3
>compatibility to me.
>
>[1] http://java.sun.com/j2se/1.3/download.html
>[2] Interesting enough is the fact that the last maintenance release
>(1.3.1_15) for JDK 1.3.1 dates back to December 2004. Quite recent,
>don't you think?
>
>  
>

Yes, indeed quite recent--I did not know it was still being maintained 
by Sun.  I won't revisit this issue until March 2006 at the earliest then.

(Very detailed response, BTW.  You seem to know a thing or two about 
Java...  ;-)

Glen

Re: Consolidating LayoutManager's and AbstractBreaker's getNextKnuthElements() methods

[Jeremias Maerki <de...@greenmail.ch>]

On 29.05.2005 08:13:13 Glen Mazza wrote:
<snip/>

> Excellent!  This is exactly what I'm looking for--with this 
> architecture, the LM's gNKE() are to handle getting the Knuth elements 
> for their FO's, while the Breaker gNKE() are to handle routing between 
> various LM's gNKE() methods.  I hope to comment the code soon to make 
> that clarification so others are aware.

Thanks for that!


> >>-- I'll happily do so if I'm correct here.
> >>    
> >>
> >
> >I bet. I can only say it again. My priorities are getting FOP into a
> >releasable state. You won't get a medal from my by gilding our code
> >right now. What FOP really needs right now is finally getting to an
> >initial developer release. I doesn't have to be perfect but it has to
> >show our users that the long waiting period was worth waiting for. I
> >strongly believe that once we have an initial release, people will start
> >coming back, trying it out and we will see more people contributing. I
> >really, really, really wish you would channel your energy towards this
> >goal, too.
> >
> >  
> >
> 
> My energies right now are only in understanding layout, and in finding 
> and making changes that will make it easier for others to understand it 
> as well.

But maybe less so if the stuff changes the whole time and sometimes
changes back. What helped me a lot to understand how layout works was to
implement new features and fixing problems, real problems, by writing
test cases and observing the results.

> Users/Release dates, etc. are not my concern.

That's what I was afraid of.

> I'll be doing 
> the same work before FOP's release that I will be doing after its release.
> 
> BTW, are we losing potential committers due to FOP 1.0 supporting JDK 
> 1.3?

Committers? Probably not. Users? Possibly. There are still a significant
number of platforms, especially server platforms, that still don't have
a JDK 1.4.

>  We haven't heard much from Renaud since you asked him to maintain 
> some special 1.3-only graphics package that we otherwise wouldn't need 
> to have.  I want to make sure we didn't lose him to a 1.4/1.5 project 
> because he couldn't afford to hurt his skill sets by working on 1.3.  If 
> we did, IMO it would be better for the 1.3 users to stay on 0.20.5 so 
> the 1.4 users can have the benefits of new contributors' work in 1.0.

We don't lose Renaud because of the necessity to support JDK 1.3. He's
currently in the process of starting a new job and didn't have much time
to finish the patch he started working on. At least that was what I
interpreted when I last talked to him on the phone recently. But we're
assuming too much and know little. So far, he's done a fine job and
there are simply a few details still to be handled. This has absolutely
no relation to our discussion whether we should support JDK 1.3 or not.
If Renaud finds himself unable to complete the Java2DRenderer & Co. or
if I need the stuff a little sooner (for testing purposes) I'm going to
ask him to post what he has and I'm going to finish his work. Renaud can
spend as much time on FOP as he likes and is able to spend.

> Your comment on channelling energy is what reminded me of this.  
> AntennaHouse is requiring 1.4.2+.  So the time that we're spending on 
> that 1.3 graphics package they are presumably spending on speeding up 
> their SW for their (Windows, Linux, HP, Solaris) user base.  Are they 
> doing a better job of channelling energy than we are?  Are they doing a 
> better job of determining which users to concentrate on?

That's a weak argument since this particular item is rather a no-brainer
to handle. I haven't checked lately, but I think FOP hasn't compiled under
JDK 1.3 for a rather long time now. But this is still on my long-term
task list for FOP and until there was a user poll and a vote, I regard
FOP as being JDK 1.3 compatible even if it means that you don't get full
functionality (all bitmaps types or renderers supported and things like
that). And I know now that you don't care about FOP's users, but I do.

AntennaHouse took a decision for themselves by requiring 1.4.2+. That's
ok but it doesn't mean that FOP necessarily has to do the same. Cocoon
for example is still JDK 1.3+ but that also has no consequence for FOP.
JDK 1.3 and 1.4 are not as far apart from each as 1.4 is from 1.5/5.0. I
don't think there's a lot of pain involved in keeping 1.3 compatibility.
Given that the EOL phase for 1.3.1 ends March 2006 [1][2] and given
FOP's estimated time for the next serious release JDK 1.3 compatibility
may really be no big concern. But I know that many people (mostly
running server applications) are still stuck with JDK 1.3 we would do
them a disservice by requiring 1.4 too soon. But leave the JDK 1.3
compatibility to me.

[1] http://java.sun.com/j2se/1.3/download.html
[2] Interesting enough is the fact that the last maintenance release
(1.3.1_15) for JDK 1.3.1 dates back to December 2004. Quite recent,
don't you think?

Jeremias Maerki

Re: Consolidating LayoutManager's and AbstractBreaker's getNextKnuthElements() methods

[Glen Mazza <gr...@verizon.net>]

----- Original Message ----- 
>
> I find it strange, Glen, that you dont care whether people use FOP or not.

I'm such a monster.

> You
> have worked hard on FOP over the last couple of years. Wouldnt you be
> disappointed if your work benefitted no one?
>
> Chris
>

My goals on FOP are to make XSL as open-source dominant as XSLT is, to make
paying $4-5K/server CPU as ridiculous for an XSL processor as it is
presently is for an XSLT one.  But such an architecture will take much time,
and Jeremias is welcome to release as often as he'd like--including today,
if he wants--while we get this long-term work hammered down.  But right now,
studying and learning layout is my goal.

Keep in mind, it is not just the immediate user base that matters--you also
need to please the larger corporations (IBM, Sun) and technical
organizations (W3C, OASIS and their member companies) for FOP to be
successful, and they're a little more thorough on architecture (cf. the
behavior of the Xerces and Xalan teams.)  You please the Big Boys,
everything else tends to fall in line, just as it has in the past with most
other Java/XML-based technologies.

Glen

Re: Consolidating LayoutManager's and AbstractBreaker's getNextKnuthElements() methods

[Chris Bowditch <bo...@hotmail.com>]

Glen Mazza wrote:

<snip/>

> BTW, are we losing potential committers due to FOP 1.0 supporting JDK 
> 1.3?  We haven't heard much from Renaud since you asked him to maintain 
> some special 1.3-only graphics package that we otherwise wouldn't need 
> to have.  I want to make sure we didn't lose him to a 1.4/1.5 project 
> because he couldn't afford to hurt his skill sets by working on 1.3.  If 
> we did, IMO it would be better for the 1.3 users to stay on 0.20.5 so 
> the 1.4 users can have the benefits of new contributors' work in 1.0.
> 
> Your comment on channelling energy is what reminded me of this.  
> AntennaHouse is requiring 1.4.2+.  So the time that we're spending on 
> that 1.3 graphics package they are presumably spending on speeding up 
> their SW for their (Windows, Linux, HP, Solaris) user base.  Are they 
> doing a better job of channelling energy than we are?  Are they doing a 
> better job of determining which users to concentrate on?

Dont forget that Antenna House is written in C++ with just a Java wrapper 
provided for integration purposes. So you could still use Antenna House from 
1.3 but calling their C++ program using another technique or write a JNI 
wrapper yourself.

An interesting debate on whether to keep 1.3 compatibility or not. I agree 
with Jeremias, too many platforms are stuck on ancient JDKs, so we must 
support 1.3 as a minimum.

I find it strange, Glen, that you dont care whether people use FOP or not. You 
have worked hard on FOP over the last couple of years. Wouldnt you be 
disappointed if your work benefitted no one?

Chris

Re: Consolidating LayoutManager's and AbstractBreaker's getNextKnuthElements() methods

[Glen Mazza <gm...@apache.org>]

Jeremias Maerki wrote:

>  
>
>>Three LM classes have these two "duplicate" methods:  PSLM, SCLM, and 
>>BlockContainerLayoutManager.  SCLM and BCLM I cannot tell if they are 
>>mergable--it looks doubtful to my eyes but I'm unsure, however PSLM's 
>>two implementations look somewhat strange:  for PSLM, what else would 
>>activate PSLM.gNKE() other than its PageBreaker.gNKE()?
>>    
>>
>
>Nothing.
>
>  
>
>>If "nothing", 
>>those two should be merged at least to PSLM's implementation to clarify 
>>    
>>
>
>I don't think so. AbstractBreaker subclasses' responsibility is to
>control the breaking process and thus initiate gNKE() calls on the right
>LMs. The individual LM's are simply responsible to handle their own FOs.
>  
>

Excellent!  This is exactly what I'm looking for--with this 
architecture, the LM's gNKE() are to handle getting the Knuth elements 
for their FO's, while the Breaker gNKE() are to handle routing between 
various LM's gNKE() methods.  I hope to comment the code soon to make 
that clarification so others are aware.

>  
>
>>-- I'll happily do so if I'm correct here.
>>    
>>
>
>I bet. I can only say it again. My priorities are getting FOP into a
>releasable state. You won't get a medal from my by gilding our code
>right now. What FOP really needs right now is finally getting to an
>initial developer release. I doesn't have to be perfect but it has to
>show our users that the long waiting period was worth waiting for. I
>strongly believe that once we have an initial release, people will start
>coming back, trying it out and we will see more people contributing. I
>really, really, really wish you would channel your energy towards this
>goal, too.
>
>  
>

My energies right now are only in understanding layout, and in finding 
and making changes that will make it easier for others to understand it 
as well.  Users/Release dates, etc. are not my concern.  I'll be doing 
the same work before FOP's release that I will be doing after its release.

BTW, are we losing potential committers due to FOP 1.0 supporting JDK 
1.3?  We haven't heard much from Renaud since you asked him to maintain 
some special 1.3-only graphics package that we otherwise wouldn't need 
to have.  I want to make sure we didn't lose him to a 1.4/1.5 project 
because he couldn't afford to hurt his skill sets by working on 1.3.  If 
we did, IMO it would be better for the 1.3 users to stay on 0.20.5 so 
the 1.4 users can have the benefits of new contributors' work in 1.0.

Your comment on channelling energy is what reminded me of this.  
AntennaHouse is requiring 1.4.2+.  So the time that we're spending on 
that 1.3 graphics package they are presumably spending on speeding up 
their SW for their (Windows, Linux, HP, Solaris) user base.  Are they 
doing a better job of channelling energy than we are?  Are they doing a 
better job of determining which users to concentrate on?

Thanks,
Glen

Re: Consolidating LayoutManager's and AbstractBreaker's getNextKnuthElements() methods

[Jeremias Maerki <de...@greenmail.ch>]

On 28.05.2005 06:46:59 Glen Mazza wrote:
> Jeremias, perhaps Luca:
> 
> Is there a reason why we maintain separate getNextKnuthElement() methods 
> within both an LayoutManager and its inner AbstractBreaker?

Looking at the code I think there is. They both have different
responsibilities. Ok, BlockContainerBreaker has the same gNKE() as
StaticContentBreaker. If you want to consolidate these two, why not.
And: it works, why change it now?

> Can they be 
> consolidated into LayoutManager and we call 
> getTopLevelLM().getNextKnuthElement() instead within the breaker code?

I don't see how this is possible.

> Three LM classes have these two "duplicate" methods:  PSLM, SCLM, and 
> BlockContainerLayoutManager.  SCLM and BCLM I cannot tell if they are 
> mergable--it looks doubtful to my eyes but I'm unsure, however PSLM's 
> two implementations look somewhat strange:  for PSLM, what else would 
> activate PSLM.gNKE() other than its PageBreaker.gNKE()?

Nothing.

> If "nothing", 
> those two should be merged at least to PSLM's implementation to clarify 

I don't think so. AbstractBreaker subclasses' responsibility is to
control the breaking process and thus initiate gNKE() calls on the right
LMs. The individual LM's are simply responsible to handle their own FOs.

> -- I'll happily do so if I'm correct here.

I bet. I can only say it again. My priorities are getting FOP into a
releasable state. You won't get a medal from my by gilding our code
right now. What FOP really needs right now is finally getting to an
initial developer release. I doesn't have to be perfect but it has to
show our users that the long waiting period was worth waiting for. I
strongly believe that once we have an initial release, people will start
coming back, trying it out and we will see more people contributing. I
really, really, really wish you would channel your energy towards this
goal, too.

Jeremias Maerki

Consolidating LayoutManager's and AbstractBreaker's getNextKnuthElements() methods

[Glen Mazza <gm...@apache.org>]

Jeremias, perhaps Luca:

Is there a reason why we maintain separate getNextKnuthElement() methods 
within both an LayoutManager and its inner AbstractBreaker?  Can they be 
consolidated into LayoutManager and we call 
getTopLevelLM().getNextKnuthElement() instead within the breaker code?

Three LM classes have these two "duplicate" methods:  PSLM, SCLM, and 
BlockContainerLayoutManager.  SCLM and BCLM I cannot tell if they are 
mergable--it looks doubtful to my eyes but I'm unsure, however PSLM's 
two implementations look somewhat strange:  for PSLM, what else would 
activate PSLM.gNKE() other than its PageBreaker.gNKE()?  If "nothing", 
those two should be merged at least to PSLM's implementation to clarify 
-- I'll happily do so if I'm correct here.

Thanks,
Glen

Re: FOText: Several obsolete methods?

[Jeremias Maerki <de...@greenmail.ch>]

Victor,

thanks for digging this up. It actually surprises me and on the other
side still leaves me wondering what to choose. You could say the wrong
interpretation is more what a user would expect, and the right
interpretation is more right. :-) Interesting to note is that a XEP
trial does it "wrong" and an AltSoft trial does it "right".

I'll have a look if I can change the bahaviour.

On 27.05.2005 17:17:54 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > I see. Thanks for answering! Just to see what the current 
> > code does, I've written two testcases. It turns out that the 
> > issue you were working on has already been fixed in the 
> > meantime, provided I'm testing correctly. So I guess I'll 
> > remove these methods.
> 
> WRT text-transform2.xml, you might want to look at this comment from Paul
> Grosso:
> http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0006.html
> 
> It looks like your test case for text-transform="capitalize" assumes exactly
> as he has documented there, i.e. that non-initial characters should be
> converted to lowercase. That appears now to be incorrect, but it should be
> any easy thing to fix. I was probably the one that implemented it that way
> in the first place. I thought it might be easier for you to fix now, while
> fresh in memory, than later.
> 
> Victor Mote



Jeremias Maerki

RE: FOText: Several obsolete methods?

[Victor Mote <vi...@outfitr.com>]

Jeremias Maerki wrote:

> I see. Thanks for answering! Just to see what the current 
> code does, I've written two testcases. It turns out that the 
> issue you were working on has already been fixed in the 
> meantime, provided I'm testing correctly. So I guess I'll 
> remove these methods.

WRT text-transform2.xml, you might want to look at this comment from Paul
Grosso:
http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0006.html

It looks like your test case for text-transform="capitalize" assumes exactly
as he has documented there, i.e. that non-initial characters should be
converted to lowercase. That appears now to be incorrect, but it should be
any easy thing to fix. I was probably the one that implemented it that way
in the first place. I thought it might be easier for you to fix now, while
fresh in memory, than later.

Victor Mote

Re: FOText: Several obsolete methods?

[Jeremias Maerki <de...@greenmail.ch>]

I see. Thanks for answering! Just to see what the current code does,
I've written two testcases. It turns out that the issue you were working
on has already been fixed in the meantime, provided I'm testing
correctly. So I guess I'll remove these methods.

On 27.05.2005 15:38:15 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > I've just stumbled upon these two methods in FOText:
> > 
> > createBlockPointers()
> > getPrevFOTextThisBlock()
> > getNextFOTextThisBlock()
> > getAncestorBlock()
> > 
> > The latter three are never referenced. I assume these could 
> > be removed?
> 
> I think these were methods that I added at one time to deal with
> text-transform="capitalize", the idea being to link together the contiguous
> text within a given block but within different FOs. IIRC, I had this working
> in HEAD at one time. If the above methods are not being used, then that
> feature has probably either been removed or implemented another way. My
> implementation was an ugly static-ish hack that resulted from some design
> problems, and I am sure it is no great loss if it has been removed. I
> obviously have no objection to you removing those methods. Here is the
> message that I wrote when I left the project that documents some of this:
> http://marc.theaimsgroup.com/?l=fop-dev&m=107199000718911&w=2
> so you might look for the related static variable as well.
> 
> Victor Mote



Jeremias Maerki

RE: FOText: Several obsolete methods?

[Victor Mote <vi...@outfitr.com>]

Jeremias Maerki wrote:

> I've just stumbled upon these two methods in FOText:
> 
> createBlockPointers()
> getPrevFOTextThisBlock()
> getNextFOTextThisBlock()
> getAncestorBlock()
> 
> The latter three are never referenced. I assume these could 
> be removed?

I think these were methods that I added at one time to deal with
text-transform="capitalize", the idea being to link together the contiguous
text within a given block but within different FOs. IIRC, I had this working
in HEAD at one time. If the above methods are not being used, then that
feature has probably either been removed or implemented another way. My
implementation was an ugly static-ish hack that resulted from some design
problems, and I am sure it is no great loss if it has been removed. I
obviously have no objection to you removing those methods. Here is the
message that I wrote when I left the project that documents some of this:
http://marc.theaimsgroup.com/?l=fop-dev&m=107199000718911&w=2
so you might look for the related static variable as well.

Victor Mote