Re: Sources for layout.jpg

[Glen Mazza]

--- The Web Maestro <[EMAIL PROTECTED]> wrote:
>
> Does anyone have any objections to my making these
> files LIVE on the 
> FOP site (and replacing the current "document.jpg"
> image on the home 
> page)? 
>

None whatsoever, but I'm going to act like I do in
order to get something I want in exchange...

No way, Clay!  Not unless you refresh the team page so
my change adding Renaud as a contributor appears!!!

Thanks,
Glen

Re: master-reference '' for fo:page-sequence matches no simple-page-master or page-sequence-master

[Glen Mazza]

Quite happy to.  Done.

Glen

--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> Glen,
> 
> On Wed, Mar 09, 2005 at 11:34:29AM -0800, Glen Mazza
> wrote:
> > The property on
> fo:conditional-page-master-reference
> > should be "master-reference", not "master-name"
> [1].
> 
> I had this problem too the other day. Can you not
> throw some
> validation towards detecting a missing
> master-reference attribute? The
> idea that FOP goes searching for an empty
> master-reference name is not
> quite satisfactory.
> 
> Regards, Simon
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.nl
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> RFC 2045 [1] says this:
> > (1)   Private values (starting with "X-") may be
> defined
> >   bilaterally between two cooperating
> agents without
> >   outside registration or standardization.
> Such values
> >   cannot be registered or standardized.
> 
> So to be on the safe side we would need to rename
> "application/awt" to
> "application/X-awt".
> 

Sounds good--and acceptable for purists as well.

Glen


> [1] http://www.faqs.org/rfcs/rfc2045.html
> 

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> Ah, there's the catch. Yes, CCITT4 is particularly
> interesting which is
> not supported by the code in Batik. But still, I
> think we don't have to

I don't think we have to

> support everything under JDK 1.3. 

Or anything, for that matter.  1.3 users can remain on
0.20.5 IMO, optionally downloading Oleg's TIFF patch
if they need to.  

Glen

Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > > Otherwise, I'd rather use ImageIO even if it's
> only available in JDKs
> > > >=1.4.
> > I thought FOP should be 1.3 compilant [3]? So how
> do we go around that?
> 
> That's right. But nothing stops us from providing
> additional code that's
> JDK 1.4 dependent as long as it's not core
> functionality and it's in a
> separate directory (src/java-1.4).
> 

BTW, does it have to be in a separate directory?  Can
we keep it in the directory it would otherwise be in
if FOP were 1.4-based but somehow alter the Ant
scripts to help the 1.3-only users?

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

[Glen Mazza]

The "application/awt" MIME type doesn't exist.  I
think Jeremias wanted this to be null instead for
output types that lack a MIME type, correct?

Thanks,
Glen

--- [EMAIL PROTECTED] wrote:
>
>   +/** The MIME type for AWT-Rendering */
>public static final String MIME_TYPE =
> "application/awt";
>

Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

Yeah, Peter makes me want to do that sometimes
myself...  ;)

Glen

--- vivek gupta <[EMAIL PROTECTED]> wrote:

> How to leave this group. Please help me to
> unsubscribe.
> 
> 
> 
> --- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> > Renaud Richardet wrote:
> > > Oleg,
> > > 
> > > I'm currently working on the AWTRenderer. The
> > basic idea is to create
> > > a Java2DRenderer which provides the (abstract)
> > technical foundation.
> > > Other renderers can subclass Java2DRenderer and
> > provide the concrete
> > > output paths [1].
> > > 
> > > I think it would be a good idea to integrate
> your
> > TIFFRenderer, as you
> > > propose in [2]. Would you like to integrate it
> > yourself? Otherwise I
> > > would like to do it.
> > > 
> > > Regards,
> > > Renaud
> > > 
> > > [1]
> >
> http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> > > [2] http://www.tkachenko.com/fop/fop.html
> > 
> > Renaud,
> > 
> > This approach is obviously of interest to me, and
> I
> > will follow 
> > developments closely.  The wiki page is very
> > general.  If the 
> > Java2DRenderer is to be the "(abstract) technical
> > foundation", what will 
> > the relationship to the concrete PDF renderer be? 
> > The wiki is vague on 
> > this point.
> > 
> > Peter
> > -- 
> > Peter B. West 
> > Folio 
> > 
> > 
> 
> 
>   
>   
> __ 
> Celebrate Yahoo!'s 10th Birthday! 
> Yahoo! Netrospective: 100 Moments of the Web 
> http://birthday.yahoo.com/netrospective/
> 

Good job! / Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

Team,

Oleg's TIFF Renderer is under the Mozilla license[1],
not the Apache one (also apparently some of the code
is from Sun?).  Is the former compatible with the
latter?  If not, I would like Oleg to switch the
license on it before we proceed further in putting it
into FOP.

Renaud--thanks for your fantastic work with the AWT
Renderer.  You clearly have ace technical skills,
enthusiasm, organization, and you write beautifully. 
You have a bright future ahead of you.

[Thanks also to Bertrand for sending Renaud our way. 
This is the second quality developer--Peter Herweg
being the other--that we have gotten from him since
I've been on this project.]

Regards,
Glen

[1] http://www.tkachenko.com/fop/tiffrenderer.html


--- Renaud Richardet <[EMAIL PROTECTED]>
wrote:

> Oleg,
> 
> I'm currently working on the AWTRenderer. The basic
> idea is to create
> a Java2DRenderer which provides the (abstract)
> technical foundation.
> Other renderers can subclass Java2DRenderer and
> provide the concrete
> output paths [1].
> 
> I think it would be a good idea to integrate your
> TIFFRenderer, as you
> propose in [2]. Would you like to integrate it
> yourself? Otherwise I
> would like to do it.
> 
> Regards,
> Renaud
> 
> [1]
> http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> [2] http://www.tkachenko.com/fop/fop.html
> 

Re: FOP at ApacheCon Europe 2005?

[Glen Mazza]

Fantastic!  I hope to be able to do the same someday.

Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> FYI, I've just given myself a shove, followed
> Bertrand's suggestion and
> submitted a session proposal for ApacheCon. I feel
> that our project
> should be present there. I was also thinking about
> something like
> "hidden treasures in the XML Graphics project" but I
> guess there's not
> so much meat on that bone to fill one hour.
> 
> > ApacheCon Europe 2005 CFP submission
> > 
> > Submitter: Jeremias Maerki <[EMAIL PROTECTED]>
> > Title: Apache FOP: Optimizing speed and memory
> consumption
> > Level: Experienced
> > Style: 
> > Orientation: Developer
> > Duration: 60
> > Categories: 
> > Abstract:
> > 
> > Apache FOP is the most popular XSL-FO
> implementation on the
> > market. It is used in a wide variety of use cases
> to create documents
> > in PDF, PostScript and other formats. This session
> will show a
> > number of techniques to improve processing speed
> and and hints on how
> > to handle things like OutOfMemoryErrors. It will
> also contain a
> > short info block about the state and the future of
> the project.
> > 
> 
> 
> 
> On 12.02.2005 10:57:15 Bertrand Delacretaz wrote:
> > Le 8 févr. 05, à 19:29, Jeremias Maerki a écrit :
> > 
> > > Most of you will probably have heard that
> ApacheCon Europe will be 
> > > happening in
> > > July. I think it would be great if FOP would
> somehow be visible there.
> > > There's a call for participation ending
> 2005-03-04. Any ideas?
> > 
> > A recurring question in my consulting work is "is
> FOP fast or what?" or 
> > more precisely "how to tune XSL-FO for FOP to run
> efficiently", mostly 
> > in view of avoiding memory bottlenecks.
> > 
> > Me, I'm not using FOP hands-on enough these days
> to answer very 
> > precisely, I usually just tell them to test their
> performance on large 
> > documents very regularly during development, to
> avoid surprises.
> > 
> > But maybe one of you FOP gurus could give a
> presentation with more 
> > precise information about this?
> > 
> > Just my 2 cents.
> > 
> > -Bertrand
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

[Glen Mazza]

Happy to see how you have reprioritized your efforts
over the past two months [1], and much, much for the
better.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> I very much hope so. But it becomes more and more
> apparent that this
> will be the greatest challenge in my programmer's
> life. Wow indeed.
> 
> 
> Jeremias Maerki
> 
> 

[1] http://marc.theaimsgroup.com/?l=fop-dev&m=110495579414655&w=2

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java

[Glen Mazza]

Thanks Simon.

Glen

--- [EMAIL PROTECTED] wrote:
>
> spepping2005/03/02 13:03:25
> 
>   Modified:src/java/org/apache/fop/fo/flow
> TableBody.java
> TableFooter.java
>   Log:
>   Corrected a validation problem. Made TableFooter
> use TableBody's validation.
>   

Re: page-breaking strategies and performance

[Glen Mazza]

Yes, I'm not in Simon's league here--I know very
little about TeX--so I'll defer to you two on this
issue.  Just try to make sure that the final algorithm
will help us support the keep-* properties.

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Thanks. I think this has only to do with the rules
> to handle keeps and
> breaks and how to resolve conflicts. I don't think,
> however, that these
> parts create a restriction which tells us what
> page-breaking strategy to
> pursue. We could probably run with a first-fit
> strategy and still
> fulfill the rules below if we accept a lot of
> backtracking. But as Simon
> suggested, this seems to be a poor approach.
> 
> Keeps and breaks are only part of what a page
> breaking algorithm has to
> deal with. See [3].
> 
> [3]
>
http://wiki.apache.org/xmlgraphics-fop/PageLayout/InfluencingFeatures
> 
> On 02.03.2005 16:44:17 Glen Mazza wrote:
> > I'm unsure here.  My interpretation comes from two
> > places: 
> > 
> > 1.) Section 4.8, the last paragraph of [1]:
> > 
> > "The area tree is constrained to satisfy all break
> > conditions imposed. ***Each keep condition must
> also
> > be satisfied***, except when this would cause a
> break
> > condition or a stronger keep condition to fail to
> be
> > satisfied."
> > 
> > i.e., keep conditions need to be satisfied.
> > 
> > 2.) The definitions of the three keep-[]
> properties
> > [2] each have a initial value of "auto", meaning
> > "There are no keep-[] conditions imposed by this
> > property."
> > 
> > So by default, if the user does not explicitly
> specify
> > keep properties, e.g.,
> "keep-together.within-page", no
> > text, pictures, etc. are to be kept together on
> the
> > same page, if they wouldn't already be so due to
> > free-flowing (i.e., first-fit) text.  Everything
> would
> > become free-flowing in order to obey the
> stylesheet
> > writer's specifications.
> > 
> > Just my $0.02.
> > 
> > Thanks,
> > Glen
> > 
> > [1]
> >
>
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak
> > 
> > [2]
> >
>
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together
> > 
> > 
> > --- Jeremias Maerki <[EMAIL PROTECTED]>
> wrote:
> > 
> > > Where did you find such a suggestion? I'd be
> > > interested to know if
> > > there's a hint in this direction in the spec. I
> > > thought it was up to the
> > > implementation to decide the strategy.
> > > 
> > > I think the way we're now taking in our
> discussion
> > > suggests that we're
> > > not going to do a first-fit strategy at all. If
> > > we're really going down
> > > the two-strategy path we'll probably end up with
> a
> > > best-fit strategy and
> > > a total-fit or best-fit plus look-ahead. (See
> > > Simon's list [1]) But
> > > that's something we still need to figure out
> > > together.
> > > 
> > 
> > If we ever have multiple page-breaking options, it
> can
> > be a user-defined configuration switch.  No
> problem
> > there.
> > 
> > Glen
> > 
> > 
> > > [1]
> > >
> http://wiki.apache.org/xmlgraphics-fop/PageLayout
> > > 
> > > On 02.03.2005 14:48:17 Glen Mazza wrote:
> > > > Just a sanity check here, the XSL
> specification
> > > seems
> > > > to suggest always the first-fit strategy for
> page
> > > > breaking *except* where keeps are explicitly
> > > > specified.  Am I correct here?  And, if so, is
> > > what
> > > > you're planning going to result in an
> algorithm
> > > that
> > > > will help us do this?
> > > 
> > > 
> > > Jeremias Maerki
> > > 
> > > 
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Glen Mazza]

I'm unsure here.  My interpretation comes from two
places: 

1.) Section 4.8, the last paragraph of [1]:

"The area tree is constrained to satisfy all break
conditions imposed. ***Each keep condition must also
be satisfied***, except when this would cause a break
condition or a stronger keep condition to fail to be
satisfied."

i.e., keep conditions need to be satisfied.

2.) The definitions of the three keep-[] properties
[2] each have a initial value of "auto", meaning
"There are no keep-[] conditions imposed by this
property."

So by default, if the user does not explicitly specify
keep properties, e.g., "keep-together.within-page", no
text, pictures, etc. are to be kept together on the
same page, if they wouldn't already be so due to
free-flowing (i.e., first-fit) text.  Everything would
become free-flowing in order to obey the stylesheet
writer's specifications.

Just my $0.02.

Thanks,
Glen

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak

[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Where did you find such a suggestion? I'd be
> interested to know if
> there's a hint in this direction in the spec. I
> thought it was up to the
> implementation to decide the strategy.
> 
> I think the way we're now taking in our discussion
> suggests that we're
> not going to do a first-fit strategy at all. If
> we're really going down
> the two-strategy path we'll probably end up with a
> best-fit strategy and
> a total-fit or best-fit plus look-ahead. (See
> Simon's list [1]) But
> that's something we still need to figure out
> together.
> 

If we ever have multiple page-breaking options, it can
be a user-defined configuration switch.  No problem
there.

Glen


> [1]
> http://wiki.apache.org/xmlgraphics-fop/PageLayout
> 
> On 02.03.2005 14:48:17 Glen Mazza wrote:
> > Just a sanity check here, the XSL specification
> seems
> > to suggest always the first-fit strategy for page
> > breaking *except* where keeps are explicitly
> > specified.  Am I correct here?  And, if so, is
> what
> > you're planning going to result in an algorithm
> that
> > will help us do this?
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Glen Mazza]

Just a sanity check here, the XSL specification seems
to suggest always the first-fit strategy for page
breaking *except* where keeps are explicitly
specified.  Am I correct here?  And, if so, is what
you're planning going to result in an algorithm that
will help us do this?

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I'd rather not work on HEAD directly because after
> creating the basics
> for the new mechanism the whole thing will probably
> not work for some
> time (probably 2-4 weeks). But I'd like to be able
> to check in early so
> people can review. I expect that the life time of
> the branch will not
> exceed 8 weeks. So there's almost no chance that
> alt-design is repeated,
> especially since the basic LM infrastructure will
> not be altered big
> time and it looks like we are all going in the same
> direction for the
> new page-breaking. It's clear that it has to be done
> and it seems to be
> moveing in the direction of a derived Knuth
> approach. It's much like the
> migration to the Knuth line breaking and it's mostly
> the block-level LMs
> that will be affected. People can continue to work
> on HEAD during that
> time as long as nothing serious is altered in the
> block-level LMs which
> would make merging difficult.
> 
> Before I can kick off we need to agree to the
> general approach for the
> algorithm and clear a few details so we are
> reasonably sure that it'll
> work. Once we have that the plan for the branch
> should not be a big deal
> if we take the above into account.
> 
> On 02.03.2005 13:16:42 Glen Mazza wrote:
> > 
> > --- Chris Bowditch <[EMAIL PROTECTED]>
> wrote:
> > 
> > > > 
> > > > As for the plan to implement a new
> page-breaking
> > > mechanism: I've got to
> > > > do it now. :-) I'm sorry if this may put some
> > > pressure on some of you.
> > > > I'm also not sure if I'm fit already to tackle
> it,
> > > but I've got to
> > > > do it anyway. Since I don't want to work with
> a
> > > series of patches like
> > > > you guys did earlier, I'd like to create a
> branch
> > > to do that on as soon
> > > > as we've agreed on a strategy. Any objections
> to
> > > that?
> > > 
> > > If we are going to branch the code for this then
> we
> > > need to make sure we have 
> > > a plan to merge the branch back once we are
> > > confident in the new page breaking 
> > > algorithm. This plan (which should be agreed
> before
> > > branching takes place) 
> > > should include an acceptance procedure, e.g.
> will a
> > > single -1 be able to 
> > > prevent the code being merged back? We dont want
> to
> > > end up with another 
> > > alt-design, which eventually moved to source
> > > forge!!!
> > > 
> > > Chris
> > > 
> > 
> > Either way is fine with me, but Chris brings up a
> very
> > valid point.  If you can tolerate and keep up with
> my
> > minor code housekeeping from time to time in some
> of
> > the layout managers (currently mostly PSLM), feel
> free
> > to work from HEAD directly instead if you wish.
> > 
> > Glen
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: page-breaking strategies and performance

[Glen Mazza]

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:

> > 
> > As for the plan to implement a new page-breaking
> mechanism: I've got to
> > do it now. :-) I'm sorry if this may put some
> pressure on some of you.
> > I'm also not sure if I'm fit already to tackle it,
> but I've got to
> > do it anyway. Since I don't want to work with a
> series of patches like
> > you guys did earlier, I'd like to create a branch
> to do that on as soon
> > as we've agreed on a strategy. Any objections to
> that?
> 
> If we are going to branch the code for this then we
> need to make sure we have 
> a plan to merge the branch back once we are
> confident in the new page breaking 
> algorithm. This plan (which should be agreed before
> branching takes place) 
> should include an acceptance procedure, e.g. will a
> single -1 be able to 
> prevent the code being merged back? We dont want to
> end up with another 
> alt-design, which eventually moved to source
> forge!!!
> 
> Chris
> 

Either way is fine with me, but Chris brings up a very
valid point.  If you can tolerate and keep up with my
minor code housekeeping from time to time in some of
the layout managers (currently mostly PSLM), feel free
to work from HEAD directly instead if you wish.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

OH!!!   

Yes, you're right, Chris--now I see the issue.  I
implemented validation for about 80% of the FOs, but
80% is not 100%.  fo:table-body never had any
validation implemented, hence the NPE's that were
occurring.  

Sorry, Jeremias, I thought you had just gratuitously
*removed* the validation from fo:table-body -- I
should have researched that it wasn't there to begin
with.

Thanks,
Glen


--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> 
> Glen:
> 
> All Jeremias was doing was changing the code to
> prevent a rather nasty NPE in 
> the event of an empty fo:table-body. Surely you
> cannot be arguging that the 
> NPE be restored?!?
> 
> Chris
> 
> 
> 
> 

remove build.bat and build.sh?

[Glen Mazza]

Team,

Build.bat and build.sh just call "ant" internally
today (and tell them to get Ant if it is not available
on their machine)--I would like to move these
instructions for how to download & activate Ant to our
README file instead, and remove these two files.  (The
check for JAVA_HOME is already done by Ant, so nothing
lost there.)  Are we at the stage yet that we can rely
on just a build.xml?

With this change, instead of calling "build" to start
a build, the user will just type "ant" instead.  (The
README file will tell them this.)  I suspect we'll get
a few more emails on the ML from people who don't read
the README file, but learning a little about Ant--if
only the fact that they need to type "ant"--is
probably a Good Thing for them anyway.

Thanks,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

Simon,

Thanks for reading and responding to my concerns.  I
appreciate it.  Your endorsement of this change is
sufficient for me--I am withdrawing my veto.

Regards,
Glen

--- Simon Pepping <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza
> wrote:
> > 
> > Jeremias, I'm going to veto (-1) your change.  I
> would
> > like the content model restored to the XSL
> standard
> > and the FONode.removeNode() method removed.
> 
> I support Jeremias' change, and vote +1.
>  

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

Jeremias,

My veto still stands, along with the seven technical
reasons given for it.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> 
> On 25.02.2005 07:21:25 Glen Mazza wrote:
> 
> 
> For the moment I'm not going to answer the veto
> itself. Your veto makes
> this situation a one against one. I have presented
> my reasons for the
> change and therefore, I request feedback from the
> rest of the committers
> on this matter even if it's just a short message.
> 
> > Jeremias, I gave you a full, thorough, and
> > respectfully written explanation of the issues
> > involved.  Not only did you mostly ignore it, but
> in
> > your response you chose to use my earlier smaller
> > email in order to give others the impression that
> I
> > had nothing more to say.  This is terrible
> leadership
> > on your part--railroading a change without
> discussion
> > and refusal to discuss the change afterwords.  I
> > simply can't support this behavior, hence my veto.
> 
> It may well be that I'm overreacting here. If that
> is so, then I'd like
> an honest feedback from additional members in the
> team. You must see
> that with your history I learned to treat your
> vetoes with caution
> because of the many times you changed a -1 to a +1
> later after a long
> discussion and a lot of power spent. There's tension
> between us two and
> that's bad. ATM I don't know how to resolve it. I
> tried to be as open as
> possible and to address any concerns you have. You
> have repeatedly
> brought very good points and for that I'm glad but
> you had to withdraw
> several vetoes after starting to realize that you
> were wrong and I've
> also seen behaviour from your part that I don't
> like. For example,
> starting sentences with "Mein Freund, bla bla" and
> then later accusing
> someone else in a different thread of being
> disrespectful. I didn't say
> anything about it then. (Also, apologies to Renaud
> for not speaking up.
> I didn't want to pour any oil into the fire at that
> time.) I tried to
> overlook that, but I have my limits. I sometimes
> wonder if you're not
> more of a blocker in this project than a pusher. I
> don't think I'm the
> only one thinking like this. You know what happend
> during the creation
> of the XML Graphics PMC.
> 
> > BTW, letting yourself be known to the W3C by
> writing
> > to them on occasion would appear to be a smart
> move
> > for you--I don't know why you are fighting this.
> 
> I'm not fighting this. I've had no compelling reason
> and spare time to
> do this, yet. The current issue is no reason for me
> to write anything to
> the WG.
> 
> Jeremias Maerki
> 
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> I have nothing more to say about this. I want to
> spend my time on more
> productive things now.
> 

Jeremias, I'm going to veto (-1) your change.  I would
like the content model restored to the XSL standard
and the FONode.removeNode() method removed.

Technical reasons:

1.)  Your content model change is not in agreement
with either the 1.0 or 1.1 spec.  You did not make a
request to the W3C recommending that they make the
change to the specification.  Our responsibility is to
implement the standard, if we need to diverge from it
we need to inform them first.

I already explained to you[1], via fo:wrapper and
fo:page-sequence-wrapper, that they already make
allowances in order to ease coding.  (Even though I
may not like those changes personally.)

We are not like a commercial product where we can just
ignore the content models, we have a charter and a
community responsibility to fulfill.

2.)  You failed to explain how an empty fo:table-body
could possibly be of use to stylesheet writers, or how
it would simplify their work.  I was able to debunk
what you wrote in my response[2].  All you did say was
that it is illegal and not useful, basically
strengthening my argument.

3.)  As I explained to you, due to the new
relationship between FO's and LM's, our architecture
no longer supports FO's deciding whether or not to be
attached to a LM.  I gave you the opportunity to
discuss moving back to the older architecture, but you
chose to ignore it--instead challenging me to find a
better way.  That was my question: do we need to move
back to the old method?

4.)  The change involved would leave vague of how to
implement a table header if there is no table-body,
worse, it would lead to abuse of the fo:table to just
have headers printed.  None of this is backed up by
the spec--we would be in fantasyland on how to
interpret fo:tables without fo:table-bodies.

5.)  You're relying a dubious distinction of strict
vs. relaxed validation, which has no basis in the
spec.  The content models for the FO's form the
contract of the language that the XSL processor is to
accept.  Not validating at the source requires more &
repeated checking downstream, clogging the logic in
those places, and creating far more sources of error. 
All this for an item that you yourself say is of no
practical use?

6.)  Adhering to the XSL model makes the Apache FOP
process the gold standard of validators--an XSL file
is not legitimate unless FOP accepts it.  Painting FOP
as a reference implementation will do wonders for us,
just as it has for Tomcat.  I *will* support
divergences from it, but we have to (1) discuss it
beforehand, (2) there has to be a legitimate reason
for it--not just saving someone a five-line XSLT
template that should be properly written anyway--(3)
and explain to the W3C our suggestion first.

7.)  I already implemented the official validation. 
You cannot remove it and then tell me if I want it I
have to reimplement it again in a different manner. 
The burden is on you for that.  Our validation unit
has to be able to support the spec.  

Jeremias, I gave you a full, thorough, and
respectfully written explanation of the issues
involved.  Not only did you mostly ignore it, but in
your response you chose to use my earlier smaller
email in order to give others the impression that I
had nothing more to say.  This is terrible leadership
on your part--railroading a change without discussion
and refusal to discuss the change afterwords.  I
simply can't support this behavior, hence my veto.

BTW, letting yourself be known to the W3C by writing
to them on occasion would appear to be a smart move
for you--I don't know why you are fighting this.

Glen

[1] 
http://marc.theaimsgroup.com/?l=fop-dev&m=110922603225376&w=2

[2]
http://marc.theaimsgroup.com/?l=fop-dev&m=110930040205336&w=2

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> 2. Empty
> table-bodies make no
> sense but it makes life easier for stylesheet
> writers not to have to
> work around them.

I don't see the benefits.  In XSLT, one does a test to
see if there is data in the source XML that would
constitute a fo:table-row.  If so, then you activate a
template that creates the fo:table.  Next, within the
template that creates the fo:table (and assorted other
fo's including the fo:table-body), you call another
template for each fo:table-row.  This is standard XSLT
programming -- an empty fo:table-body wouldn't be
needed, and doesn't appear to be useful for the
developer.

If there aren't any to-be fo:table-rows in the input
XML, the template that creates the fo:table is never
called, and so there is no empty fo:table-body
necessary.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

--- Glen Mazza <[EMAIL PROTECTED]> wrote:
>
> Jeremias,
> 
> This should not be done.  If someone has a problem
> with it--and I've never heard a complaint--they can
> send an email to xsl-editors, for them to adjust the
> content model for fo:table accordingly.  (If they
> don't, they don't.)
> 

To elaborate, I also frequently have problems with
certain content models, but what I do is send requests
to the xsl-editors list[1] when I have them (for
example, [2, #61], and several others).  I think it
would be best for you to do that before considering
making the change with FOP.  It may also encourage
others to endorse your suggestion on the ML.

But making the change without informing the W3C of
what you see as an error doesn't help improve the
standard.  Also, IMO we should be encouraging unhappy
users to register their complaints with the W3C so
that they will indeed make these changes.  (10, 15
complaints, they will!)  In this way, FOP plays the
role of a true reference implementation, with a nice
circular, ongoing feedback with the W3C, and all
FOP-accepted stylesheets will be guaranteed to work
with other processors.

We validate also to show newbie users what they are
doing wrong.  It gives nice correction and feedback to
the user, just like compilation errors in Java give
feedback to newbie developers.  Validation serves a
good purpose.

[1]
http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/

[2]
http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/0011.html


> Note that the editors are very reasonable about
> this--for example, fo:page-sequence-wrapper and
> fo:wrapper are allowed to have no children for
> programmatic convenience, even though it doesn't
> make
> sense for these items to be empty.
> 

And in #61, you can see I don't like empty
fo:page-sequence-wrappers or fo:wrappers either.  ;)


> BTW, what is FONode.removeChild() for anyway?  Why
> is
> this helpful--we haven't needed such a method for
> years.
> 

Sorry, I was wrong here--we have indeed needed such a
method, until about December ([3], emails 9, 7, 6). 
We used to have addLayoutManager() in the FO's in
which the FO would determine whether or not it was
empty, and if not, attach itself to a Layout Manager. 
(Email #9)  I kind of preferred this implementation,
as it allowed us to keep the internal state of each FO
internal, rather than need to expose its internal
variables to another object that would subsequently
read inside it to make the empty-or-not determination
for the FO.

Simon moved us away from that (Email #7 of [3])
because he didn't want the FO's to have knowledge of
layout managers, and wanted to move us from (1) having
the FO decide whether or not to attach itself to a LM
to (2) having a layout manager decide whether or not
to process an empty FO.  This is not my preferred
implementation, but it seems an acceptable
interpretation.

But your removeNode() function seems to be bouncing
back to the original implementation now: let the FO
decide.  Can we make a decision and settle on one or
the other here?  Do we really have to do both?

Also, my main problem with Simon's implementation, was
that (as mentioned above) the FO's needed to expose
their internal state more to the LayoutManagerMaker
object so the latter could determine if it needed to
process that FO.  I think Simon saw that a little as
well, and what I recommended in Email #6 was that we
have an boolean FONode.isEmpty() that the
LayoutManagerMakers can read, and if it returns true,
to not process the FO.  Question: can we use a boolean
isEmpty() instead of your removeNode()?  We can then
much better encapsulate each FO (i.e., instead of
having a LMM read variable a, b, and c of an FO to see
if it needs processing, it can just check isEmpty()).

Sorry for the long post.

Thanks,
Glen

[3] http://marc.theaimsgroup.com/?t=11028610291&r=1&w=2

Re: Renaming the AWT Renderer to Java2D Renderer

[Glen Mazza]

--- The Web Maestro <[EMAIL PROTECTED]> wrote:
> 
> One thing I know for certain, is that it would be
> great if we could all 
> get together for a beer (root beer or ginger ale is
> acceptable for 
> those trying to cut down!)
> 

I know...sad thing is, you're the closest committer to
me and California is thousands of miles away!  (We can
meet halfway though...perhaps Pittsburgh would be
good... ;)

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

Jeremias,

This should not be done.  If someone has a problem
with it--and I've never heard a complaint--they can
send an email to xsl-editors, for them to adjust the
content model for fo:table accordingly.  (If they
don't, they don't.)

Note that the editors are very reasonable about
this--for example, fo:page-sequence-wrapper and
fo:wrapper are allowed to have no children for
programmatic convenience, even though it doesn't make
sense for these items to be empty.

BTW, what is FONode.removeChild() for anyway?  Why is
this helpful--we haven't needed such a method for
years.

Thanks,
Glen


--- [EMAIL PROTECTED] wrote:

> jeremias2005/02/23 14:04:01
> 
>   Modified:src/java/org/apache/fop/fo FObj.java
> FONode.java
>src/java/org/apache/fop/fo/flow
> TableBody.java
>   Log:
>   An empty table-body is illegal but we'll allow it
> to make things easier for stylesheet writers.
>   Empty table-body elements are removed from their
> parent so they can't cause any nasty effects in the
> LMs.
>   
>   Revision  ChangesPath
>   1.92  +7 -0 
> xml-fop/src/java/org/apache/fop/fo/FObj.java
>   
>   Index: FObj.java
>  
>
===
>   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/fo/FObj.java,v
>   retrieving revision 1.91
>   retrieving revision 1.92
>   diff -u -r1.91 -r1.92
>   --- FObj.java   3 Feb 2005 08:18:27 -   1.91
>   +++ FObj.java   23 Feb 2005 22:04:01 -  1.92
>   @@ -170,6 +170,13 @@
>}
>}
>
>   +/** @see
>
org.apache.fop.fo.FONode#removeChild(org.apache.fop.fo.FONode)
> */
>   +public void removeChild(FONode child) {
>   +if (childNodes != null) {
>   +childNodes.remove(child);
>   +}
>   +}
>   +
>/**
> * Find the nearest parent, grandparent, etc.
> FONode that is also an FObj
> * @return FObj the nearest ancestor FONode
> that is an FObj
>   
>   
>   
>   1.54  +10 -0
> xml-fop/src/java/org/apache/fop/fo/FONode.java
>   
>   Index: FONode.java
>  
>
===
>   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/fo/FONode.java,v
>   retrieving revision 1.53
>   retrieving revision 1.54
>   diff -u -r1.53 -r1.54
>   --- FONode.java 1 Feb 2005 21:21:28 -   1.53
>   +++ FONode.java 23 Feb 2005 22:04:01 -  1.54
>   @@ -198,6 +198,15 @@
>}
>
>/**
>   + * Removes a child node. Used by the child
> nodes to remove themselves, for
>   + * example table-body if it has no children.
>   + * @param child child node to be removed
>   + */
>   +public void removeChild(FONode child) {
>   +//nop
>   +}
>   +
>   +/**
> * @return the parent node of this node
> */
>public FONode getParent() {
>   @@ -410,5 +419,6 @@
>public int getNameId() {
>return Constants.FO_UNKNOWN_NODE;
>}
>   +
>}
>
>   
>   
>   
>   1.38  +8 -1 
>
xml-fop/src/java/org/apache/fop/fo/flow/TableBody.java
>   
>   Index: TableBody.java
>  
>
===
>   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/fo/flow/TableBody.java,v
>   retrieving revision 1.37
>   retrieving revision 1.38
>   diff -u -r1.37 -r1.38
>   --- TableBody.java  21 Feb 2005 21:52:14 -  1.37
>   +++ TableBody.java  23 Feb 2005 22:04:01 -  1.38
>   @@ -88,6 +88,11 @@
> */
>protected void endOfNode() throws
> FOPException {
>getFOEventHandler().endBody(this);
>   +if (childNodes == null ||
> childNodes.size() == 0) {
>   +getLogger().error("fo:table-body must
> not be empty. "
>   ++ "Expected:
> (table-row+|table-cell+)");
>   +getParent().removeChild(this);
>   +}
>convertCellsToRows();
>}
>
>   @@ -98,7 +103,9 @@
> */
>private void convertCellsToRows() throws
> FOPException {
>try {
>   -if (childNodes.size() == 0 ||
> childNodes.get(0) instanceof TableRow) {
>   +if (childNodes == null 
>   +|| childNodes.size() == 0 
>   +|| childNodes.get(0)
> instanceof TableRow) {
>return;
>}
>//getLogger().debug("Converting cells
> to rows...");
>   
>   
>   
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 

Re: Renaming the AWT Renderer to Java2D Renderer

[Glen Mazza]

We can do it this way.  But on second thought, I think
it would be better for Renaud to move it in as
AWTRenderer, and slowly start factoring out more and
more while things are getting settled.  BTW, this will
take some time to do anyway--it isn't easy because the
renderers are so different between 0.20.5 and 1.0.

[A note for Renaud:  I would recommend cutting down on
the chatroom English and instead start writing
properly/respectfully to us, in the same manner that
all of us have been writing to you.  Capitalize "I",
the first word of each sentence, your name, our
names[1], greetings, etc.  Above all, when people
write to you in standard polite English, you shouldn't
be responding back with chatroom writing.  None of us
here do.  Thanks!]

Glen

[1]
http://marc.theaimsgroup.com/?l=fop-dev&m=110625230922690&w=2


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Given the new layout I don't even need to prepare
> anything. It would
> only complicate things. Just rename the AWTRenderer
> to Java2DRenderer,
> move it to the new location, then create an empty
> subclass of
> Java2DRenderer called AWTRenderer and move any
> AWT-dependant code to
> that subclass.
> 
> On 22.02.2005 22:43:01 Renaud Richardet wrote:
> > Glen Mazza <[EMAIL PROTECTED]> wrote:
> > > Looks good!  Now whether you wish to do this
> before or
> > > after Renaud moves the logic over is up to you
> two.
> > > There's advantages/disadvantages to either
> method.
> > yes, that looks good! 
> > 
> > Jeremias, if it's ok for the team, i would
> apreciate if you would do
> > the changes asap.
> > 
> > thanks, Renaud
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: Renaming the AWT Renderer to Java2D Renderer

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> Deal. It seems like we want the same things but
> didn't understand each
> other. I hope we do now.
> 
> I've documented all this in a Wiki page:
> http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> 

Looks good!  Now whether you wish to do this before or
after Renaud moves the logic over is up to you two. 
There's advantages/disadvantages to either method.

Thanks,
Glen

Re: Renaming the AWT Renderer to Java2D Renderer

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> A veto would have been easier. :-) I would simply
> have stopped and said:
> "Sigh. Again. Ok, next task."
> 

Yes, but the change proposed simply doesn't rise to
the level of a veto.

> Would it be more interesting/agreeable if we would
> leave the render.awt
> package and create an AWTRenderer that is optimized
> for embedding into
> AWT/Swing applications? 

Close.  How about this:  AWTRenderer is just for our
pop-up AWT/Swing window with the document in the
middle.  It will extend an (abstract?) Java2DRenderer,
and will not really be meant to be extended or
modified by other users.  

Java2DRenderer, OTOH, is what is used for others for
embedding into AWT/Swing applications.  AWTRenderer,
in addition to being our own native renderer, will be
an excellent example of how to extend Java2DRenderer
in the user's own programs.

Simplest use case:  someone wants Java2D output but
doesn't like our AWTRenderer.  Wants to add some
buttons, remove others from the window, do 400 other
things.  They will extend the Java2DRenderer to embed
this technology into their own work.  

By way of analogy:

AWTRenderer = Squiggle
Java2DRenderer = Whatever Batik does to allow other
users to create their own Squiggle apps.  (Sorry, I
don't know Batik! ;)

WDYT?

Glen

Re: Renaming the AWT Renderer to Java2D Renderer

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> Now that we've got someone who will work on the AWT
> Renderer I'd like to
> know if someone is against renaming the AWT Renderer
> to Java2D Renderer.

"AWT Renderer" has a rich history within FOP, it's a
popular renderer, and I have not heard of any
complaints or confusion from the user community about
its naming.  Its output is that neat-looking AWT/Swing
window, so it's not that incorrect a name.  The
internal technology we use to generate said window is
IMO less important than what the user sees.


> The API in use is actually the Java2D API [1],
> although most of the
> classes had their origin within AWT (and are still
> in there). 

Mein Freund, even the Java2D library itself (from the
link you gave below) uses ".awt." in their package
names and not ".java2D.".  Why should we use .java2D.
in our package names when even Java2D itself
doesn't/won't?

Also, using this logic, shouldn't we rename the
(future) TIFF Renderer--which Oleg says will descend
from AWTRenderer--and current SVG Renderers to
Java2DRenderer as well?  Don't they use Java2D as
well?

Now, if you want to create a Java2DRenderer as a
abstract base class for Renderers utilizing
it--AWTRenderer, AWTPrintRenderer, SVGRenderer,
TIFFRenderer, etc., that would appear to make a lot
more sense.  Consider that before you tie
"Java2DRenderer" specifically with our AWTRenderer.


> AWT is
> actually the windowing toolkit which is something
> that's not used inside
> the renderer. 

True, but PDF is not used within the PDF Renderer. 
Text codes "/0 /0 /a /c" etc. etc. are instead.  To a
degree, using this logic here would then call for us
renaming PDF Renderer to BinaryOutputCodesRenderer.  


> Only when the Java2D renderer is
> embedded inside a GUI
> application AWT (or rather Swing or SWT) are coming
> into use. 

Yes, so far we have been naming our renderers on the
final output that the user sees (here, an AWT/Swing
window), not the internal technology used in
generating that output.


> And the
> preview window actually uses Swing, not AWT.
> 

But Swing sits on top of AWT, no?  Also, I suspect
there are AWT-specific packages within the AWTRenderer
anyway (such as the EventHandlers and EventListeners
like java.awt.event.ActionEvent).  AWTRenderer appears
more accurate overall then SwingRenderer, and has the
added benefit of not sounding as silly.  ;)


> So here are the proposed changes:
> 
> - Package org.apache.fop.render.awt becomes
> org.apache.fop.render.java2d
>

-0.5, because java2d itself uses "awt" in its package
name, and we use (or will use) java2d for more than
the AWTRenderer.  It's more consistent as-is.

Also, "AWTRenderer" gives the user a better mental
model of what the output of this type is -- and
AWT/Swing Window with a document in the middle. 
"Java2DRenderer" sounds like an intermediate renderer
that can be output in several different ways, not just
an AWT window.


> - AWTRenderer.java becomes Java2DRenderer.java
> (AWT*.java ->
> Java2D*.java)
> 

-0.5, because, again, other renderers use or may use
Java2D.  And we can't all be renaming our renderers
BinaryOutputCodesRenderer.java and
Java2DRenderer.java.

Note, of course, these aren't vetoes.

Regards,
Glen

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> It doesn't really matter if the FOs generate
> reference areas or not, the

Well, the Recommendation declares which of the three
types each FO belongs to, in the "Areas" section in
each FO definition.  It is a static answer that holds
for all FO's of a given type, i.e. it is not something
dynamically dependent on how a particular instance of
an FO is currently used in processing.

So there should not need to be any debate of whether
any FO (1) generates areas, (2) returns areas, or is
(3) used in generating areas -- we would have a bug in
the Rec if it were vague for any particular FO.

Glen

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

--- Glen Mazza <[EMAIL PROTECTED]> wrote:
>
> This IMO is the fatal flaw in your logic in your
> previous email.  You determined fo:s-p-m and fo:r-b
> to
> be type (1) FO's, and hence used the wrong equations
> in 5.3.2 to determine calculated values for them. 
> They are type (3) FO's, and hence the first two
> equations can never be relevant for them.
> 

Oops!  The second equation set in 5.3.2 *can* be
relevant for an FO that does not generate areas.  It
is not applicable for the fo:region-body in Luca's
example, however, because "margin-" was not
explicitly specified on it.  Hence, we are left with
the third equation set.

Glen

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I'm afraid that you're wrong here. It's true that
> s-p-m and region-body
> don't directly generate reference areas but they
> also can't, because
> they are only used as a template for each new page.

Jeremias, so you are in agreement with me that they
are type (3) below -- not type (1).  The spec is very
clear on that.  These FO's are *used to generate a
area*, they don't *generate them* directly.  Hence you
are using the wrong equations to determine their
values.  They do *not* generate reference areas,
unlike what you were basing your logic on in your
previous email.


> For for each page
> they serve as FOs that generate reference areas.
> 

Please use the official Rec terminology:  "they are
used to generate reference areas"  (type 3).  (If you
get vague, then your solutions become in danger of
getting inaccurate.)


> But let me give you another example where this is
> clearer and so you see
> that your argument doesn't really count in this
> discussion. Please open
> test/layoutengine/testcases/block-container3.xml.

> You can't
> deny that block-container generates a reference area
> directly. 

I'm not denying that at all.  But we are determining
the value of these properties on fo:region-body and
fo:simple-page-master, we are *not* resolving these
properties on fo:block-container.  Fo:block-container
uses these properties after they are already
calculated on fo:region-body and fo:s-p-m.  You are
jumping ahead here--the calculated values of these
properties on fo:s-p-m and fo:region-body is what the
point of your email was, and that is what I was
responding to.  Let's get these calculated values on
fo:r-b and fo:s-p-m nailed down before we discuss
their further usage within an fo:page-sequence.

This section of the spec, 5.3.2, Jeremias, and your
email I responded to, was just to determine the
calculated values on these two FO's:  fo:s-p-m and
fo:r-b.  This can be done, and their values would be
the same, regardless of whether those values are
subsequently activated within a page-sequence.  


>So in
> this test case the block inside the b-c has an
> effective start-indent of
> 20pt (10pt + 10pt) much like in Luca's example.
> 
> If you look at the checks at the end of
> block-container3.xml you will
> realize that there is no "2" (millipoints)
> anywhere. It's simply the
> effect from the reference area which results in the
> double indent. So if
> you wanted to have both text-generating blocks
> left-aligned at the same
> position you'd have to specify start-indent="0pt" on
> the block-container
> or on its nested block to reset the start-indent to
> "0pt".
> 

This has nothing to do with the discussion.  We're
talking about the resolved values directly on fo:s-p-m
and fo:region-body.  That's all I was responding to:
your previous email.  You are using the wrong
equations to determine their calculated values,
because you incorrectly assumed that those FO's
(fo:s-p-m and fo:r-b) generate reference areas.

> > 
> > Section 6.1 [1] says "There are three kinds of
> > formatting objects: (1) those that generate areas,
> (2)
> > those that return areas, but do not generate them,
> and
> > (3) those that are used in the generation of
> areas."
> > 
> > fo:s-p-m and fo:region-body are type (3), not type
> > (1).
> > 
> > fo:s-p-m text:  The fo:simple-page-master
> formatting
> > object generates no area directly. It is used in
> the
> > generation of pages by an fo:page-sequence. type
> (3)
> > 
> > fo:r-b text:  The fo:region-body formatting object
> is
> > used to generate one region-viewport-area and one
> > region-reference-area whenever an
> > fo:simple-page-master that has an fo:region-body
> as a
> > child is used to generate a page.  (i.e., type 3)
> > 
> > 
> > [1]
> >
> 

This IMO is the fatal flaw in your logic in your
previous email.  You determined fo:s-p-m and fo:r-b to
be type (1) FO's, and hence used the wrong equations
in 5.3.2 to determine calculated values for them. 
They are type (3) FO's, and hence the first two
equations can never be relevant for them.


http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section
> > 
> > 
> > > So in your case you could specify
> > > a margin="0pt" on
> > > the region-body which triggers the first formula
> > > given in 5.3.2. 
> > 
> > Again, I don't think so because fo:region-body
> never
> > generates a reference-area.  Hence, with no
> explicit
> > specification of margin properites, the third set
> of
> > formulas then activates:
> > 
> > margin-corresponding = start-indent -
> > inherited_value_of(start-indent) -
> > padding-corresponding - border-corresponding-width
> > 
> > with the additional rule that:  "If the
> "start-indent"
> > or "end-indent" properties are not specified their
> > inherited value is used in these formulae."
> > 
> > Since start-indent and end-indent were not
> specified,
> > then we have:
> > 
> > margin-corresponding =
> > inherited_value_of(start-indent)

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

On second thought, Jeremias, instead of arguing this,
why don't we just compromise at 75pt. margins?  ;)

Glen

--- Glen Mazza <[EMAIL PROTECTED]> wrote:

> --- Jeremias Maerki <[EMAIL PROTECTED]>
> wrote:
> 
> > Hi Luca,
> > 
> > the reason for the effect you're seeing is the
> > inheritance of
> > start-indent and end-indent. In your exapmle, if
> you
> > specify a
> > margin-left and margin-right on the
> > simple-page-master, 
> 
> (margin-left and margin-right of 50pt each on
> fo:s-p-m)
> 
> > this results
> > (corresponding properties) in a start-indent and
> > end-indent of 50pt each.
> 
> via the second set of formulas, because margins are
> explicitly specified and fo:s-p-m does not generate
> any area and hence does not generate a reference
> area
> (although it is used by fo:page-sequence to do so):
> I
> agree here.
> 
> 
> > Now, because start|end-indent are inherited,
> > region-body also starts
> > with a start-indent and end-indent of 50pt which
> 
> I agree, but these properties are not explicitly
> specified on fo:region-body, so the first two sets
> of
> formulae are not relevant here.  Nor would they be
> anyway because I don't believe fo:region-bodies
> generate reference areas.
> 
> 
> > together with the
> > parent's start-indent accumulates 100pt because
> each
> > of the FOs are
> > generating a reference area. 
> 
> I don't think so here--I don't believe either
> fo:s-p-m
> or fo:region-body generate reference areas--indeed,
> I
> don't think anything located outside of
> fo:page-sequence does.  The spec says they are
> *used*
> to create a reference area, but they don't generate
> one themselves.  So maybe your calculations here may
> need changing--because different formulae in 5.3.2
> would hence be activated.
> 
> Section 6.1 [1] says "There are three kinds of
> formatting objects: (1) those that generate areas,
> (2)
> those that return areas, but do not generate them,
> and
> (3) those that are used in the generation of areas."
> 
> fo:s-p-m and fo:region-body are type (3), not type
> (1).
> 
> fo:s-p-m text:  The fo:simple-page-master formatting
> object generates no area directly. It is used in the
> generation of pages by an fo:page-sequence. type (3)
> 
> fo:r-b text:  The fo:region-body formatting object
> is
> used to generate one region-viewport-area and one
> region-reference-area whenever an
> fo:simple-page-master that has an fo:region-body as
> a
> child is used to generate a page.  (i.e., type 3)
> 
> 
> [1]
>
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section
> 
> 
> > So in your case you could specify
> > a margin="0pt" on
> > the region-body which triggers the first formula
> > given in 5.3.2. 
> 
> Again, I don't think so because fo:region-body never
> generates a reference-area.  Hence, with no explicit
> specification of margin properites, the third set of
> formulas then activates:
> 
> margin-corresponding = start-indent -
> inherited_value_of(start-indent) -
> padding-corresponding - border-corresponding-width
> 
> with the additional rule that:  "If the
> "start-indent"
> or "end-indent" properties are not specified their
> inherited value is used in these formulae."
> 
> Since start-indent and end-indent were not
> specified,
> then we have:
> 
> margin-corresponding =
> inherited_value_of(start-indent) -
> inherited_value_of(start-indent) -
> padding-corresponding - border-corresponding-width,
> 
> or zero for the margin properties on fo:region-body.
> 
> (i.e., we just rely on the 50pt. on
> simple-page-master.)
> 
> So Luca is correct that both fo:simple-page-masters
> should generate the same overall margins of 50 pt.
> each, no?
> 
> Thanks,
> Glen
> 
> 

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Hi Luca,
> 
> the reason for the effect you're seeing is the
> inheritance of
> start-indent and end-indent. In your exapmle, if you
> specify a
> margin-left and margin-right on the
> simple-page-master, 

(margin-left and margin-right of 50pt each on
fo:s-p-m)

> this results
> (corresponding properties) in a start-indent and
> end-indent of 50pt each.

via the second set of formulas, because margins are
explicitly specified and fo:s-p-m does not generate
any area and hence does not generate a reference area
(although it is used by fo:page-sequence to do so): I
agree here.


> Now, because start|end-indent are inherited,
> region-body also starts
> with a start-indent and end-indent of 50pt which

I agree, but these properties are not explicitly
specified on fo:region-body, so the first two sets of
formulae are not relevant here.  Nor would they be
anyway because I don't believe fo:region-bodies
generate reference areas.


> together with the
> parent's start-indent accumulates 100pt because each
> of the FOs are
> generating a reference area. 

I don't think so here--I don't believe either fo:s-p-m
or fo:region-body generate reference areas--indeed, I
don't think anything located outside of
fo:page-sequence does.  The spec says they are *used*
to create a reference area, but they don't generate
one themselves.  So maybe your calculations here may
need changing--because different formulae in 5.3.2
would hence be activated.

Section 6.1 [1] says "There are three kinds of
formatting objects: (1) those that generate areas, (2)
those that return areas, but do not generate them, and
(3) those that are used in the generation of areas."

fo:s-p-m and fo:region-body are type (3), not type
(1).

fo:s-p-m text:  The fo:simple-page-master formatting
object generates no area directly. It is used in the
generation of pages by an fo:page-sequence. type (3)

fo:r-b text:  The fo:region-body formatting object is
used to generate one region-viewport-area and one
region-reference-area whenever an
fo:simple-page-master that has an fo:region-body as a
child is used to generate a page.  (i.e., type 3)


[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section


> So in your case you could specify
> a margin="0pt" on
> the region-body which triggers the first formula
> given in 5.3.2. 

Again, I don't think so because fo:region-body never
generates a reference-area.  Hence, with no explicit
specification of margin properites, the third set of
formulas then activates:

margin-corresponding = start-indent -
inherited_value_of(start-indent) -
padding-corresponding - border-corresponding-width

with the additional rule that:  "If the "start-indent"
or "end-indent" properties are not specified their
inherited value is used in these formulae."

Since start-indent and end-indent were not specified,
then we have:

margin-corresponding =
inherited_value_of(start-indent) -
inherited_value_of(start-indent) -
padding-corresponding - border-corresponding-width,

or zero for the margin properties on fo:region-body. 
(i.e., we just rely on the 50pt. on
simple-page-master.)

So Luca is correct that both fo:simple-page-masters
should generate the same overall margins of 50 pt.
each, no?

Thanks,
Glen

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

Jeremias,

I am wrong here.  This phrase in 5.3.2:

"If the corresponding absolute "margin" property is
specified on the formatting object..."

Clearly means that margin *is* a CP, and hence is a CP
with start-indent/end-indent as appropriate.  Forget
that argument--never mind, and I'm sorry that you had
to waste time explaining this to me.

I may have more questions on your logic though, as I'm
studying your original response to Luca.  But
thankfully we're in agreement on this point.

Thanks,
Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> In mid January Peter helped me understand what's
> going on. Please have a
> look at his explanation [1]. Maybe that makes it
> clearer. The margin
> properties are never used directly in the layout
> engine (I think and
> hope). I'm always working from *-indent and space-*.
> I think it's
> obvious enough from 5.3.2 that *-indent and margin
> are meant to be corresponding,
> at least through the rules established therein.
> 
> Actually, I think 5.1.2 is the section I should have
> looked at before
> Peter pointed out my mistake. About corresponding
> properties it says
> "The simplest example of such properties...", so in
> my view 5.3.2
> describes a complex relationship and so my calling
> these properties
> corresponding was really correct. And the rules in
> 5.3.2 talk about
> corresponding ("margin-corresponding"), and to what
> can they correspond
> to if not start-indent and end-indent or
> space-before and space-after
> depending on the writing mode?
> 
> If you think the current interpretation is wrong,
> please present your
> theory. However, the more I think about this, and
> the more I'm
> explaining, the more I can say that I'm sure that
> the interpretation is
> correct.
> 
> [1]
>
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=2078791

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

But if start-indent and margin-left are not
Corresponding Properties, then the inheritance of
50pt. you gave in your example would not occur.

IMO, if start-indent and margin-left were actually
intended to be Corresponding Properties, the former
would have been named margin-start.  Also,
margin-before and margin-after (or before-indent and
after-indent) corresponding properties would also have
been created.  The description of Corresponding
Properties, 2nd para of 5.1.2, is unfortunately vague
about which properties are actually CP's.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Yes, I was probably not 100% correct in my
> explanation though my
> interpretation still stands.
> 
> On 15.02.2005 18:02:14 Glen Mazza wrote:
> > Oh--5.3.2 says: "There are two more properties,
> > "end-indent" and "start-indent" (block-level
> > formatting objects) which correspond to the
> various
> > absolute "margin" properties."
> > 
> > I'm uncertain that that means that they are
> > Corresponding Properties however--I wonder if you
> are
> > reading too much into the word "correspond".
> 
> 
> Jeremias Maerki
> 
> 

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

Oh--5.3.2 says: "There are two more properties,
"end-indent" and "start-indent" (block-level
formatting objects) which correspond to the various
absolute "margin" properties."

I'm uncertain that that means that they are
Corresponding Properties however--I wonder if you are
reading too much into the word "correspond".

Glen


--- Glen Mazza <[EMAIL PROTECTED]> wrote:

> --- Jeremias Maerki <[EMAIL PROTECTED]>
> wrote:
> 
> > Hi Luca,
> > 
> > the reason for the effect you're seeing is the
> > inheritance of
> > start-indent and end-indent. In your exapmle, if
> you
> > specify a
> > margin-left and margin-right on the
> > simple-page-master, this results
> > (corresponding properties) in a start-indent and
> > end-indent of 50pt each.
> 
> Jeremias,
> 
> I think I am missing something here.  Margin-left
> and
> margin-right are different properties from
> start-indent and end-indent, so I'm unsure why
> inheritance between the two would be applicable in
> this case.
> 
> How does specifying margin-left = 50pt result in the
> start-indent value being set to 50pt? 
> (Corresponding
> properties just map ***-start to ***-left, etc. for
> an
> otherwise-same-named property so CP don't appear to
> be
> relevant to this issue.  Does the spec declare
> margin-left and start-indent to be corresponding
> properties?)
> 
> Thanks,
> Glen
> 
> 

Re: Error in computation of inline progression dimension ?

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Hi Luca,
> 
> the reason for the effect you're seeing is the
> inheritance of
> start-indent and end-indent. In your exapmle, if you
> specify a
> margin-left and margin-right on the
> simple-page-master, this results
> (corresponding properties) in a start-indent and
> end-indent of 50pt each.

Jeremias,

I think I am missing something here.  Margin-left and
margin-right are different properties from
start-indent and end-indent, so I'm unsure why
inheritance between the two would be applicable in
this case.

How does specifying margin-left = 50pt result in the
start-indent value being set to 50pt?  (Corresponding
properties just map ***-start to ***-left, etc. for an
otherwise-same-named property so CP don't appear to be
relevant to this issue.  Does the spec declare
margin-left and start-indent to be corresponding
properties?)

Thanks,
Glen

Re: representative example needed [was in fop-user]

[Glen Mazza]

--- Vincent Hennebert <[EMAIL PROTECTED]>
wrote:
>
> 
> > You would be most welcome here.
> I really would be glad to help. Sadly I don't have
> much time to devote to Fop. 
> I've begun to read the XSL spec and dive into Fop
> code. I'll still need some 
> time before being able to provide patches. Hope
> you'll hear about me soon...
> 

Hey--don't worry about it.  Do take care of your own
needs first of course.  If you're busy that's fine.

Regards,
Glen

Re: need to update team page

[Glen Mazza]

Thanks for updating the site, and also thanks for
teaching us how to fish here.  I will do this next
time I need an update to occur.

Glen


--- The Web Maestro <[EMAIL PROTECTED]> wrote:

> On Feb 11, 2005, at 12:30 PM, Glen Mazza wrote:
> > Clay,
> >
> > I have a favor to ask--when you have the chance,
> would
> > you please republish the FOP team page with my
> recent
> > changes?  Much appreciated!
> 
> I've updated the FOP Team page (HTML & PDF).
> 
> FYI (and FMI), the quick and dirty way to generate a
> new page (without 
> waiting for the whole site to generate) is to run
> this command:
> 
> forrest -Dproject.start-uri=team.pdf
> 
> and then this one:
> 
> forrest -Dproject.start-uri=team.html
> 
> Do the PDF first--since there's no links in it,
> forrest stops after 
> generating the PDF. Then do team.html, which starts
> the normal process. 
> Because there was no change in the navigation
> structure (no files added 
> or removed), you can just stop it (Ctrl-C).
> 
> One of these days I'll update the Doc Mgmt page[1]
> to include this 
> information. Of course we need to set up the CVS
> system for this to 
> work 'correctly', which will happen in due time.
> 
> Cheers!
> 
> [1] FOP Doc Management Page
> http://xml.apache.org/fop/dev/doc.html
> 
> Web Maestro Clay
> -- 
> <[EMAIL PROTECTED]> -
> <http://homepage.mac.com/webmaestro/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
> 
> 

Re: representative example needed [was in fop-user]

[Glen Mazza]

Hello Vincent!

--- Vincent Hennebert <[EMAIL PROTECTED]>
wrote:

> [Web Maestro Clay]
> > It would be *great* if some enterprising and
> generous developer could spend 
> > the time to generate FOP-based XSL-FO documents
> from the XML, XSLT and XPath
> >  specs. In fact, that would be a useful tool for
> comparing how fop-0.20.5 
> > compares to fop-1.0-dev (the FOP re-design/TRUNK
> branch). Unfortunately, that
> >  hasn't been a priority up to this point. Perhaps
> it could become a priority
> >  in the future.
> 
> [Jeremias]
> > Oh, it would be so cool if we could have our
> own PDF of the XSL 1.0 
> > specification [1]. The official PDF was created by
> RenderX. I thought about 
> > doing a stylesheet for that myself but I'm
> currently so busy coding on FOP 
> > 1.0dev that I'd be more than happy if someone from
> the user community could 
> > do that. It would also be interesting to compare
> FOP 0.20.5 and FOP 1.0dev 
> > which is under development.
> 
> [Glen]
> > Doughnuts are great!  I really like them.
>

> Hi Fop team,
> 
> would there be anything wrong with using RenderX'
> XSLT stylesheet to produce a
> pdf whith Fop? 

Probably, right now, because if we modify it it would
still be copyrighted by RenderX, so we can't have it
on our site, etc.  We must be very careful to stay
away from their work (I will flatter myself into
thinking that some of them are even subscribed to this
ML ;), and not have their work show up in one form or
another within our project.

So I think we should wait on this until the W3C makes
up its own stylesheet without extensions, and makes
the same stylesheet publicly available for any XSL
processor to run.

What may be more "cool"--and a much better selling
point for FOP anyway--is for the Docbook XSL/PDF
stylesheets to work well with 1.0 (0.20.5 already does
a pretty good job with Docbook PDF generation.)  I
think that's a nicer target than the RenderX
stylesheet, much more practical for our user base, and
avoids the copyright headaches.  But it is indeed a
lot more work.


> Anyway, I have it on my disk and tried to run Fop
> over it. Well, bad news so far ;-(
> Fop 0.20.5 stops at p.16 whith an error message
> (Flow 'xsl-region-body' does not
> map to the region-body in page-master 'blank-page').
> This is the page where
> there is just "This page is intentionally left
> blank".

We don't care much for making changes to 0.20.5
anymore.  We focus on 1.0.


> Fop 1.0dev (freshly checked out) crashes with a
> NoSuchMethodError.

Now *that* is of interest for us.  


> I can provide details if needed (in form of a
> Bugzilla entry?).

Sure for 1.0, please.


> I could adapt the stylesheet to introduce Fop
> extensions (at least for the
> 0.20.5 version, I don't think they are available in
> 1.0dev?), 

No--because again we don't want it anywhere on our
site--please don't send it to us--it is RenderX's
stylesheet, not ours.  It is better not to even look
at it, lest our ideas for a similar stylesheet end up
coming from their work.  (For FOP, BTW, the bookmark
extensions from 0.20.5 were removed in favor of the
1.1 fo:bookmark-tree & Co. formatting objects.)


> and perhaps to
> circumvent Fop's current flaws. If it may be useful
> to the Fop team I would be
> glad to help.
> 

You would be most welcome here.

Thanks,
Glen

(BTW, checked your ENSEEIHT website -- looks like a
wonderful place for a person to grow.)

Re: testcases

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Thanks, Simon.
> 
> And fop-devs, also note that you are allowed (and
> encouraged) to correct,
> modify, improve and add test cases yourself. :-)
> 

Can we remove some too?!?  ;)

Glen

need to update team page

[Glen Mazza]

Clay,

I have a favor to ask--when you have the chance, would
you please republish the FOP team page with my recent
changes?  Much appreciated!

Thanks,
Glen

Re: Markers added to the wrong page

[Glen Mazza]

OK...I see its purpose now.  But please put in a
descriptive comment for isBogus() in
AbstractLayoutManager so others down the road
understand what it means and what it is for.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Glen,
> 
> no, I'm afraid the isBogus() method is necessary
> because it checks the
> parent LM. 

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

[Glen Mazza]

I just took care of it--you may need to refresh PSLM
in the marker patch though as I did some minor changes
in that class as well.

BTW, I'd like to remove "String
getCurrentPageNumber();" from the LayoutManager
interface and replace it with "PageSequence
getCurrentPageSequence()".  The latter offers a
superset of the former's functionality, and also
allows us to move the page number string formatting
from PSLM (see the first few lines of
PSLM.activateLayout() for example) to
PageNumberLayoutManager.  Any objections?

Thanks,
Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Glen,
> 
> no, that's ok. Thanks for the review. I've removed
> my change locally and
> will commit either tomorrow or on Monday. I can't
> commit right now
> because it overlaps with my changes for the marker
> problem where I still
> hope for another comment.
> 

Re: Markers added to the wrong page

[Glen Mazza]

Jeremias,

I don't see the need for the bBogus variable/isBogus()
method, because in the three or four places where the
value of this variable is actually *being used*, it is
just set to :

bBogus = !bp1.generatesAreas(); 

So it appears you can just rely on
"!bp1.generatesAreas()" in these places
instead--perhaps just commenting the conditional that
bogus areas are being ignored--and we can worry about
getting rid of the actual bogus areas later (when
overall team grokkage in this part of the code
improves).

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I've got a possible fix for the problem. But I don't
> know if it's not
> too much of a hack. At least it somehow feels like a
> hack. Any comments
> about the attached patch? Obviously, some javadocs
> are missing and the
> naming could probably be improved but this is just
> an idea how this
> could be fixed.
> 
> IMO it would be nicer if these "bogus" areas as I
> call them wouldn't be
> constructed at all. I experimented with such an
> approach but the code
> got far too complicated with too much
> copy/paste/modify. And I also
> didn't manage to make it work. On the other side
> these special areas
> are not a big problem since there are relatively few
> of them.
> 
> Still interested in opinions and ideas Thanks!
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

[Glen Mazza]

Jeremias,

We are using this pageCount statistic only at
endDocument() in ATH, i.e., when the document is
complete.  Any problem with us just relying on the
rootFObj.getRunningPageNumberCounter() in
endDocument() instead of this page-by-page callback
(i.e., get rid of pageCount in ATH)?  I would like to
keep things as simple as possible in ATH and PSLM.

Thanks,
Glen  

--- [EMAIL PROTECTED] wrote:

> jeremias2005/02/03 12:44:45
> 
>   Modified:src/java/org/apache/fop/area
> AreaTreeHandler.java
>   Log:
>   Add a facility for the PageSequenceLayoutManager
> to notify about a new page being added so the
> rendering statistics work again.
>   

Re: Markers added to the wrong page

[Glen Mazza]

Can't add much here, but I do remember noticing the
bogus areas being created when I was trying to fix
spacing about a year ago.  And, yes, I do agree it
would be better if our algorithms did not need them to
be created.

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I've got a possible fix for the problem. But I don't
> know if it's not
> too much of a hack. At least it somehow feels like a
> hack. Any comments
> about the attached patch? Obviously, some javadocs
> are missing and the
> naming could probably be improved but this is just
> an idea how this
> could be fixed.
> 

Re: Background images

[Glen Mazza]

Jeremias Maerki wrote:
Team,
I'm going to implement background images as one of my next steps. I
found that even in 1.1 WD there's no way to scale the background image.
Should we skip that or should we define our own properties? Maybe Glen
wants to talk to the WG about that.
Jeremias Maerki
 

Pardon me, forgot to ask:  where did the background images need to be 
implemented (i.e., which FO's needed them that the spec doesn't support)?

Thanks,
Glen

Re: (housekeeping) need Compare class, TestConverter.getLogger()/.setLogger()?

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> 
> On 22.01.2005 18:18:06 Glen Mazza wrote:
> > Hello--three questions:
> > 
> > Is anyone using the get/setLogger() methods within
> > TestConverter?  (It is coded to use a SimpleLog by
> > default.)  I think these two methods are holdovers
> > from when we switched from the Avalon
> Logger--which
> > needed these methods--to the Commons Logger--which
> > doesn't.
> 
> Not really.
> 

It's gone.

> > Also, is the tools.anttasks.Compare class ready
> for
> > the CVS attic now?--I don't see it anywhere in
> use.
> 
> I do. examples\fo\build.xml. Although IMO this
> approach isn't really
> helping. Binary comparison of generated PDF and PS
> files fails as soon
> as there's a tiny change even if it's only an
> additional space somewhere.
> The output should be compared visually.
> 

I've "promoted" the class a bit to FileCompare.java,
and had TestConverter call it instead of implementing
its own file compare functionality.

I was unaware that the Examples directory is also used
for FOP testing, and share your general concern with
byte-by-byte testing.

Just FYI, apparently (my company's W3C membership
allows me view the XSL SG ML) the XSL SG is planning
on having a 1.1 Test Suite (I guess) similar to what
they already have in 1.0 [1].  I hope FOP can play a
role in this for 1.1 as we did for 1.0--perhaps we
will have new cases to donate. 

[1] http://www.w3.org/Style/XSL/TestSuite/


> > Also Java question here (probably Jeremias would
> > know):  Why in anttasks.RunTest.runConverter() do
> we
> > use Class.forName() & .newInstance(), etc., to
> > activate an instance of TestConverter rather than
> just
> > "hard-code" a TestConverter instance instead?  (We
> > also do this in runReference() for Fop itself--I
> don't
> > why things are done this way though.)
> 
> To establish a different class loader for the test
> runs. If you
> hard-coded this the TestConverter wouldn't find FOP
> that was set up in a
> separate class loader.
> 

I understand now--thanks.  Just added a comment in TC
to that effect should others also be curious about
this.

Thanks,
Glen

Re: Layout dimension mechanism

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> I'm beginning to think that the layout dimensions
> should be held and provided
> by the layout managers instead of the FObjs. 

(learning here...)

Can you point me towards FObjs which are currently
holding the layout dimensions -- I want to try to
understand more of what you're talking about.

I assume you mean the ipd and bpd values only, or are
there other values which constitute "layout
dimensions"?  I'm not certain of the range of values
that layout dimensions consist of.


> To
> evaluate a
> percentage-enabled value the layout manager would
> have to call
> getLength() with some kind of context object that
> allows it to fetch the
> right base values for percentage calculations. 

I assume you're referring to "property contexts" as in
[1] below, correct?

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N6968-Property-Context

Thanks,
Glen

(housekeeping) need Compare class, TestConverter.getLogger()/.setLogger()?

[Glen Mazza]

Hello--three questions:

Is anyone using the get/setLogger() methods within
TestConverter?  (It is coded to use a SimpleLog by
default.)  I think these two methods are holdovers
from when we switched from the Avalon Logger--which
needed these methods--to the Commons Logger--which
doesn't.

Also, is the tools.anttasks.Compare class ready for
the CVS attic now?--I don't see it anywhere in use.

Also Java question here (probably Jeremias would
know):  Why in anttasks.RunTest.runConverter() do we
use Class.forName() & .newInstance(), etc., to
activate an instance of TestConverter rather than just
"hard-code" a TestConverter instance instead?  (We
also do this in runReference() for Fop itself--I don't
why things are done this way though.)

Thanks,
Glen

Re: Background images

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> Team,
> 
> I'm going to implement background images as one of
> my next steps. 

Good.

> I
> found that even in 1.1 WD there's no way to scale
> the background image.

Jeremias, please do another scan first of the 1.1
document--thankfully it's all in one HTML file--search
for both "scale" and "scaling" throughout to (1) make
sure that is the case (there appear to be some new
properties and even formatting objects related to
scaling), and (2) to see if there is any scaling logic
that you're contemplating that may be applicable in
other areas as well.

Next, you may wish to check the AntennaHouse and
RenderX extension element/attribute list.  There may
be something you can learn there about background
scaling, also when you send emails to the xsl-editors
list saying "[insert commercial company here] already
does this", etc., it will carry more weight.


> Should we skip that or should we define our own
> properties? 

I don't care either way.  Although I don't understand
why the specification doesn't already handle
background image scaling.  Something is rotten in the
State of Denmark here--this would seem to be a common
need.


> Maybe Glen
> wants to talk to the WG about that.
> 

Would be delighted.  But imaging issues are beyond my
scope, and it's about time the WG learn more about you
as well.  Please do so, also mention that you're from
FOP as well please.  (Not that you need my
permission.)

(This is gonna be great--with both of us sending
comments to the W3C, we can use a good-cop/bad-cop
technique to persuade them.  Guess which role I want
to play? ;)

Thanks,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/xml XMLRenderer.java

[Glen Mazza]

I don't think this is needed (unless I'm missing your reasoning here.)  
The validation in the FO Tree would raise errors otherwise, at least one 
page-sequence being required by the fo:root FO.  The validation scheme 
was designed so you don't need subsequent safety checks further downstream.

Glen
[EMAIL PROTECTED] schrieb:
jeremias2005/01/19 13:45:07
 Modified:src/java/org/apache/fop/render/xml XMLRenderer.java
 Log:
 Safety check
 
 Revision  ChangesPath
 1.38  +3 -1  xml-fop/src/java/org/apache/fop/render/xml/XMLRenderer.java
 
 Index: XMLRenderer.java
 ===
 RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/xml/XMLRenderer.java,v
 retrieving revision 1.37
 retrieving revision 1.38
 diff -u -r1.37 -r1.38
 --- XMLRenderer.java	18 Jan 2005 08:55:58 -	1.37
 +++ XMLRenderer.java	19 Jan 2005 21:45:07 -	1.38
 @@ -313,7 +313,9 @@
   * @see org.apache.fop.render.Renderer#stopRenderer()
   */
  public void stopRenderer() throws IOException {
 -endElement("pageSequence");
 +if (startedSequence) {
 +endElement("pageSequence");
 +}
  endElement("areaTree");
  try {
  handler.endDocument();
 
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

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

[Glen Mazza]

Yes, I think that's my fault. I believe that was
related to the space-before and space-after properties
which I was trying (unsuccessfully) to fix.  This is a
very complex portion of the code.

Glen

--- [EMAIL PROTECTED] wrote:

> jeremias2005/01/17 10:59:50
> 
>   Modified:src/java/org/apache/fop/layoutmgr
> BlockLayoutManager.java
>   Log:
>   Adding todo item for a static variable.
>   
>   Revision  ChangesPath
>   1.37  +1 -4 
>
xml-fop/src/java/org/apache/fop/layoutmgr/BlockLayoutManager.java
>   
>   Index: BlockLayoutManager.java
>  
>
===
>   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/BlockLayoutManager.java,v
>   retrieving revision 1.36
>   retrieving revision 1.37
>   diff -u -r1.36 -r1.37
>   --- BlockLayoutManager.java 12 Jan 2005 12:03:00
> - 1.36
>   +++ BlockLayoutManager.java 17 Jan 2005 18:59:50
> - 1.37
>   @@ -22,13 +22,9 @@
>import java.util.List;
>
>import org.apache.fop.datatypes.PercentBase;
>   -import org.apache.fop.fo.FONode;
>   -import org.apache.fop.fo.FObj;
>   -import
> org.apache.fop.fo.properties.CommonMarginBlock;
>import org.apache.fop.fonts.Font;
>import org.apache.fop.area.Area;
>import org.apache.fop.area.Block;
>   -import org.apache.fop.area.BlockParent;
>import org.apache.fop.area.LineArea;
>import org.apache.fop.traits.SpaceVal;
>import org.apache.fop.traits.MinOptMax;
>   @@ -54,6 +50,7 @@
>*/
>private MinOptMax foBlockSpaceBefore = null;
>// need to retain foBlockSpaceAfter from
> previous instantiation
>   +//TODO this is very bad for multi-threading.
> fix me!
>private static MinOptMax foBlockSpaceAfter =
> null;
>private MinOptMax prevFoBlockSpaceAfter =
> null;
>
>   
>   
>   
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 

Re: marketing Defoe

[Glen Mazza]

(Don't let Peter rattle you, Jeremias--he's just
jealous that I've found more XSL spec bugs than him. 
;)

Our delays are mostly related to advanced issues
concerning layout, and the type of parser used doesn't
have much effect on this issue.  So I don't share
Peter's conviction that FOP is in need of a major
design overhaul--or that Defoe's layout is as complete
as it needs to be either, for the matter.  Both sides
have a lot of work to do.

Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Peter,
> 
> this is not about the question whether I disagree
> with the assessment.
> You might be right, you might be wrong. I can't
> tell, yet, because I'm
> still working my way into the new layout engine. My
> reaction was
> triggered by the way you said these things, not by
> any technical
> statement. But as I said, I may be overreacting and
> I may not have
> filtered everything through all the "is-written" and
> "is-in-foreign-language" filters.
> 

bring XSL 1.1 fo:flow-map into HEAD?

[Glen Mazza]

Team,

The bookmarks are finished.  In doing them, I found
perhaps about 10 bugs in the 1.1 spec with them
(mostly typos but a few functional ones as well), and
I sent emails to the XSL-Editors list about those.

Next, I'd like to start this weekend looking into
bringing fo:flow-map [1] into our 1.0 release.  Any
objections?

Thanks,
Glen

[1] http://www.w3.org/TR/xsl11/#fo_flow-map

Re: Checking for OutputSource for renderer overrides

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > 
> > Personally, I would rather we get rid of
> > RendererFactory and put the logic back where it
> > was--in FOTreeBuilder and RenderPagesModel.  This
> > functionality is just too specific to be reused
> > elsewhere in FOP.
> 
> I don't see your point and you were the only one who
> complained about
> the RendererFactory. I still think the
> RendererFactory is A Good Thing 
> (tm). It reduces imports, dependencies and number of
> lines in
> FOTreeBuilder and RenderPagesModel

I don't see how adding a class in the renderer
package, which fo.FOTreeBuilder and
area.RenderPagesModel now must access in order to do
their work, reduces the number of dependencies and
imports.  (Indeed, we now have a new dependency: 
RendererFactory.)

Also, the fact that the new solution has more classes
and more overall LOC would appear to invalidate the
benefit of there being fewer LOC in FOTB and RPM as a
result. 

Usually for a factory pattern, its biggest selling
point is in reuse--i.e., centralizing certain logic so
it doesn't have to be duplicated in multiple places. 
But there is no reuse being realized here.  (Perhaps
you see some in the future however.)


> and centralizes
> instantiation of the
> Renderers and FOEventHandler in one place where they
> are easier to find
> for those unfamiliar with FOP sources.
> 

True--but is that an acceptable OO design?  Can we
indeed just rip out disparate business logic from
various classes and place them into one class for
convenience?  Is there really an object that would
know which FOEventHandler an FOTreeBuilder requires
*and* which Renderer the RenderPagesModel needs? 
(They are different issues, after all.)

RendererFactory seems to be a C-language-like non-OO
collection of business logic, an artificial object,
and the fact that it has no class or instance
variables would appear to add to that argument.

Still, this is just one additional class so hardly an
architecture-breaker.  (And I can see the convenience
regardless of having them together in one place.)  So
just take this posting as a desire on my part to
further clarify my concerns about this class.

Thanks,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination/bookmarks Bookmark.java BookmarkTitle.java BookmarkTree.java

[Glen Mazza]

True, but for all times save the first, it ends up
being a cached-value "get".  Repeated across all the
FO's, the ratio would appear to be about 90% get/10%
original make.  I wanted to stress in the code that we
are not necessarily "making" a brand-new property
object each time it is applicable for an FO.

Ultimately, whether a property needs to be "maked"
(made) or is cached is just an internal implementation
issue with that get() method.  (e.g., we could choose
to create all the properties up-front, and then
implement the get() as 100% retrieval instead of
90/10.)

Glen

--- Simon Pepping <[EMAIL PROTECTED]> wrote:

> On Tue, Jan 11, 2005 at 12:07:53AM -,
> [EMAIL PROTECTED] wrote:
> > gmazza  2005/01/10 16:07:53
> > 
> >   Modified:src/java/org/apache/fop/fo
> Constants.java
> > FOPropertyMapping.java
> PropertySets.java
> >src/java/org/apache/fop/fo/flow
> MultiCase.java
> >   
> src/java/org/apache/fop/fo/pagination/bookmarks
> > Bookmark.java
> BookmarkTitle.java BookmarkTree.java
> >   Log:
> >   2.) Switch from "makeEnumProperty" to slightly
> more intuitive "getEnumProperty" in
> FOPropertyMapping.
> 
> It does really make a property value, which is held
> as in the member
> enums in the property maker:
> 
> private Property makeEnumProperty(int enumValue,
> String text) {
> if (enums == null) {
> enums = new Property[ENUM_COUNT+1];
> }
> if (enums[enumValue] == null) {
> ==> enums[enumValue] = new
> EnumProperty(enumValue, text); <===
> }
> return enums[enumValue];
> }
> 
> Regards, Simon
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.nl
> 
> 

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

[Glen Mazza]

--- Glen Mazza <[EMAIL PROTECTED]> wrote:

> BTW, would Jeremias' proposal 
> effect future
  ^^

oopsaffect ;)

Glen

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

[Glen Mazza]

BTW, would Jeremias' proposal effect future
implementation of the property value functions[1]?

Thanks,
Glen

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8624-Property-Value-Functions

--- Simon Pepping <[EMAIL PROTECTED]> wrote:

> Section 5.3.2 of the spec is really hard to
> understand. I combine it
> with 5.1.4 about Inheritance. Then my guess is this:
> 
> A test file
>   
> A test
> file
>   
> 
> 
> The computed value of start-indent on the outer
> block is 'start-indent
> = inherited_value_of(start-indent) +
> margin-corresponding +
> padding-corresponding + border-corresponding-width'
> = 0 + 1pc + 0 +
> 0. The computed value of start-indent on the inner
> block is
> 'start-indent = inherited_value_of(start-indent) +
> margin-corresponding + padding-corresponding +
> border-corresponding-width' = 1.5pc + 1pc + 0 + 0.
> 
> In this case:
> 
> A test file
>   
> A test
> file
>   
> 
> 
> the computed value of start-indent on the outer
> block is 'start-indent
> = inherited_value_of(start-indent) +
> margin-corresponding +
> padding-corresponding + border-corresponding-width'
> = 0 + 1pc + 0 +
> 0. The computed value of start-indent on the inner
> block is
> 'start-indent = inherited_value_of(start-indent) +
> margin-corresponding + padding-corresponding +
> border-corresponding-width' = 1pc + 1pc + 0 + 0. The
> inherited value
> uses the calculated value (sect. 5.1.4). That is the
> value that should
> be returned by
>
pList.getParentPropertyList().get(Constants.PR_START_INDENT).getLength().
> 
> The inherited value should not be stored, but used
> in the computation
> of the property value. This should be implemented by
> the property
> maker.
> 
> When I run the above examples in a debugger, I find
> that the computed
> start-indent values CommonMarginBlock.startIndent
> are exactly like I
> argue above they should be. There does not seem to
> be a need to add
> the inherited value later; the property maker
> already has done so. See
> IndentPropertyMaker.compute(PropertyList). It uses
>
propertyList.getInherited(baseMaker.propId).getNumeric())
> to get the
> inherited value. Earlier FOP developers understood
> this part well.
> 
> If you find wrong results, then the problem must be
> elsewhere.
> 
> Is there a book or treatise on these subjects, where
> we can read how a
> knowledgeable author interprets these difficult
> parts of the spec?
> 
> Regards, Simon
> 
> On Fri, Jan 07, 2005 at 09:26:15AM +0100, Jeremias
> Maerki wrote:
> > Finn or Simon,
> > 
> > would you please check if it is acceptable to put
> the inherited values
> > directly into the CommonMarginBlock? It might have
> been cleaner to
> > always get the value via the parent FO but I think
> in this case it helps
> > simplifying the code in TraitSetter and
> BlockLayoutManager.
> > 
> > On 07.01.2005 09:21:21 jeremias wrote:
> > > jeremias2005/01/07 00:21:21
> > > 
> > >   Modified:   
> src/java/org/apache/fop/fo/properties
> CommonMarginBlock.java
> > >src/java/org/apache/fop/layoutmgr
> TraitSetter.java
> > > BlockLayoutManager.java
> > >   Log:
> > >   Bugfix for start-indent calculation for nested
> blocks. The inherited start-indent wasn't taken into
> account as described in 5.3.2 of the spec.
> > >   Minor style and javadoc improvements on the
> way.
> > 
> > 
> > 
> > >   Revision  ChangesPath
> > >   1.5   +34 -2
>
xml-fop/src/java/org/apache/fop/fo/properties/CommonMarginBlock.java
> > >   
> > >   Index: CommonMarginBlock.java
> > >  
>
===
> > >   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/CommonMarginBlock.java,v
> > >   retrieving revision 1.4
> > >   retrieving revision 1.5
> > >   diff -u -r1.4 -r1.5
> > >   --- CommonMarginBlock.java  28 Oct 2004
> 10:00:24 -1.4
> > >   +++ CommonMarginBlock.java  7 Jan 2005 08:21:21
> - 1.5
> > >   @@ -1,5 +1,5 @@
> > >/*
> > >   - * Copyright 1999-2004 The Apache Software
> Foundation.
> > >   + * Copyright 1999-2005 The Apache Software
> Foundation.
> > > * 
> > > * Licensed under the Apache License, Version
> 2.0 (the "License");
> > > * you may not use this file except in
> compliance with the License.
> > >   @@ -70,6 +70,16 @@
> > >public Length endIndent;
> > >
> > >/**
> > >   + * The inherited "start-indent" property.
> > >   + */
> > >   +public Length inheritedStartIndent;
> > >   +
> > >   +/**
> > >   + * The inherited "end-indent" property.
> > >   + */
> > >   +public Length inheritedEndIndent;
> > >   +
> > >   +/**
> > > * Create a CommonMarginBlock object.
> > > * @param pList The PropertyList with
> propery values.
> > > */
> > >   @@ -84,5 +94,27 @@
> > >
> > >startIndent =
> pList.get(Constants.PR_START_INDENT).getLength();
> > >endIndent =
> 

Re: Checking for OutputSource for renderer overrides

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I think you're confusing things. 

Yes, I think I was.

> If someone embeds FOP in
> his/her application the
> not supplying an OutputStream when a renderer needs
> one is a bug and so
> it doesn't matter if the error message comes early
> or only when the
> renderer is started (Renderer.startRenderer()).
> 

OK, I see what you're saying here--it would be one
time only programmatic change for the user to fix his
embedded code.

If I understand you correctly, all that would be
needed for renderer overrides is to just raise an
exception within Renderer.startRenderer(OutputStream)
if the OutputStream is null (for those renderers
requiring an OutputStream).  Arguably, the Renderer
should be programmed to do that anyway, even if it is
checked earlier.  That makes sense--and I now agree
with your previous change of not checking for an
OutputStream when the RendererOverride is set.  Thanks
for the clarification.

(I still prefer the one-line check in RendererFactory
for our *hardcoded* renderers--for
documentation/comprehension reasons, and it gives us a
common error message for our own renderers.)


> 
> Ok, here's your technical justification:
> I'm certain you've seen the new test subsystem for
> the layout engine
> where I analyze the output of the area tree
> renderer. If I wrote the
> area tree to an OutputStream I'd have to parse it
> again later, so I get
> a DOM I can evaluate XPath statements on. If I can
> pass in a
> TransformerHandler into the XMLRenderer the renderer
> can simply send SAX
> events which are used by a Transformer to build a
> DOM from (directly).
> 

I haven't looked at your test framework yet here--I
hope to be able to do so sometime soon.  I'm sure it's
very good.  I still have a little bit more bookmark
stuff to do.


> So here's another one. Do you know about SVG Print?
> An SVG renderer
> could send the generated SVG using SAX. That way a
> developer could run
> the generated SVG through an XSLT post-processing
> without having to
> reparse the generated SVG. That's a place where
> speed is very important
> and an OutputStream-only system would be suboptimal.
> 

I don't completely understand this idea (Namely, how
can you send "generated SVG using SAX"--wouldn't that
mean the "generated SVG" would have to be in XML
format?)--but it doesn't matter anyway because, again,
I don't have a problem with your validation change.  

Thanks,
Glen

Re: Checking for OutputSource for renderer overrides

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> You're right, my change was suboptimal. When I think
> about this I must
> say that I'd prefer to remove that check entirely
> and let the individual
> renderers check if they have everything to write to
> their target. 

I don't think so, because we need early checking at
the command line and embedded usage to make sure all
input is OK before proceeding.  That's a very common
paradigm used in just every compiler or text
processor.  FOP has been doing this for several years.

> The
> renderer knows best what it needs. 

I don't think so--all of the non-AWT based renderers,
for the past seven years, require a OutputSource and
only an OutputSource.  We never had a user complaint
on that or a request otherwise for a change.  It has
never been a problem.

BTW, you are glossing over how one can generate a PDF
or any other output document without using an
OutputSource.  Absent user demand or a technical
explanation from you on this point, I can't really
support your position.


> Having this check
> in the
> RendererFactory only puts renderer-dependant logic
> in a place that is
> renderer-agnostic. If it's ok by you I'm going to
> fix that.
> 

Personally, I would rather we get rid of
RendererFactory and put the logic back where it
was--in FOTreeBuilder and RenderPagesModel.  This
functionality is just too specific to be reused
elsewhere in FOP.


> I see two possibilities: Adding a RENDER_CUSTOM
> constant or having a Fop
> contructor without this constant.
> 

RENDER_CUSTOM is OK.  (But there can also be
advantages of still encouraging users to use
RENDER_PDF, for example, if the override is still a
PDF renderer.  e.g., checking for an output source or
other business logic.)

> Please keep in mind that if you simply define a new
> API, release and
> then change according to user feedback you can't
> just change the API in
> an incompatible way again. You'd have to provide
> API-compatibility
> within smaller version steppings. See for example
> [1].
> 

Indeed, this reason is why I'm against adding API
methods without an explanation of the technical needs
for them, or bothering to point to user demand or
requests for them first.  Once it's there, we're
forever stuck with it unless we do another major
release.  So I think you should be keeping versioning
etc. in mind as well.

This is also the reason why we are using a simple
JAXP-based API--something we know that we will support
now and forever.  (Adding to an API is always OK, as
more functionality and enhancements are provided--it
is *subtracting* from it that causes the problem.) 
Additional functionality should be based on user
requests and needs, not every possible theoretical
usage.

Thanks,
Glen

Checking for OutputSource for renderer overrides

[Glen Mazza]

Jeremias,

Per your change here [1], no longer checking for an
OutputStream variable if the Renderer is overridden:
The render constant chosen is irrelevant when the
renderer is overridden.  So the embedded programmer
can rely on RENDER_AWT or _PRINT for those
comparatively rare cases of not needing an
OutputStream (and, indeed, that would be the
appropriate render type in most of those instances
anyway.) 

People will be supplying an OutputSource for PDF-type
generation--FOP has been requiring it for six years
now with nary a complaint.  If you remove that check,
and they forget to programmatically supply an output
stream (a fairly common newbie mistake), errors in FOP
will occur without informative messages.  

So I would advise the usage of RENDER_AWT/_PRINT for
non-OutputStream usage for overridden renderers, while
returning the check for the RENDER_PDF et al ones. 
That should be sufficient for our next release, after
which we can then consider "what's next" based on user
feedback.

Glen

[1]
http://marc.theaimsgroup.com/?l=fop-cvs&m=110495921529754&w=2

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/properties BoxPropShorthandParser.java

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> 
> Using casts will prevent us from adding property
> proxies, which i 
> suspect will be needed.
> 

 What's a "property proxy"?  Can you 
elaborate on that--give a simple scenario of it?

Thanks,
Glen

Re: fo.InlineLevel -- make abstract?

[Glen Mazza]

Done.  Thanks both for the quick response.

Glen

--- Simon Pepping <[EMAIL PROTECTED]> wrote:

> I agree as well.
> 
> Regards, Simon
> 
> On Tue, Jan 04, 2005 at 09:39:14AM +0100, Jeremias
> Maerki wrote:
> > I think, you are right. They should be abstract.
> > 
> > On 04.01.2005 00:47:29 Glen Mazza wrote:
> > > Any problem with making fo.InlineLevel an
> abstract
> > > class?  Any reason why you made it
> instantiable--or
> > > was this just an oversight?  (Actually, anyone
> know
> > > why we're not making FObj and FObjMixed abstract
> as
> > > well?  I might be missing something here...)
> > 
> > 
> > 
> > Jeremias Maerki
> > 
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.nl
> 
> 

Re: Implementing text-decoration

[Glen Mazza]

I looked at the code and I can't see anything wrong
with your suggestion.  Unfortunately I'm far from an
expert in this area of the code.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I'm currently looking at implementing
> text-decoration. ATM it's
> specified as an EnumProperty but should be more like
> a set of enums with
> certain validation rules applied. I'm unsure about
> the approach. If
> anyone already has an idea how it should look like
> I'd appreciate any
> insight.
> 
> My first idea was to implement a special property
> class
> (TextDecorationProperty) that handles the conversion
> of a ListProperty
> of NCNames to an internal set of variables while at
> the same time
> validating the enum combinations. I think my
> approach would work even if
> it look a bit awkward. But I wanted to check first
> so I didn't implement
> something really ugly.
> 
> Jeremias Maerki
> 
> 

Re: [RT] FOP RTF edition

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> I'd like to test the waters and see what you guys
> think about separately
> releasing the RTF part, or in other words: FOP RTF
> edition. 

My $0.02:  Looks like busywork--I don't see how this
would help you or any other committer.

I would be concerned about burdening current
committers with this work, as well as scaring away
prospective ones.  The deep thinkers that are needed
to get layout et al done are generally not attracted
to the mundane tasks that a FOP RTF would require.

> It might be
> a good sign to our users that our project's not
> dead. 

Even if some think that way now, they'll come back
when it's done. 

Glen

Re: New year -> update copyright years

[Glen Mazza]

{Sigh.}  Jeremias, you are so particular--anyway,
Peter, will you please give Jeremias said greeting so
he can proceed?

Thanks,
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> I've
> got a script from Thomas to do that but I need a
> good day to do that. :-)
> 
> Jeremias Maerki
> 

fo.InlineLevel -- make abstract?

[Glen Mazza]

Simon,

Any problem with making fo.InlineLevel an abstract
class?  Any reason why you made it instantiable--or
was this just an oversight?  (Actually, anyone know
why we're not making FObj and FObjMixed abstract as
well?  I might be missing something here...)

Thanks,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java

[Glen Mazza]

+1!  Ausgezeichnet!  Danke...

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Sorry, I'm so used to using A-F Enums that I didn't
> think about that.
> I've fixed this and hope that you can agree with my
> change now.
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java

[Glen Mazza]

Jeremias,

Would you please elaborate on the need for this?  I
want to make sure that adding an additional dependency
on the Avalon project is passing a cost-benefit
analysis here.

We're not a fluffy hi-level word processing system
--we are a very low-level application (like a
compiler), that is in turn will be integrated into
other applications.  Therefore we have to be careful
not to include gratuitous linkages to other libraries.
 (That we already--currently--use Avalon for
configuration does not excuse us from this principle. 
Linkages should be kept at a minimum.  For example, we
had an option of using Commons Configuration instead
of Avalon.  Now, if we do so, we're still required to
keep Avalon just because of your change below.)

What is lost if we don't link to Avalon here?  How
often have we failed by relying on Java variables? 
How come Xalan and Xerces can work without Avalon
variables but FOP can't?

Also, why is the Cocoon Team in error for trying to
detach themselves from Avalon[1]?  Why are those 15
committers wrong?

I'm -1 (veto) on this change.

Glen

[1]
http://marc.theaimsgroup.com/?t=10800483371&r=1&w=2

--- [EMAIL PROTECTED] wrote:
>
>   Made the LayoutDimension keys a subclass of Avalon
> Framework's Enum to make the thing more
> debugger-friendly and more type-safe.
>   

Re: Happy New Year

[Glen Mazza]

2005?  Oooh--what's it like?--is everyone going around
in space ships?  ;)

Glen (7 1/2 hours more to go)

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
>
> Greetings from the future.  Happy New Year.  Welcome
> to 2005.
> Peter
> 

Re: Tweaking the FO class hierarchy

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> I'm currently playing around with external-graphic
> and
> instream-foreign-object as you may have seen. It's
> my attempt to dive
> into the whole layout engine thing.
> 

Yes, I was very surprised and happy to see you working
in layout!

> I realize that there are a lot of similarities (and
> redundancy) between
> the two classes (and even their LM counterparts). I
> wonder if I should
> create a common (abstract) base class for the two.

They are similar enough that that would be an
acceptable design.  We already do the same with
fo:static-content and fo:flow (more or less suggested
by the spec, which IIRC declares them both flows), and
the region classes.


> Is there anything
> that speaks against that other than it may be
> appropriate to check for
> additional refactoring possibilities? 

Yes, be careful that the decision is not just based on
coincidentally common functionality.  They should be
closely similar objects.  (Also too many classes, even
if reduced LOC in each as a result, can make FOP seem
larger and more complex than it actually is, which can
intimidate newbies.)

For a silly example, if both class Teacher and class
AlpsMountain happen to have a "getLocation()" method,
it wouldn't necessarily follow that we should have an
abstract TeacherOrAlpsMountain base class.  OTOH,
class Teacher, class Policeman should probably extend
a common abstract class Worker.

The recommendation does not declare any relationship
between instream-foreign-object and external-graphic,
other than that they are both formatting objects. 
This two-tier hierarchy is already present in FOP, as
we  have them both extend FObj.  But, again, they are
close enough that an abstract base class may not be
such a bad idea.

Glen

Re: Horizontal Line

[Glen Mazza]

Please use FOP-USER, to help in future searching of
the ML archives.  Developers are on both lists.

Glen

--- "Puppala, Kumar (LNG-DAY)"
<[EMAIL PROTECTED]> wrote:

> Hello All,
>  Does anyone know what FO tags I need to use to
> generate a horizontal line
> given the width, color and justification for this
> line?
> 
> Thanks,
> Kumar Puppala
> 
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

[Glen Mazza]

--- Simon Pepping <[EMAIL PROTECTED]> wrote:

>
> I have contained
> its effect by catching the exception, and have not
> explored the stack
> of methods that may need to declare the throwing of
> an exception. That
> is a problem in its own right, to be solved at
> another moment.
> 

OK...sorry to be rushing you.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

[Glen Mazza]

--- Simon Pepping <[EMAIL PROTECTED]> wrote:

> Glen,
> 
> In my view the FO system knows nothing about the LM
> system. 

It appears that you've just made a friend in Colorado.
 ;)

> That is
> how the LM system can be pluggable. 

Not really, it can still be pluggable if you have
addLayoutManager() in each FO, providing you pass in
the LMMaker.  (Minor point though that doesn't detract
from the rest of your response here.)

> The FO system
> sets itself up and
> waits if any subsequent system finds it useful. Its
> only connection
> with the subsequent system is that it sends FO
> events to its
> FOEventHandler.
> 

OK.

> The LM system, OTOH, knows about the FO system,
> because that is its
> input. _This_ LM system chooses not to create a LM
> when it finds that
> the FOText node is empty. Another LM system may do
> otherwise.
> 

True.

> It is true that the use of endIndex and startIndex
> is too
> detailed. Those details may be hidden behind a
> method hasText(),
> similar to FObj.getChildren() returning null or not,
> which is used by
> other LMMakers.
> 

OK.  In the future, we may wish to have a generic
isEmpty() function in each FO, that the LM Maker can
use to determine if a LM should be created.  How
isEmpty() would be implemented would then be up to
each FO.

Thanks,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

[Glen Mazza]

This doesn't seem appropriate--the business logic to
determine whether or not a layout manager is needed
for a particular FO should be within that FO object,
where it reads its own private variables--in whatever
manner it is internally constucted--and makes its own
determination.

Otherwise (1) you're forcing the logic below to be
repeated in everyone else's subclasses of the Maker
method, also (2) it forces the internal state of each
FO (endIndex, startIndex) to be public, furthermore,
you're forever constraining all implementations of
FOText objects to have these method variables. 
Someone could completely wish to redo FOText, and not
have a startIndex and endIndex indicators.  With this
design, this is no longer possible.

Why not retain the addLayoutManager() method within
each FO, but just have it call this mapping function
to determine which LayoutManager object to create? 
Why did you consider it better to strip out the
addLayoutMangers() from the FO's?

Glen

--- [EMAIL PROTECTED] wrote:

+public static class FOTextLayoutManagerMaker
extends Maker {
  +public void make(FONode node, List lms) {
  +FOText foText = (FOText) node;
  +if (foText.endIndex - foText.startIndex
> 0) {
  +lms.add(new
TextLayoutManager(foText));
  +}
  +}
  +}

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

[Glen Mazza]

Simon,

Why aren't these fatal errors--what's the gain in
having FOP continue running in an invalid state?

One-in-a-million bugs like these that occur for
inexplicable reasons should raise an
IllegalStateException and halt.  FOP should not
continue running after catastrophic failures.

Glen

--- [EMAIL PROTECTED] wrote:

>   +} catch (FOPException e) {
>   +log.error
>   +("Failed to create a
> StaticContentLayoutManager for flow "
>   + + flow.getFlowName()
>   + + "; no static content will be
> laid out:");
>   +log.error(e.getMessage());
>   +return;
>   +}
>lm.initialize();
>lm.setRegionReference(reg.getRegion());

..

>if (pageSequence.getMainFlow() != null) {
>   -PageSequenceLayoutManager pageSLM =
>   -(PageSequenceLayoutManager)
>   +PageSequenceLayoutManager pageSLM;
>   +try {
>   +pageSLM =
> (PageSequenceLayoutManager)
>   
>
getLayoutManagerMaker().makeLayoutManager(pageSequence);
>   +} catch (FOPException e) {
>   +log.error("Failed to create a
> PageSequenceLayoutManager; no pages will be laid
> out:");
>   +log.error(e.getMessage());
>   +return;
>   +}

Re: arabic pdf

[Glen Mazza]

The squeaky wheel doesn't always get the grease.  Send
your question to FOP-USER.

Glen

--- nafise hassani <[EMAIL PROTECTED]> wrote:

>  Anybody knows how to Create PDF with Arabic words? 
> 
> Seems FOP-0.20.5 cannot handle Arabic
> glyphs/ligature properly. It can only display the
> Arabic characters but the rules to ligate them
> together cannot be displayed.
> 
> Any other software or tool that we can use for this
> kind of task?  
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr LayoutManagerMaker.java LayoutManagerMapping.java AbstractLayoutManager.java ContentLayoutManager.java LayoutManager.java PageSequenceLayoutManager.java

[Glen Mazza]

Simon, 

Will you please comment this method--the purpose of
checkLength is not obvious in meaning at least to me.

Thanks,
Glen

--- [EMAIL PROTECTED] wrote:

>   public LayoutManager makeLayoutManager(FONode
> node, boolean checkLength) {
>   List lms = new ArrayList();
>   makeLayoutManagers(node, lms);
>   LayoutManager lm = null;
>   if (checkLength && lms.size() != 1) {
>   log.error("More than 1 LayoutManager
> for class "
> + node.getClass()
> + "; 1 was requested"); 
>   } else if (lms.size() != 0) {
>   lm = (LayoutManager) lms.get(0);
>   }
>   return lm;
>   }
>   

Re: [OT] Printing the XSL WD

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> How do you guys print out the new XSL WD? I
> don't manage

haven't managed

> to print this
> document either in IE or in Firefox without having
> some of the content
> being cropped. 

I use Internet Explorer, move the browser text size to
"small" (next to the smallest) and then print
double-sided, 20 pages at a time (it's about 550 pages
total at that size.)  I haven't had a problem with the
content being cropped with this document (although
frequently IE does have that problem for some reason.)

Glen

Merry Christmas everyone!

[Glen Mazza]

Merry Christmas!
Buon Natale!
Vrolijk Kerstfeest!
Glædelig Jul!
Froehliche Weihnachten!
Zalig Kerstfeest!/Joyeux Noël!

(OK, think I got everybody...  ;-)

Regards,
Glen

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

[Glen Mazza]

--- [EMAIL PROTECTED] wrote:

> The property
>   lists are not cloned. 

For future clarity, it may be good to add this
"limitation" of FONode.clone() (and other ones you're
aware of) to its javadoc comment.

>   +/**
>   + * Perform a shallow cloning operation,
>   + * set its parent, and optionally clean the
> list of child nodes
>   + * @param parent the intended parent of the
> clone
>   + * @param removeChildren if true, clean the
> list of child nodes
>   + * @return the cloned FO node
>   + */
>   +public FONode clone(FONode parent, boolean
> removeChildren)
>   +throws FOPException {

Glen

Re: replace extension bookmarks with XSL 1.1 ones?

[Glen Mazza]

  ;-)

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
>
> Glen Mazza wrote:
> 
> > They're coming very close (I suspect in a few
> weeks at
> > the latest) to having a "Last Call" version--would
> it
> > be acceptable for you at that stage?  I don't mind
> > waiting a little longer.
> 
> Second edition of working Draft was released today
> :-)
> 
> 
> 
> Chris
> 

RE: replace extension bookmarks with XSL 1.1 ones?

[Glen Mazza]

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:

> the XSL 1.1 WD, but since that's all it is ATM, a
> 'Working Draft', changing
> their namespace might be a bit premature (?[*]),

They're coming very close (I suspect in a few weeks at
the latest) to having a "Last Call" version--would it
be acceptable for you at that stage?  I don't mind
waiting a little longer.


> unless we have some
> certainty WRT when it's going to be approved and
> will get the status of
> 'Recommendation'.
> 

I'm more comfortable with Last Call.  Last Call ->
Recommendation I suspect incurs lots of bureaucratic
delays while having few changes to the spec itself.  

At any rate, we can always drop and add XSL-NS FO
elements and properties as the spec itself is
modified.  Indeed, it's frequently the implementation
of these FO's that allows for feedback that causes
changes in the spec to occur.


> Changing the names: +1
> ... the namespace: -1
> 
> Greetz,
> 
> Andreas
> 
> [*] Surely someone here will remember MS's 'blunder'
> when they adopted an
> XSL-WD as a 'standard' too quickly...
> 

Well we can also lose in the other direction.  The
main question appears to be what's the percentage
chance of the 1.1 bookmark XSL FO's being dropped at
this stage?  If < 10-20%, perhaps best to switch now
and accept a 10-20% chance of needing to change our
code later, rather than keep it in the fox: NS and
have an 80-90% chance of needing to change it later to
the fo: NS.  

Thanks,
Glen

remove Runnable from PageSequenceLayoutManager?

[Glen Mazza]

Team,

PageSequenceLayoutManager implements Runnable,
theoretically to allow for the layout of each page
sequence on separate threads.  The more complex
logical aspects needed for this to happen (e.g., idref
resolution, page numbering) though are not
implemented, rendering this feature not very useful. 
We're not using Runnable now, and so I'd like to yank
it before the upcoming release--it is easy to place it
back in later if we do this in the future releases
(although the more extensive logic will still need to
be developed).  Thoughts?  Objections?

I don't see multithreading page-sequence layouts as a
certainty ATM because:

(1) multithreading may not be workable/worthwhile
given the layout process and the dependences of one
page sequence upon another

(2) multithreading may not buy us anything
performance-wise: instead of:

F-PS1 --> L-PS1 --> F-PS2 --> L-PS2 --> F-PS3 -->
L-PS3

(Where F-PS1 means "create FO Tree for page sequence
1"
and L-PS1 means "layout page sequence 1", etc.)

Multithreading might mean:
 
F-PS1 --> (F-PS2, L-PS1) --> (F-PS3, L-PS1, L-PS2) -->
(L-PS2, L-PS3)

But cycles spent on getting F-PS2 done earlier (i.e.,
before L-PS1 is finished) end up slowing down L-PS1 by
an equivalent rate, and because of context switching,
performance would appear to be actually worse.

(3) whether we have the multithreading at the wrong
level--i.e., normally, it would appear that the SW
that embeds FOP would do the multithreading (i.e., a
servlet which runs multiple FOP reports, one for each
thread), not FOP itself.  Having dual levels of
multithreading appear suspect to me--I doubt Xalan
goes that route.

Thanks,
Glen

replace extension bookmarks with XSL 1.1 ones?

[Glen Mazza]

Team,

Silly confirmation question here -- is the 1.1 XSL
Spec's fo:bookmark-tree, fo:bookmark, and
fo:bookmark-title [1] basically the same thing as our
fox:bookmarks, fox:outline, and fox:title,
respectively?   (i.e., they're for off-document PDF
bookmarks?)  Its mandated location [2] in the FO is
the same place where our fox: equivalents are.  (The
only issue giving me pause is that fo:bookmark
apparently generates inline areas according to the
spec [3], i.e., it appears to be something that is
*on* the document.)

Anyway, if they're equivalent, I would like to bring
these three 1.1 elements in (I'm guessing a new
pagination.bookmarks package, we can move it around
later) and drop our fox: equivalents.  Backwards
compatibility with 0.20.5 is already broken because of
the addition of fox:bookmarks in 1.0, as well as the
enforced validation scheme, so we can fortunately
focus on the best design here.

There is a differing namespace issue that will need to
be taken care of eventually but I think we can tend to
that afterwards without much hassle.  (We can handle
it now, if anyone has ideas.)  My primary goal for the
moment is to pull out our bookmark extension elements
and put in the official XSL elements (even if 1.1)
instead.

Thoughts?  Objections?

Thanks,
Glen

[1] http://www.w3.org/TR/xsl11/#d0e12873
[2] http://www.w3.org/TR/xsl11/#fo_root
[3] http://www.w3.org/TR/xsl11/#fo_bookmark

Re: Another problem with Marker.rebind()

[Glen Mazza]

- Original Message - 
From: "Peter B. West" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 08, 2004 8:20 PM
Subject: Re: Another problem with Marker.rebind()


> Oh, I'm sorry, it involves
> re-thinking the building of the FO tree, using stream parsing.

Peter, are you saying that a pull parser is more computationally powerful
than a SAX Parser--or is it just much more convenient?  I don't think pull
parsers can do more than SAX Parsers for the simple reason that you can
implement a pull parser using a SAX Parser, no?

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgrKnuthElement.java KnuthBox.java KnuthGlue.java KnuthPenalty.java

[Glen Mazza]

Sounds good.

--- Luca Furini <[EMAIL PROTECTED]> wrote:

> 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
> getPenalty() or
> getValue(), but they seemed less clear to me.
> 
> Regards
> Luca
> 
> 
> 
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr KnuthElement.java KnuthBox.java KnuthGlue.java KnuthPenalty.java

[Glen Mazza]

Luca, I think we should be using getWidth() instead of
getW(), correct?

Thanks,
Glen

--- [EMAIL PROTECTED] wrote:

>
>   +/**
>   + * Return the width of this element.
>   + */
>public int getW() {
>return width;
>}
>

Re: Info on Avalon Framework

[Glen Mazza]

 It appears we should
switch from Avalon configuration to Commons
configuration -- and then drop the Avalon library from
HEAD.  Thoughts?

Thanks,
Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Gang,
> 
> you may have heard about what happened in
> Avalon-land. Looks like the
> project has failed from a community POV. So, just
> for those who don't
> know already, Avalon Framework which we use in FOP
> has been transferred
> over to the Avalon Excalibur project
> (http://excalibur.apache.org/).
> 
> The source code is here:
>
https://svn.apache.org/repos/asf/excalibur/trunk/framework/
> 
> The announcement:
>
http://www.mail-archive.com/users@avalon.apache.org/msg05033.html
> 
> My impression is that the package will remain active
> and maintained this
> way, so actually this doesn't change anything for
> us.
> 
> Jeremias Maerki
> 
> 

Re: Good news: Jeremias has been elected as an ASF member!

[Glen Mazza]

Yes, Jeremias has been serving FOP for four years now!
[1][2]  (I think it's time for us to give him a raise
also... ;)  Congrats Jeremias!

[1] Earliest emails:
http://marc.theaimsgroup.com/?a=9723805961&r=1&w=2

[2] First email (perhaps):
http://marc.theaimsgroup.com/?l=fop-dev&m=97238032303320&w=2

Glen

--- Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:

> Hi FOP people,
> 
> 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.
> 
> I'm sure you will agree that this is well deserved,
> given all the 
> energy that Jeremias has been pouring tirelessly in
> FOP, Batik, the XML 
> federation and probably many things here that I
> don't know about.
> 
> /me happy ;-)
> 
> -Bertrand
> 

> ATTACHMENT part 2 application/pkcs7-signature
name=smime.p7s

Re: Knuth linebreaking questions

[Glen Mazza]

[Finn]
3) What is the reasoning for doing hyphenation only after threshold=1
fails. Naive common sense tells me that if the user specify hyphenation
we should do hyphenation before finding line breaks.
   

 

[Luca]
Finding hyphenation points is time-expansive (all words must be
hyphenated, not only the ones "near a line's end"), the sequence of
elements becomes longer, there are more feasible breaking points, and a
line ending with a "-" is less beautiful; so I thought that if a set of
breaking points could be find without hyphenation.
 

I've just started to read Knuth's chapter on breaking paragraphs into 
lines, and from what I've read, he considers excessive hyphenation a bad 
form.  The main benefits he gives for taking the entire paragraph into 
account when deciding where to break lines (as opposed to the more 
traditional just-look-at-the-current-line analysis) are a reduced need 
for hyphenation and a reduced number of over-spaced lines (i.e., too few 
words on a line requiring large spaces between them for the line to be 
justified.)

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow Marker.java

[Glen Mazza]

Finn (or anyone else), given that FOText nodes (and possibly other 
non-formatting object nodes in the future) also have properties, any 
objections if we move FObj.bind() to FONode.bind()?   That would 
simplify the below code a bit.

Thanks,
Glen
[EMAIL PROTECTED] schrieb:
spepping2004/11/30 12:20:59
 Modified:src/java/org/apache/fop/fo/flow Marker.java
 Log:
 Fixed a ClassCastException in rebind
 
 Revision  ChangesPath
 1.20  +7 -2  xml-fop/src/java/org/apache/fop/fo/flow/Marker.java
 
 Index: Marker.java
 ===
 RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/flow/Marker.java,v
 retrieving revision 1.19
 retrieving revision 1.20
 diff -u -r1.19 -r1.20
 --- Marker.java	28 Oct 2004 10:00:21 -	1.19
 +++ Marker.java	30 Nov 2004 20:20:59 -	1.20
 @@ -26,6 +26,7 @@
  import org.apache.fop.apps.FOPException;
  import org.apache.fop.fo.FOEventHandler;
  import org.apache.fop.fo.FONode;
 +import org.apache.fop.fo.FOText;
  import org.apache.fop.fo.FObj;
  import org.apache.fop.fo.FObjMixed;
  import org.apache.fop.fo.PropertyList;
 @@ -69,9 +70,13 @@
  // Set a new parent property list and bind all the children again.
  propertyList.setParentPropertyList(parentPropertyList);
  for (Iterator i = children.keySet().iterator(); i.hasNext(); ) {
 -FObj child = (FObj) i.next();
 +Object child = i.next();
  PropertyList childList = (PropertyList) children.get(child);
 -child.bind(childList);
 +if (child instanceof FObj) {
 +((FObj) child).bind(childList);
 +} else if (child instanceof FOText) {
 +((FOText) child).bind(childList);
 +}
  }
  }
  
 
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Preview for a general XSL-FO processing API

[Glen Mazza]

Jeremias Maerki wrote:
If there's enough interest I can put the source code for the API plus
implementations on my website (or to a SF project or somewhere else).
I believe this common API could be interesting in the following months
when FOP HEAD advances. It can be used to easily switch implementations
or during development/testing. And I've got a few additional ideas. As
time allows...
It might also be interesting to have implementations for Foray, Defoe,
XEP and maybe even ol' JFOR. I hope the design is flexible enough to
accomodate all Java implementations.
 

As long as a FOP user is not *required* to use it, (i.e., they can 
ignore JAFOP entirely and still call FOP's native JAXP-based API as in 
our embed examples), and as long as JAFOP is implemented using our 
current API, then I don't think I would have much problem with it.  I 
don't want us to lose our present JAXP capabilities though--JAXP is a 
useful skill for our users to become proficient in, and something I 
would like us to continue promoting.

But your idea -- an interface that allows for run-time swapping of FO 
processors (like JAXP allows for Xalan and Saxon to be switched) is not 
bad at all.  I wish the folks at AH and RX would create such an 
interface that we could just implement.  Two thoughts come to mind:  (1) 
perhaps we should try to reactivate that EXSLFO group and move this 
topic to them, and (2) you may wish to take a look at the JAXP 
specification, if you haven't recently, and see if there are any 
issues/ideas/things you perhaps forgot to take into account, etc., with 
JAFOP.  That spec should show you what needs to be done for a common 
interface to be accepted, including things you may have missed.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
> 
> > We've been doing the same with PR_ (properties)
> and
> > FO_ (FO's) for quite some time.  
> 
> To avoid a name conflict somewhere.
> 

Yes, I was wondering why you didn't originally do that
for the enumeration constants as well.  I like their
self-documenting value in particular though.

> How about having 3 interfaces: 'Properties',
> 'Elements' and 'Enums' 
> which contains the constants without any prefix. And
> then decide that 
> these interfaces are never implemented, but the
> constants are always 
> accessed using the interface name:
>  Enums.TRUE
> 
> That would keep the searchability and perhaps even
> help us when (if) we 
> move to typesafe enums.
> 

-0.  I prefer the simplicity of the current method,
and like the way the code looks as-is.  But I can
easily see how others may view this solution as more
professional.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Glen Mazza]

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] wrote:
> > gmazza  2004/11/24 13:07:31
> >   2.) Appended EN_ to enumeration constants to
> make them better S&R'able throughout app.
> 
> Yuk. Having a large number of identifiers in the
> same scope with
> an identical prefix isn't very good for
> autocompletion both in
> Emacs and Eclipse. 

We've been doing the same with PR_ (properties) and
FO_ (FO's) for quite some time.  After hitting the
EN_, you're at the same place you would be without the
prefix.  Furthermore, you can now hunt away for your
enumeration constants without them being intermixed
with the PR_'s and FO_'s.

It was also a commenting issue:  TRUE and FALSE, for
example, without a prefix, just weren't self
documenting enough to emphasize that we're working
with enumeration constants here.  (Remember, we
removed the old interfaces--per your desire as well as
mine--such as WritingMode.LR_TB or whatever that
previously provided that emphasis.)


> I also don't quite get the point
> about the
> better S&R'ability.
> 

Because it gives us a very convenient handle ("EN_")
to identify all the places where enumeration constants
are currently being used.  So if we wanted to switch
from "EN_", to "ENUM_", it would just be a quick S&R. 
Sans handle, that would be a very cumbersome
file-by-file manual process--which I just did
yesterday, in order to get the EN_'s in place to begin
with.

Glen

Re: Do we need an "inherit" enumeration constant?

[Glen Mazza]

[Finn]

It [an INHERIT constant] isn't needed as an enum value
because the 'inherit' keyword takes precedence over
the other enumeration values. See 5.9.11:
 
"The Keyword values take precedence over
EnumerationToken."
 
where Keyword is 'inherit'. The code to handle
'inherit' is at line 397
 
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/properties/Proper

tyMaker.java?annotate=1.11
 
[Glen]

Finn, I've read what you've written above, as well as
what the spec is saying -- but I am confused here. 
Why does there need to be a precedence-determining
rule in the spec that says "The Keyword values take
precedence over EnumerationToken."?  Does anyone know?

My first thought is that we're only going to have one
attribute value between the quotes (i.e., "inherit",
"left", "right", "justify", etc.) so I don't see the
need for order-of-evaluation rules or declarations of
precedence.  But are there actually cases where you
would have more than one enumeration constant (e.g.,
"left | justify"?)  I must be missing something here.

Thanks,
Glen

Re: For our American readers...

[Glen Mazza]

Thanks (but to Him, not to me!),
Glen

http://holydays.tripod.com/linc.htm


--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:

> 
> Happy Thanksgiving! (--that is the 25th, right? :-P)
> 
> Greetz,
> 
> Andreas
> 
> 

foundation page updated

[Glen Mazza]

XML Graphics is now listed on the foundation page,
thanks to David Crossley/Forrest Team:

http://www.apache.org/foundation

Glen