Re: Sources for layout.jpg

2005-03-11 Thread 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

2005-03-10 Thread 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: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread 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: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

2005-03-09 Thread 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
 




Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-08 Thread 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: Integration of TIFFRenderer in FOP

2005-03-08 Thread 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 http://cv.pbw.id.au/
  Folio http://defoe.sourceforge.net/folio/
  http://folio.bkbits.net/
  
 
 
   
   
 __ 
 Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web 
 http://birthday.yahoo.com/netrospective/
 



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

2005-03-08 Thread 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: FOP at ApacheCon Europe 2005?

2005-03-07 Thread 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

2005-03-03 Thread 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-devm=110495579414655w=2


Re: page-breaking strategies and performance

2005-03-02 Thread 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: page-breaking strategies and performance

2005-03-02 Thread 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

2005-03-02 Thread 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

2005-03-02 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java

2005-03-02 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-03-01 Thread Glen Mazza
OH!!!  lightBulb state=on wattage=25/ 

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
 
 snip/
 
 



remove build.bat and build.sh?

2005-02-26 Thread 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

2005-02-25 Thread 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:
 snip/
 
 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

2005-02-25 Thread 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

2005-02-24 Thread 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

2005-02-24 Thread 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-devm=110922603225376w=2

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



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

2005-02-23 Thread 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

2005-02-23 Thread 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

2005-02-23 Thread 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=11028610291r=1w=2


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread 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: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread 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

2005-02-22 Thread 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

2005-02-22 Thread 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-devm=110625230922690w=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: Error in computation of inline progression dimension ?

2005-02-16 Thread 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 ?

2005-02-16 Thread 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 ?

2005-02-15 Thread 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: Error in computation of inline progression dimension ?

2005-02-15 Thread 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 ?

2005-02-15 Thread 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 ?

2005-02-15 Thread 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 ?

2005-02-15 Thread 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: representative example needed [was in fop-user]

2005-02-14 Thread 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: representative example needed [was in fop-user]

2005-02-13 Thread 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: need to update team page

2005-02-13 Thread 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: testcases

2005-02-12 Thread 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

2005-02-11 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2005-02-06 Thread 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

2005-02-06 Thread 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: Markers added to the wrong page

2005-02-05 Thread 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

2005-02-04 Thread 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

2005-02-03 Thread 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: (housekeeping) need Compare class, TestConverter.getLogger()/.setLogger()?

2005-01-30 Thread 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: Background images

2005-01-30 Thread 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


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

2005-01-22 Thread 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: Layout dimension mechanism

2005-01-22 Thread 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



Re: Background images

2005-01-20 Thread 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

2005-01-19 Thread 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: marketing Defoe

2005-01-17 Thread 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.
 



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

2005-01-17 Thread 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]
 
 



bring XSL 1.1 fo:flow-map into HEAD?

2005-01-13 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination/bookmarks Bookmark.java BookmarkTitle.java BookmarkTree.java

2005-01-11 Thread 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: Checking for OutputSource for renderer overrides

2005-01-11 Thread 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/layoutmgr TraitSetter.java BlockLayoutManager.java

2005-01-10 Thread 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:
 
 fo:block margin-left=1pcA test file
   fo:inline-container start-indent=1.5pc
 fo:block margin-left=1pcA test
 file/fo:block
   /fo:inline-container
 /fo:block
 
 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:
 
 fo:block margin-left=1pcA test file
   fo:inline-container
 fo:block margin-left=1pcA test
 file/fo:block
   /fo:inline-container
 /fo:block
 
 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.
  
  snip/
  
 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: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

2005-01-10 Thread Glen Mazza
--- Glen Mazza [EMAIL PROTECTED] wrote:

 BTW, would Jeremias' proposal 
 effect future
  ^^

oopsaffect ;)

Glen



Re: Checking for OutputSource for renderer overrides

2005-01-08 Thread 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

2005-01-07 Thread 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



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

2005-01-06 Thread Glen Mazza
--- Finn Bock [EMAIL PROTECTED] wrote:

 
 Using casts will prevent us from adding property
 proxies, which i 
 suspect will be needed.
 

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

Thanks,
Glen




Checking for OutputSource for renderer overrides

2005-01-06 Thread 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-cvsm=110495921529754w=2



Re: [RT] FOP RTF edition

2005-01-05 Thread 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: Implementing text-decoration

2005-01-05 Thread 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: fo.InlineLevel -- make abstract?

2005-01-05 Thread 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: New year - update copyright years

2005-01-04 Thread 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
 



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

2005-01-03 Thread 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=10800483371r=1w=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: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java

2005-01-03 Thread 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.
 



fo.InlineLevel -- make abstract?

2005-01-03 Thread 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: Happy New Year

2004-12-31 Thread 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

2004-12-28 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread 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

2004-12-27 Thread 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

2004-12-27 Thread Glen Mazza
--- Simon Pepping [EMAIL PROTECTED] wrote:
snip/

 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: Horizontal Line

2004-12-27 Thread 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: arabic pdf

2004-12-25 Thread 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: [OT] Printing the XSL WD

2004-12-24 Thread 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



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

2004-12-24 Thread 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;
   }
   



Merry Christmas everyone!

2004-12-23 Thread 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

2004-12-21 Thread 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?

2004-12-17 Thread Glen Mazza
face color=red/  ;-)

--- 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
 :-)
 
 snip/
 
 Chris
 



RE: replace extension bookmarks with XSL 1.1 ones?

2004-12-15 Thread 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?

2004-12-14 Thread 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?

2004-12-12 Thread 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()

2004-12-08 Thread 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

2004-12-07 Thread 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

2004-12-06 Thread 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

2004-12-03 Thread Glen Mazza
body temperature=98.5/ 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!

2004-12-01 Thread 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=9723805961r=1w=2

[2] First email (perhaps):
http://marc.theaimsgroup.com/?l=fop-devm=97238032303320w=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: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow Marker.java

2004-11-30 Thread 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: Knuth linebreaking questions

2004-11-30 Thread 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/traits LayoutProps.java SpaceVal.java

2004-11-26 Thread 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: Preview for a general XSL-FO processing API

2004-11-26 Thread 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: For our American readers...

2004-11-25 Thread 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
 
 



Re: Do we need an inherit enumeration constant?

2004-11-25 Thread 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: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

2004-11-25 Thread 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 SR'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 SR'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 SR. 
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: Unnecessary zipping and backups?

2004-11-24 Thread Glen Mazza
--- The Web Maestro [EMAIL PROTECTED] wrote:

 On Nov 24, 2004, at 11:52 AM, The Web Maestro wrote:
  On a similar note, I am 'contemplating' committing
 the xml-fop/build/ 
  folder ('built' by apache-forrest-0.6). My
 reasoning for this is 
  two-fold:
  1. it contains the FOP web site (which I've spent
 a significant amount 
  of time to re-create).
  2. it can serve as off-line of documentation (for
 those installations 
  not connected to the internet).
 
  We may not need to do this since it *is* on
 minotaur.apache.org...
 
 I meant to ask FOP-DEV... what are your thoughts on
 my COMMITTING 
 xml-fop's Forrest-generated build/ directory
 structure?
 

For #1) Wouldn't we have to keep doing that whenever a
change is made to the website as a result?  I'm
concerned with it falling out of sync with the
production website.

Also, the output on minotaur should be viewable via
ViewCVS anyway, correct?  (We were doing manual
updates to the website to fix the breadcrumb issue--we
went through ViewCVS to find the correct pages to
update IIRC.)  

For #2) Oh ye of little faith! ;) Aren't we eventually
going to have a full-site PDF anyway?  Then
non-internet installations can just save a copy of the
PDF locally after they download the software.  (I
guess they have to be connected at some time to the
'Net though...)  Perhaps saving the full site PDF once
we get it may be more efficient.

Glen



foundation page updated

2004-11-24 Thread Glen Mazza
XML Graphics is now listed on the foundation page,
thanks to David Crossley/Forrest Team:

http://www.apache.org/foundation

Glen



Unnecessary zipping and backups?

2004-11-23 Thread Glen Mazza
Clay,
I'm noticing a lot of .zips and .bak backup files in our cvs directories 
[1] -- this seems unnecessary and a bit messy for a version control 
system, as everyone who cvs checkouts or cvs updates is now 
downloading these files.  Instead of zip files, usually the solution is 
just to cvs remove the files -- they will automatically go into the 
cvs attic as a result (they are not actually deleted -- ViewCVS lists 
them as dead but they are always still retrievable.)

For backup files, we can always go to older versions by clicking on the 
first column in ViewCVS ([2], for an example version list).  So I don't 
think we have a need for creating any .bak files either.  If there is 
a message you wish to store with a particular version before moving 
forward, just make a *very* minor change to the file (say, move a 
character or add a blank line), and add your comment when you cvs commit.

Can we get these zip's and bak's removed?  Just cvs remove them -- get 
them in the attic so people aren't downloading them on a cvs checkout.

BTW -- thanks *very* much for taking care of the alt-design tab, I 
greatly appreciate the effort in simplifying our site.

Thanks,
Glen
[1] http://cvs.apache.org/viewcvs.cgi/xml-fop/
[2] http://cvs.apache.org/viewcvs.cgi/xml-fop/build.bat?rev=1.22view=log


  1   2   3   4   5   6   7   >