Re: [VOTE] Two changes to 1.0 branch

2003-10-27 Thread Jeremias Maerki 
Glen,

first of all, thanks for your continuing effort in the development
towards 1.0. I'm sad that I currently don't have the time to contribute
and have been extremely happy when I saw the first few patches targeted
at HEAD coming in recently.

On 27.10.2003 13:53:33 Glen Mazza wrote:
 Team,
 
 Two changes I would like to make to the 1.0dev branch:
 
 1.)  Rename the org.apache.fop.area.inline.Word class
 to org.apache.fop.area.inline.Text, and rename the
 renderWord() method in the Renderer subclasses to
 renderText().

snip/

 This is confusing--Text/renderText() is better for
 these objects.  Here is my +1.

+1

 2.)  Move the org.apache.fop.pdf package to a new
 org.apache.fop.render.pdf.document package.

I'd rather not for the following reason:

The PDF library could be used separately and outside of FOP. I think I
brought that up before that I'd even prefer splitting up the FOP source
code into coarse-grained components (core + components actually).

Take the two Transcoders (for PDF and PS) for example. They could just
as well be in Batik. Maybe they should actually be there, or maybe they
should be in a separate project that is maintained by interested FOP and
Batik people as there are concerns from both sides. The PDF transcoder
could probably have long been promoted to 1.0 status already. Because it
lives in the same space as FOP it isn't. Ok, Keiron and I didn't push
hard enough, yet, but I hope you get my point. The PS transcoder could
equally get there quickly enough. Having EPS output for SVG is an
interesting thing IMO.

The font code could be used by other projects. Maybe the same for the
MIF and RTF libraries and image abstractions.

Actually, the font code would have to be extracted from FOP, too,
because the PDF library and the two transcoders depend on it. By
extracted from FOP I don't mean that the code must necessarily go to a
new project. It could also stay in the FOP code base but live in a
separate package structure. I particularly like the way the Cocoon
people have split up their code base.

I'm sure there are pros and cons to such a move but I'd like to have
that discussed before Glen's proposal is put to action. As positive
points for the split-up I see:
- Cleaner design as the dependencies get more important and the
  components have to be worked out as such.
- The individual components get a higher visibility which could attract
  new people. FOP is rather monolithic from an outside view which I
  believe can scare away rookies.
- The PDF (maybe even the PS/EPS) transcoder could be released soon.

Thoughts?

Jeremias Maerki

DO NOT REPLY [Bug 24148] - Kerning upsets text-align=end

2003-10-27 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24148.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24148

Kerning upsets text-align=end





--- Additional Comments From [EMAIL PROTECTED]  2003-10-27 14:40 ---
Created an attachment (id=8756)
Here is an example showing an exaggerated case of the problem.

DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates

2003-10-27 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23883.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23883

SVG embedded in FO cannot handle large (6digit) translates





--- Additional Comments From [EMAIL PROTECTED]  2003-10-27 17:16 ---
The warnings about the fonts on the Mac turn out to be sth Mac-specific 
(happens with a number of FOs containing embedded SVG), so I guess this remark 
can be ignored WRT to this bug...

Being quite intrigued by this, I decided to do a little reading in the PDF 
spec, and found this little note (4.2.3 Graphics - Coordinate Systems - 
Transformation Matrices) :
q
When rendering graphics objects, it is sometimes necessary for a viewer 
application to perform the inverse of a transformation -—that is, to find the 
user space coordinates that correspond to a given pair of device space 
coordinates. Not all transformations are invertible, however. For example, if a 
matrix contains a, b, c, and d elements that are all zero, all user coordinates 
map to the same device coordinates and there is no unique inverse 
transformation. Such noninvertible transformations are not very useful and 
generally arise from unintended operations, such as scaling by 0. Use of a 
noninvertible matrix when painting graphics objects can result in unpredictable
behavior.
/q

Wonder if this has got sth to do with it... Just an idea... We'll keep looking.

RE: [VOTE] Two changes to 1.0 branch

2003-10-27 Thread Victor Mote 
Jeremias Maerki wrote:

  Two changes I would like to make to the 1.0dev branch:
 
  1.)  Rename the org.apache.fop.area.inline.Word class
  to org.apache.fop.area.inline.Text, and rename the
  renderWord() method in the Renderer subclasses to
  renderText().

 snip/

  This is confusing--Text/renderText() is better for
  these objects.  Here is my +1.

 +1

+1 from me also

  2.)  Move the org.apache.fop.pdf package to a new
  org.apache.fop.render.pdf.document package.

 I'd rather not for the following reason:

I agree, and for much the same reasons.

 The PDF library could be used separately and outside of FOP. I think I
 brought that up before that I'd even prefer splitting up the FOP source
 code into coarse-grained components (core + components actually).

+1

 Take the two Transcoders (for PDF and PS) for example. They could just
 as well be in Batik. Maybe they should actually be there, or maybe they
 should be in a separate project that is maintained by interested FOP and
 Batik people as there are concerns from both sides. The PDF transcoder
 could probably have long been promoted to 1.0 status already. Because it
 lives in the same space as FOP it isn't. Ok, Keiron and I didn't push
 hard enough, yet, but I hope you get my point. The PS transcoder could
 equally get there quickly enough. Having EPS output for SVG is an
 interesting thing IMO.

 The font code could be used by other projects. Maybe the same for the
 MIF and RTF libraries and image abstractions.

+1. The RTF stuff is already set up in a separate directory this way. This
is primarily due to the design of the JFOR crew. MIF should be done the same
way. And I agree that the same could be done with fonts.

I would actually prefer to see a directory structure that started at either
util or lib that had subdirectories like lib/pdf and lib/rtf. These
are separate from, but used by, the renderers.

Without belaboring the point (discussed earlier), I see benefits to even
taking the FOP core stuff and breaking it up into smaller pieces. I think
the FO Tree can be treated as a separate project. I *definitely* think there
is benefit to treating each of the layout strategies as separate projects.
To a lesser extent, but still important, I think each of the renderers can
and probably should be treated that way as well. That just leaves the Area
Tree, which will end up having a lot of sub-pieces dependent on it (each of
the layout strategies and each of the laid-out renderers), and I even like
having it as a separate sub-project. Core FOP then becomes the apps
package, managing the flow between the various sub-projects.

 Actually, the font code would have to be extracted from FOP, too,
 because the PDF library and the two transcoders depend on it. By
 extracted from FOP I don't mean that the code must necessarily go to a
 new project. It could also stay in the FOP code base but live in a
 separate package structure. I particularly like the way the Cocoon
 people have split up their code base.

 I'm sure there are pros and cons to such a move but I'd like to have
 that discussed before Glen's proposal is put to action. As positive
 points for the split-up I see:
 - Cleaner design as the dependencies get more important and the
   components have to be worked out as such.

Yes!

 - The individual components get a higher visibility which could attract
   new people. FOP is rather monolithic from an outside view which I
   believe can scare away rookies.

Yes! We could have committers that work only on layout but don't mess with
renderers, and vice versa. The monolithism hurts us from the inside looking
out as well, in that we are hesitant to make new committers until they
understand *all* of FOP. For example, we could easily make Peter Herweg a
committer for the RTF libraries and renderer, but there is some hesitation
(even on my part, who thinks Peter does good work) to turn him loose in
layout until we know more about him, which takes time. In the meantime both
he and we must work more slowly.

 - The PDF (maybe even the PS/EPS) transcoder could be released soon.

 Thoughts?

I can think of no case where a project that can be *cleanly* broken down
into smaller projects does not benefit from it. However, here are some
(potential) drawbacks:
1. releasing code is probably more complicated (more dependencies must be
managed)
2. if we want to granularize commit access, I don't know whether that can be
done feasibly apart from separate projects.

In the long run, we need a lib package for graphics formats. I think we need
an Apache-license equivalent to Jimi and JAI. This could/should eventually
be a separate package, but our existing native capabilities should probably
be considered here as well. I would turn Ben Galbraith loose in this code in
a heartbeat.

Victor Mote

Re: PDF meta properties (was Re: basic-link)

2003-10-27 Thread J.Pietschmann 
Clay Leeds wrote:
I was unaware that FOP has the ability to add Producer, Author and Title 
properties
It can be set via the PDF renderer API, at least for HEAD. Maybe
the producer is hardcoded to FOP or something (look into the
source for details).
It's not accessible on the command line yet.
J.Pietschmann

DO NOT REPLY [Bug 24148] - Kerning upsets text-align=end

2003-10-27 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24148.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24148

Kerning upsets text-align=end





--- Additional Comments From [EMAIL PROTECTED]  2003-10-27 18:20 ---
The problem is that the relevant text width calculation doesn't take kerning
into account, it just uses the character width only. This can screw any
alignment, including centering and justifying.
I don't think this will be fixed in the maintenance branch.

RE: PDF meta properties (was Re: basic-link)

2003-10-27 Thread Andreas L. Delmelle 
 -Original Message-
 From: Clay Leeds [mailto:[EMAIL PROTECTED]

 I was unaware that FOP has the ability to add Producer, Author and Title
 properties to FOP. In fact, the web site still shows FOP does not
 currently support several desirable PDF features: document properties
 (title, author, etc.), and watermarks.:

http://xml.apache.org/fop/output.html#pdf


Maestro,

Hold yer horses here... I had to do a bit of browsing around in the code to
find out that support for these is already implemented. Once I saw this, it
was merely a question of calling the appropriate method(s) in the Driver.

(In fact, the producer field was already being used. At first I added the
other properties to the code myself, after reading a bit through the pdf
spec  based upon what was already there... Only to find out later on that
these were also added by dev... :) )

 If support for these have been added, I think it would be great to add
 this info to the web site. If it's been added to 1.0Dev then, as Emily
 Litella would say... never mind.


Hmmm... I doubt the way it works right now deserves to be put on the site
somewhere, but still it's probably nice for some users to know that these
features are already available under the surface somewhere.


Greetz,

Andreas

Re: [VOTE] Two changes to 1.0 branch

2003-10-27 Thread Jeremias Maerki 

On 27.10.2003 18:38:07 Victor Mote wrote:

snip/

 +1. The RTF stuff is already set up in a separate directory this way. This
 is primarily due to the design of the JFOR crew. MIF should be done the same
 way. And I agree that the same could be done with fonts.
 
 I would actually prefer to see a directory structure that started at either
 util or lib that had subdirectories like lib/pdf and lib/rtf. These
 are separate from, but used by, the renderers.
 
 Without belaboring the point (discussed earlier), I see benefits to even
 taking the FOP core stuff and breaking it up into smaller pieces. I think
 the FO Tree can be treated as a separate project. I *definitely* think there
 is benefit to treating each of the layout strategies as separate projects.
 To a lesser extent, but still important, I think each of the renderers can
 and probably should be treated that way as well. That just leaves the Area
 Tree, which will end up having a lot of sub-pieces dependent on it (each of
 the layout strategies and each of the laid-out renderers), and I even like
 having it as a separate sub-project. Core FOP then becomes the apps
 package, managing the flow between the various sub-projects.

You go further than I would have dared.

snip/

 For example, we could easily make Peter Herweg a
 committer for the RTF libraries and renderer, but there is some hesitation
 (even on my part, who thinks Peter does good work) to turn him loose in
 layout until we know more about him, which takes time. In the meantime both
 he and we must work more slowly.

Normally, you don't just go and mess around in other people's code if
you don't know what you're doing. I think it's a relatively weak point
to deny someone the committership only because of that. If Peter is able
to handle the RTF output I don't see any problem allowing him to do that.
If he grows into the other parts, so much better. Even I have never
messed around in layout, yet.

  - The PDF (maybe even the PS/EPS) transcoder could be released soon.
 
  Thoughts?
 
 I can think of no case where a project that can be *cleanly* broken down
 into smaller projects does not benefit from it. However, here are some
 (potential) drawbacks:
 1. releasing code is probably more complicated (more dependencies must be
 managed)

Right. Therefore, I'd only separate the parts that are useful in a
non-FOP context keeping that effort at a minimum.

 2. if we want to granularize commit access, I don't know whether that can be
 done feasibly apart from separate projects.

Commit access is per project.

3. Splitting the whole thing up too much only brings other problems. You
have to add tons of directories as source directories in your IDE, for
example. IMO we shouldn't break up core-FOP too much.
 
 In the long run, we need a lib package for graphics formats. I think we need
 an Apache-license equivalent to Jimi and JAI. This could/should eventually
 be a separate package, but our existing native capabilities should probably
 be considered here as well. I would turn Ben Galbraith loose in this code in
 a heartbeat.

Yeah, I thought about that one just 2 hours ago when I was working on
Krysalis Barcode's bitmap generation code.

If we went down that road we would need to define which parts we want to
separate and where they go:
1. into another project (Batik)
2. into a new project (as XML subproject, Jakarta subproject, XML
   Commons, Apache Commons, Jakarta Commons)
3. into a separate place in xml-fop, thus staying in FOP but becoming
   some kind of sub-subproject.

Jeremias Maerki

Re: [VOTE] Two changes to 1.0 branch

2003-10-27 Thread Glen Mazza 
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
 Glen,
 
 first of all, thanks for your continuing effort in
 the development
 towards 1.0. 
 

Sure thing--two patches down, 21,234,198 to go! ;)

 
 Take the two Transcoders (for PDF and PS) for
 example. They could just
 as well be in Batik. Maybe they should actually be
 there, or maybe they

Tom DeWeese of Batik made that suggestion a few months
back--we're tentatively in agreement that once FOP
gets solidified, the transcoders can move to them for
their maintenance and documentation.


 The PDF transcoder
 could probably have long been promoted to 1.0 status
 already. 

Sie haben vergessen!  PDF transcoder is distributed up
with Batik right now--it's one of 1.0's few success
stories.  We don't even use maintenance for the
transcoder--there's not a target for it in
maintenance's build.xml.


 
 Thoughts?
 

As always, our user base's primary concern is to have 
a product that can generate [absurdly high number of
huge image-heavy documents] in [ridiculously small
amount of time].  That is FOP's responsibility to
Cocoon, Struts programmers, HP PCL users, Adobe PDF,
etc.

I see the way of accomplishing this is by having FOP
be (1) extremely fast and optimized; (2) extremely
accurate; and (3) extremely focused on (1) and (2)
above.

Making a nice framework for others to create a
FOP-like product is not as big a concern for me.  I
want to create FOP, not something to be used for
creating a FOP. 

Anyway, thanks everyone for voting, and especially to
Victor and Jeremias for their well-explained
positions.  I'll get the first one taken care of
shortly, and hold off on doing the second due to their
concerns at this time.

Glen


__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

cvs commit: xml-fop/src/java/org/apache/fop/tools AreaTreeBuilder.java

2003-10-27 Thread gmazza 
gmazza  2003/10/27 20:22:14

  Modified:src/java/org/apache/fop/area/inline InlineAreaVisitor.java
UnresolvedPageNumber.java
   src/java/org/apache/fop/layoutmgr AddLMVisitor.java
TextLayoutManager.java
   src/java/org/apache/fop/render AbstractRenderer.java
Renderer.java
   src/java/org/apache/fop/render/awt AWTRenderer.java
   src/java/org/apache/fop/render/pdf PDFRenderer.java
   src/java/org/apache/fop/render/ps PSRenderer.java
   src/java/org/apache/fop/render/svg SVGRenderer.java
   src/java/org/apache/fop/render/xml XMLRenderer.java
   src/java/org/apache/fop/tools AreaTreeBuilder.java
  Added:   src/java/org/apache/fop/area/inline TextArea.java
  Removed: src/java/org/apache/fop/area/inline Word.java
  Log:
  renamed org.apache.fop.area.inline.Word to .TextArea (.Text not used to avoid
  conflicts with org.w3c.dom.Text)
  changed Renderer.renderWord() method to renderText().
  
  Revision  ChangesPath
  1.2   +4 -4  
xml-fop/src/java/org/apache/fop/area/inline/InlineAreaVisitor.java
  
  Index: InlineAreaVisitor.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/area/inline/InlineAreaVisitor.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- InlineAreaVisitor.java10 Sep 2003 18:42:22 -  1.1
  +++ InlineAreaVisitor.java28 Oct 2003 04:22:13 -  1.2
  @@ -66,11 +66,11 @@
   void serveVisitor(Viewport viewport);
   
   /**
  - * Handle a visitor request to process an inline word.
  + * Handle a visitor request to process inline text.
*
  - * @param area  The word area
  + * @param area  The text area
*/
  -void serveVisitor(Word area);
  +void serveVisitor(TextArea area);
   
   /**
* Handle a visitor request to process an inline parent area.
  
  
  
  1.2   +3 -3  
xml-fop/src/java/org/apache/fop/area/inline/UnresolvedPageNumber.java
  
  Index: UnresolvedPageNumber.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/area/inline/UnresolvedPageNumber.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- UnresolvedPageNumber.java 11 Mar 2003 13:05:40 -  1.1
  +++ UnresolvedPageNumber.java 28 Oct 2003 04:22:13 -  1.2
  @@ -60,7 +60,7 @@
* This is a word area that resolves itself to a page number
* from an id reference.
*/
  -public class UnresolvedPageNumber extends Word implements Resolveable {
  +public class UnresolvedPageNumber extends TextArea implements Resolveable {
   private boolean resolved = false;
   private String pageRefId;
   
  @@ -71,7 +71,7 @@
*/
   public UnresolvedPageNumber(String id) {
   pageRefId = id;
  -word = ?;
  +text = ?;
   }
   
   /**
  @@ -98,7 +98,7 @@
   if (pages != null) {
   PageViewport page = (PageViewport)pages.get(0);
   String str = page.getPageNumber();
  -word = str;
  +text = str;
   
   /[EMAIL PROTECTED] Update IPD ??? */
   }
  
  
  
  1.1  xml-fop/src/java/org/apache/fop/area/inline/TextArea.java
  
  Index: TextArea.java
  ===
  /*
   * $Id: TextArea.java,v 1.1 2003/10/28 04:22:13 gmazza Exp $
   * 
   *The Apache Software License, Version 1.1
   * 
   *
   * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
   *
   * Redistribution and use in source and binary forms, with or without modifica-
   * tion, are permitted provided that the following conditions are met:
   *
   * 1. Redistributions of source code must retain the above copyright notice,
   *this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright notice,
   *this list of conditions and the following disclaimer in the documentation
   *and/or other materials provided with the distribution.
   *
   * 3. The end-user documentation included with the redistribution, if any, must
   *include the following acknowledgment: This product includes software
   *developed by the Apache Software Foundation (http://www.apache.org/).
   *Alternately, this acknowledgment may appear in the software itself, if
   *and wherever such third-party acknowledgments normally appear.
   *
   * 4. The names FOP and Apache Software Foundation must not be used to
   *endorse or