Re: startup refactoring

[Jeremias Maerki]

On 17.06.2003 21:28:29 Glen Mazza wrote:
> Instinctively, I wouldn't trust any code in the
> package root of org.apache.fop -- we wouldn't have a
> very modularized design that way (knowing FOP's
> current coding style, the main FOP API would then be
> accessing objects all through the packages,
> octopus-like, splitting of the business logic with the
> actual objects doing the work, inextricable from the
> XSL FO process.)  

Not necessarily. Well, the public API has to have some way to control
the whole show. This will automatically lead to a little octopus if the
code is in ...fop or ...fop.api. But no problem with another package.

> FOP is more a pipeline to me:
> 
> APPs package (CLI, TRAX/XSLTInputHandler, Avalonized
> API, Victor's ideas) -->  FOTreeBuilder/Layout/Area
> Tree creation --> Rendering.

Uh, thanks for that one. It's a very nice show why the current apps
package is a mess. SoC (Separation of Concerns) would suggest not to mix
thing like CLI, public API and inner communication classes.

> IMO FOTreeBuilder should just expose three functions
> (perhaps another one for logging):

Logging, at least in Avalon-land, is a lifecycle aspect (through
the LogEnabled interface). The methods below are lifestyle methods.
Lifecycle != lifestyle. It's best to talk about lifestyle primarily and
leave the lifecycle (instantiation, logging, configuration,
initialization) to a different discussion. Helps keeping the focus, I
believe. The lifecycle can eventually be handled automatically by a
container (such as Fortress or Merlin). Leaves you to care about the
lifestyle (=functionality).

> 1.) SetXSLFOStream() (file or stream)
> 2.) SetRenderType()  (those constants currently in
> Driver or CommandLineStarter)
> 3.) Run(). (returns a stream or file)

This mixes concerns. A render type does not belong in a class called
FOTreeBuilder. The name already implies that the class is responsible
for building the FO tree. It should have nothing to do with the
rendering aspect, especially since FO tree building is independant of
the output format (wrt Renderers). The render type is better placed in a
class such as a RenderingRun/Document/. The FO tree
builder is (to me) a service that simply accepts a SAX stream and builds
the FO tree. The layout engine, another (coarse grained) service, will
then access the FO tree to do the layout. This is all kept together by a
"supervising" class. At least, that's my personal high-level view of it.

> You can have 500 methods of calling these functions
> within the apps package--it's all fine/OK, because
> they will only be able to work with FOTreeBuilder
> (apps will have no access to Renderers or Layout,
> etc.) and its three functions. 
> 
> Such an FOTreeBuilder may be getting to the heart of
> the XSLFO Spec:
> 
> Input:  XSLFO Stream, RenderType
> Output: Document
> 
> and may be close to Xalan's approach, a team which has
> similar input/output requirements.
> 
> Also, embedded Java code should be able to run without
> accessing the Apps class at all by directly calling
> those three functions in FOTreeBuilder.

The FOTreeBuilder should remain an inner service to FOP, not exposed in
the public API, if you ask me. The public API, IMHO, should be an easily
understandable construct that masks the internal complexity from the
user. Driver already does that today, it's just a bit too tightly packed
and not focused on as little as possible. We need to disentangle that
class to make it more like the JAXP API.

> (Although we
> can certainly provide additional options in apps--but
> FOTreeBuilder should be all that is strictly needed.) 
> Said another way, the processing paths of
> FOTreeBuilder, once instantiated in embedded code,
> should not access *any* functionality in the apps
> package, because apps is to the left of the pipeline.



Jeremias Maerki


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

Re: startup refactoring

[Jeremias Maerki]

No problem with that.

On 17.06.2003 23:03:22 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > main FOP api in the org.apache.fop package.
> 
> org.apache.fop.api package?



Jeremias Maerki


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

cvs commit: xml-fop/src/java/org/apache/fop/rtf/renderer RTFHandler.java

[vmote]

vmote   2003/06/17 19:10:32

  Modified:src/java/org/apache/fop/rtf/renderer RTFHandler.java
  Log:
  Add support for text-align in paragraphs.
  
  Revision  ChangesPath
  1.5   +34 -2 xml-fop/src/java/org/apache/fop/rtf/renderer/RTFHandler.java
  
  Index: RTFHandler.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/rtf/renderer/RTFHandler.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- RTFHandler.java   6 May 2003 07:46:05 -   1.4
  +++ RTFHandler.java   18 Jun 2003 02:10:32 -  1.5
  @@ -63,7 +63,9 @@
   import org.apache.fop.layout.FontInfo;
   import org.apache.fop.apps.FOPException;
   
  +import org.apache.fop.fo.PropertyList;
   import org.apache.fop.fo.pagination.PageSequence;
  +import org.apache.fop.fo.properties.Constants;
   import org.apache.fop.fo.flow.Block;
   import org.apache.fop.fo.flow.Flow;
   import org.apache.fop.fo.flow.ExternalGraphic;
  @@ -77,8 +79,10 @@
   import org.apache.fop.fo.flow.TableRow;
   
   // JFOR
  +import org.jfor.jfor.rtflib.rtfdoc.RtfAttributes;
   import org.jfor.jfor.rtflib.rtfdoc.RtfFile;
   import org.jfor.jfor.rtflib.rtfdoc.RtfSection;
  +import org.jfor.jfor.rtflib.rtfdoc.RtfText;
   import org.jfor.jfor.rtflib.rtfdoc.RtfParagraph;
   import org.jfor.jfor.rtflib.rtfdoc.RtfDocumentArea;
   
  @@ -184,13 +188,16 @@
*/
   public void startBlock(Block bl) {
   try {
  -para = sect.newParagraph();
  +RtfAttributes rtfAttr = new RtfAttributes();
  +rtfAttr.set(mapBlockTextAlign(bl));
  +para = sect.newParagraph(rtfAttr);
   } catch (IOException ioe) {
   // FIXME could we throw Exception in all StructureHandler events?
   throw new Error("IOException: " + ioe);
   }
   }
   
  +
   /**
* @see org.apache.fop.apps.StructureHandler#endBlock(Block)
*/
  @@ -395,5 +402,30 @@
   // FIXME could we throw Exception in all StructureHandler events?
   throw new Error("IOException: " + ioe);
   }
  -   }
  +}
  +
  +private static String mapBlockTextAlign(Block bl) {
  +int fopValue = bl.properties.get("text-align").getEnum();
  +String rtfValue = null;
  +switch (fopValue) {
  +case Constants.CENTER: {
  +rtfValue = RtfText.ALIGN_CENTER;
  +break;
  +}
  +case Constants.END: {
  +rtfValue = RtfText.ALIGN_RIGHT;
  +break;
  +}
  +case Constants.JUSTIFY: {
  +rtfValue = RtfText.ALIGN_JUSTIFIED;
  +break;
  +}
  +default: {
  +rtfValue = RtfText.ALIGN_LEFT;
  +break;
  +}
  +}
  +return rtfValue;
  +}
  +
   }
  
  
  

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

RE: startup refactoring

[Victor Mote]

J.Pietschmann wrote:

> Well, static data often interferes badly with multithreading.
> We can use it in the CLI, but in the core which is intended to be
> possibly embedded in multithreaded long running server environments
> should it is best to avoid them. Even if you can arrange to
> synchronize properly (not as easy as many people think), blocked
> threads on shared ressources will almost certainly generate angry
> comments.

The only static data would be a pointer to the singleton object, which
contains the real data. However, it seems that your point would still be
valid with regard to that data.

The choices for data to be shared amongst threads are:
1. Allow concurrent access.
2. Allow synchronized access.
3. Allow no access (can't share data between threads).

We all agree that #1 is bad. Implementing #3 because #2 might be slow seems
counterproductive. If a person in line at the store complains that the line
is moving slowly, I don't see how it helps them to say that they can't shop
here any more (but it will shut them up). Or am I missing some fourth option
here?

Victor Mote


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

Re: startup refactoring

[J.Pietschmann]

Jeremias Maerki wrote:
main FOP api in the org.apache.fop package.
org.apache.fop.api package?

J.Pietschmann



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

Re: startup refactoring

[J.Pietschmann]

Victor Mote wrote:
I'm not opposed to Avalon, but I might be if I understood it.
Well, the good message about Avalon is that it can make
development for much easier.
The bad news is that if too much of Avalon is exposed in the
APIs intended for common usage, it will drive many potential
embedders away.
I think if we want to use Avalon internally (and there are
interesting use cases, for example the Hyphenator), it would
make most sense to provide an Avalon component shell which can
be also used with a simple factory pattern similat to TrAX.
Have a look at the Avalonization Wiki.
It probably
seems lazy that I am not up to speed on it yet -- I have tried a couple of
times to get the big picture from the doc, but concluded that I won't get my
arms around it until I use it (IOW, the doc wasn't very helpful).
Amen, brother.

If the static construct and Avalan are mutually exclusive, the former seems
far less invasive, and easier both to implement and un-implement.
Well, static data often interferes badly with multithreading.
We can use it in the CLI, but in the core which is intended to be
possibly embedded in multithreaded long running server environments
should it is best to avoid them. Even if you can arrange to
synchronize properly (not as easy as many people think), blocked
threads on shared ressources will almost certainly generate angry
comments.
J.Pietschmann



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

RE: alt-design merits (WAS: Nomination of Glen Mazza as committer)

[Victor Mote]

Peter B. West wrote:

> They can.  They must.  But then what happens to the idea that the FO
> tree can be processed and refined before the layout occurs?  If you are

The pieces that can be processed are. The pieces that cannot are deferred.

> tree can be processed and refined before the layout occurs?  If you are
> going to defer the resolution, why not defer the parsing as well?

Because to simple minds like mine, they seem like easily separable tasks for
which there is no benefit to mixing. More to the point of this conversation,
if you can complete the parsing before starting layout, why not?

> Marker resolution requires the merging of the fo:static-content subtree
> (encountered *before* the corresponding fo:flow) with fo:marker subtrees
> which can only be determined as pages are laid out.  Furthermore, this
> process may repeat with *different* fo:marker subtrees being attached at
> the same fo:retrieve-marker point in the static-content.

OK, but this doesn't help me understand how pull parsing is superior to
building an FO Tree.

> With pull parsing, events are extracted from a parsing event buffer *as
> required*.  In general, this will occur "synchronously", but need not.

By way of comparison, with the FO Tree, information is extracted from the
tree *as required*. Again, I don't see the benefit.

> The stream of static-content parsing events can be stashed away, the
> stream of fo:marker subtree events can be stashed away somewhere else,

Why not "stash away" in an FO Tree?

> and the process of resolving the FO tree need never know that it is in
> fact reading an "asynchronous" stream of parser events in which
> fo:marker streams are attached by sleight-of-hand in place of the
> fo:retrieve marker dynamically and transparently, and that this parsing
> is happening after the event - well after the static-content was first
> encountered, and after the region-body has been laid out.  Furthermore,
> it can be "rewound" and repeated for as long as new pages with new
> fo.marker retrievals are required.

I do not see the advantage of using sleight-of-hand events over a data
structure.

> "Synchronous" and "asynchronous" are relative terms here.  It's all
> asynchronous, in the sense that the SAX component simply creates parse
> events and sticks them in a producer/consumer buffer.
>
> The other problem is percentage lengths, where the percentage is defined
> against an enclosing area dimension.  Doesn't it make sense to create
> the area before you even look at the FOs which will fill it?  Creating

Not to my way of thinking (although I have struggled with this a bit). In
general, XSL-FO 1.0 content drives the layout, not the other way around. (If
you have Dave Pawson's book, see the last section of Chapter 2.) IMO, the
percentage problem that you mention is an exception to this rule that can be
handled without a redesign of the whole system. How can you create an area
for a block without knowing its "span" attribute? (BTW, I think the redesign
stumbles here as well).

> the area also creates the context for the resolution of percentages.  In
> the difficult cases where the area dimension is initially indeterminate,
> the unresolvable percentage can at least be immediately "attached" to
> the area dimension whose resolution will in turn, resolve the
> percentage.  In most cases, however, the resolution will be immediate.

Is this not implemented/implementable in redesign?

> This approach, of having the containing area in place before parsing the
> contained FO subtree, is easy to implement with pull parsing, driven by
> the *areas*.

If it were a good thing, it seems at least as easy to implement using the FO
Tree.

> If I have not answered your question, yell out.  I am quite happy to
> keep on at this until you at least understand my thinking on this, even
> if you don't agree with it.

In addition to not following the benefits, I see the following apparent
drawbacks, which I would be glad to have you address:

1. Less modularity
2. More complex design

I wanted to add "less flexible", because it would seem to restrict our
ability to make the layout pluggable. However, that is probably not true,
but that line of thinking led to an interesting thought. If pluggable layout
works, then perhaps your whole pull-parsing logic could be implemented
entirely as an implementation of LayoutStrategy. For this purpose, it would
work similarly to our Structured output concepts (MIF, RTF), in that no FO
Tree would be built, but the SAX events are passed through. You could then
do with them whatever you wish, sychronously or asynchronously,
right-brained or left-brained, Northern Hemisphere or Southern :-) Is that
worth exploring? Can your stuff use the general Area Tree model?

Victor Mote


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

RE: startup refactoring

[Victor Mote]

Jeremias Maerki wrote:

> > > I'm a bit unhappy that you placed/left Session in the apps package. I
> > > would like to see the apps package deprecated as a whole over time. I
> > > would like a cli package that only contains the stuff needed for the
> > > command line and I'd like to have (wish, not a demand) the
> main FOP api
> > > in the org.apache.fop package.
> >
> > My humble apologies. What is the easiest way to roll it back?
> Is there an
> > automated way?
>
> I wasn't vetoing your changes, merely pointing out possible differences.
> You didn't need to revert. But do you agree with what I wrote?

Reversion is already completed -- if other changes start getting checked in,
then it becomes a much more difficult task. WRT to the location of the
"Session" concept, I don't have strong feelings about it the way some others
do, and I viewed that as an issue that could be resolved later by simply
moving it wherever you guys decided it should go.

> > OK. In my terminology, Session is a long-lived object that
> lives, well, for
> > the Session. Document are children of Session. The only part of
> Session that
> > you have seen is a renaming of Driver to Session. That is all
> that has been
> > committed so far. But eventually nearly all of existing Driver
> gets pushed
> > down to Document, RenderContext, and RenderTask. The only thing
> that really
> > still lives in Session is the logging stuff, and it might belong with
> > Document (under my scheme).
>
> That's not what I'm talking about. Do we all agree on this
> terminology? Can
> we find better classnames for what they are? These are key elements in
> FOP's architecture. I'd like to have good names for them so they are
> easily understandable even by outsiders. If you use Session you'll get
> all sorts of strange questions. I'm pretty sure about that.

I am not committed to the name "Session", but can't think of a better name,
even with the help of my trusty thesaurus. I think FrameMaker uses that name
in its FDK API. Microsoft uses "Application" for the equivalent concept in
its Office 2000 object model. I didn't like "Driver" much or I would have
left it alone (that implies a different concept to me). I suppose
FOPInstance, or RuntimeInstance might work. I didn't realize that there
would be misunderstandings of "Session".

> > Yes, I am talking about GoF Singleton. I understand the
> reluctance to use
> > static variables, but I haven't adopted the no-tolerance
> approach that you
> > have. The alternative is to either carry the static information
> around with
> > you in every method that might need it, or to actually store
> the information
> > in every object that might need it. I already see that with the
> logging. If
> > it is needed, then OK, but I don't see it yet.
>
> So I guess it's a matter of community decision what is preferred. Going
> for statics and singleton is certainly easier but it'll carry you away
> from the Avalon style of life. I have no problem if the majority of
> committers think that Avalon should be thrown out. I didn't manage to
> introduce the Avalon-patterns, yet, and it looks like I'm the only one
> really pushing it so far but without enough power.

I'm not opposed to Avalon, but I might be if I understood it. It probably
seems lazy that I am not up to speed on it yet -- I have tried a couple of
times to get the big picture from the doc, but concluded that I won't get my
arms around it until I use it (IOW, the doc wasn't very helpful).

If the static construct and Avalan are mutually exclusive, the former seems
far less invasive, and easier both to implement and un-implement. However, I
realize that there are more things that you want to do with Avalon that
might require that invasiveness anyway. Sorry I am not more help here.

Victor Mote


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

Re: 0.20.5 release

[J.Pietschmann]

Christian Geisert wrote:
RC3a seems to be rather stable and the changes since then look
non-critical to me. What about doing the release now (read: next days)
(and maybe 0.20.5a later if we get more hyphenation patterns back)
Or should we make the changes proposed by Jörg (improved memory
usage with tables - see 
http://marc.theaimsgroup.com/?l=fop-dev&m=105399053227758 )
which would require another release candidate.
I'd rather close the book on the maintenance code so that
something could be done on HEAD.
Take the footnote space problem I analysed yesterday: while
I know quite precisely what went wrong (two different
approaches to account for footnote space working concurrently)
I have no idea what breaks if I attempt a fix.
While HEAD has a lot of technical details to fix, the overall
approach seams to be much more promising.
J.Pietschmann

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

new Logo

[Christian Geisert]

Hi,

What's going on with the new logo?

Christian



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

Re: startup refactoring

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I'm a bit unhappy that you placed/left Session in
> the apps package. I
> would like to see the apps package deprecated as a
> whole over time. I
> would like a cli package that only contains the
> stuff needed for the
> command line and I'd like to have (wish, not a
> demand) the main FOP api
> in the org.apache.fop package.
> 

Instinctively, I wouldn't trust any code in the
package root of org.apache.fop -- we wouldn't have a
very modularized design that way (knowing FOP's
current coding style, the main FOP API would then be
accessing objects all through the packages,
octopus-like, splitting of the business logic with the
actual objects doing the work, inextricable from the
XSL FO process.)  

FOP is more a pipeline to me:

APPs package (CLI, TRAX/XSLTInputHandler, Avalonized
API, Victor's ideas) -->  FOTreeBuilder/Layout/Area
Tree creation --> Rendering.

IMO FOTreeBuilder should just expose three functions
(perhaps another one for logging):

1.) SetXSLFOStream() (file or stream)
2.) SetRenderType()  (those constants currently in
Driver or CommandLineStarter)
3.) Run(). (returns a stream or file)

You can have 500 methods of calling these functions
within the apps package--it's all fine/OK, because
they will only be able to work with FOTreeBuilder
(apps will have no access to Renderers or Layout,
etc.) and its three functions. 

Such an FOTreeBuilder may be getting to the heart of
the XSLFO Spec:

Input:  XSLFO Stream, RenderType
Output: Document

and may be close to Xalan's approach, a team which has
similar input/output requirements.

Also, embedded Java code should be able to run without
accessing the Apps class at all by directly calling
those three functions in FOTreeBuilder.  (Although we
can certainly provide additional options in apps--but
FOTreeBuilder should be all that is strictly needed.) 
Said another way, the processing paths of
FOTreeBuilder, once instantiated in embedded code,
should not access *any* functionality in the apps
package, because apps is to the left of the pipeline.

> And then I'm a bit unhappy about your terminology:
> Session, Document,
> RenderContext... Session and Document seem like
> "rubber terms" to me.
> Your Session looks very much like a
> FOProcessorFactory (analog to
> TransformerFactory). A session to me is a
> short-lived object used during
> one transaction. I think we should get consensus on
> the terminology
> first.
> 

Again, I don't care much about what's in the app
package, but I think the idea of a one-way
FOTreeBuilder with just those three/four functions
exposed should be explored.

In general, too much business logic is in the apps
package, it evens knows about ElementMappings and
Renderers -- it shouldn't have to work with anything
that implementation-specific.  Also, AWTStarter and
PrintStarter appear to be in the wrong places, those
should somehow be moved out of apps and be *past*
FOTreeBuilder.  Let FOTreeBuilder decide to activate
those objects should it get an appropriate 
SetRenderType().

But my "mental model" in incomplete here...comments
most welcome!

Glen


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

cvs commit: xml-fop/src/documentation/content/xdocs news.xml relnotes.xml

[chrisg]

chrisg  2003/06/17 12:05:05

  Modified:src/documentation/content/xdocs news.xml relnotes.xml
  Log:
  added news about 0.20.5rc3
  
  Revision  ChangesPath
  1.11  +7 -0  xml-fop/src/documentation/content/xdocs/news.xml
  
  Index: news.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/news.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- news.xml  15 Apr 2003 14:42:02 -  1.10
  +++ news.xml  17 Jun 2003 19:05:05 -  1.11
  @@ -8,6 +8,13 @@
 
 
   
  +  23 May 2003 - FOP 0.20.5 Release Candidate 3 available
  +  
  +  See the full text of the http://archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&msgNo=5429">announcement.
  +  
  +
  +
 18 February 2003 - FOP 0.20.5 Release Candidate 2 available
 
 See the full text of the Important changes since the last release (0.20.4):
 
   Some hyphenation patterns (cs, da, de, de_DR, el, en, en_US, fr, nl,
  -no, pt, ru, sk, tr) have been removed due to licensing reasons.
  +no, pt, ru, sk, tr) have been removed due to licensing reasons
  +(en_GB hyphenation has been renamed to en).
   We hope to resolve this issue before the final release.
  -(English hyphenation is still available as en_GB)
   
   Documentation is now built with http://xml.apache.org/forrest/";>
  -Forrest (version 0.3). You need to install Forrest if you want build 
the docs
  +Forrest (version 0.4). You need to install Forrest if you want build 
the docs
   yourself. (See
   http://xml.apache.org/forrest/your-project.html";>Using 
Forrest)
   
  
  
  

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

cvs commit: xml-fop/src/documentation/content/xdocs compiling.xml

[chrisg]

chrisg  2003/06/17 12:04:05

  Modified:src/documentation/content/xdocs compiling.xml
  Log:
  small clarification
  
  Revision  ChangesPath
  1.8   +2 -1  xml-fop/src/documentation/content/xdocs/compiling.xml
  
  Index: compiling.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/compiling.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- compiling.xml 12 May 2003 01:19:11 -  1.7
  +++ compiling.xml 17 Jun 2003 19:04:05 -  1.8
  @@ -18,7 +18,8 @@
 
   JDK
 
  -Building FOP requires a minimum Java Development Kit (JDK) of 1.3.
  +Building FOP requires a minimum Java Development Kit (JDK/SDK) of 1.3
  +(A Java Runtime Environment ist not sufficient)
 
 
 
  
  
  

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

cvs commit: xml-fop/src/documentation/content/xdocs fo.xml

[chrisg]

chrisg  2003/06/17 12:02:25

  Modified:src/documentation/content/xdocs fo.xml
  Log:
  fixed typo
  Submitted by: John Collins <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.5   +1 -1  xml-fop/src/documentation/content/xdocs/fo.xml
  
  Index: fo.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/fo.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- fo.xml28 May 2003 08:09:04 -  1.4
  +++ fo.xml17 Jun 2003 19:02:25 -  1.5
  @@ -326,7 +326,7 @@
   
 Get the number of the last page as follows:
   
  -
  +
   
 This does not work in certain situations: multiple page sequences, an 
initial page number other than 1, or forcing a certain page count, thereby producing 
blank pages at the end.
   
  
  
  

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

Re: 0.20.5 release

[Jeremias Maerki]

On 17.06.2003 19:16:23 Christian Geisert wrote:
> RC3a seems to be rather stable and the changes since then look
> non-critical to me. What about doing the release now (read: next days)

+1

> (and maybe 0.20.5a later if we get more hyphenation patterns back)

Don't count on that. :-(

> Or should we make the changes proposed by Jörg (improved memory
> usage with tables - see 
> http://marc.theaimsgroup.com/?l=fop-dev&m=105399053227758 )
> which would require another release candidate.

Still -0.


Jeremias Maerki


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

RE: startup refactoring

[Victor Mote]

Victor Mote wrote:

> My humble apologies. What is the easiest way to roll it back? Is there an
> automated way?

I rolled them back manually, and have committed the change. All should be
back as it was before, except the affected files are two revisions higher.

Victor Mote


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

0.20.5 release

[Christian Geisert]

Ok,

RC3a seems to be rather stable and the changes since then look
non-critical to me. What about doing the release now (read: next days)
(and maybe 0.20.5a later if we get more hyphenation patterns back)
Or should we make the changes proposed by Jörg (improved memory
usage with tables - see 
http://marc.theaimsgroup.com/?l=fop-dev&m=105399053227758 )
which would require another release candidate.

Comments please!

Christian



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

Re: Eclipse Ant SerializeHyphPattern failure

[Jeremias Maerki]

Hmm, I've given up running Ant under Eclipse. Gave me too much of a
headache and it works well for me outside of Eclipse.

But I think the trick is to use "${basedir}" instead of "." in build.xml
because Eclipse has to set the base directory so everything is ok. I
have done some other changes locally that I cannot commit, yet, because
I'm blocked on an issue. So I can't commit my build.xml. Can you do it,
please?

On 17.06.2003 16:55:12 Peter B. West wrote:
> Trying to build HEAD using Ant under Eclipse, I get the following error 
> when the hyphenation build is attempted:
> 
> [serHyph] Fatal Error: source directory ./src/hyph for hyphenation files 
> doesn't exist.
> [serHyph] BUILD FAILED: file:/home/pbw/workspace/fop-head/build.xml:453: 
> org.eclipse.ant.core.AntSecurityException
> 
> Does anyone have any ideas about how to get around this?


Jeremias Maerki


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

Re: startup refactoring

[Jeremias Maerki]

On 17.06.2003 17:10:19 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > I'm a bit concerned that you call this "startup refactoring" where it's
> > really API redesign in the end, I think. And that's an important topic
> > where I would have expected you to ask for a "go for it" before starting
> > on this. Generally, JustDoIt (tm) is a good thing but this is about the
> > API and I'd like use to reach consensus on the direction. From the Wiki
> > page I read that there are substantial differences in our (you, Jörg, me)
> > ideas.
> 
> I certainly thought I had tacit consent.

Well, I'm certainly guilty of letting trail off that discussion. I'm
sorry if I missed anything.

> > I'm a bit unhappy that you placed/left Session in the apps package. I
> > would like to see the apps package deprecated as a whole over time. I
> > would like a cli package that only contains the stuff needed for the
> > command line and I'd like to have (wish, not a demand) the main FOP api
> > in the org.apache.fop package.
> 
> My humble apologies. What is the easiest way to roll it back? Is there an
> automated way?

I wasn't vetoing your changes, merely pointing out possible differences.
You didn't need to revert. But do you agree with what I wrote?



> OK. In my terminology, Session is a long-lived object that lives, well, for
> the Session. Document are children of Session. The only part of Session that
> you have seen is a renaming of Driver to Session. That is all that has been
> committed so far. But eventually nearly all of existing Driver gets pushed
> down to Document, RenderContext, and RenderTask. The only thing that really
> still lives in Session is the logging stuff, and it might belong with
> Document (under my scheme).

That's not what I'm talking about. Do we all agree on this terminology? Can
we find better classnames for what they are? These are key elements in
FOP's architecture. I'd like to have good names for them so they are
easily understandable even by outsiders. If you use Session you'll get
all sorts of strange questions. I'm pretty sure about that.



> Yes, I am talking about GoF Singleton. I understand the reluctance to use
> static variables, but I haven't adopted the no-tolerance approach that you
> have. The alternative is to either carry the static information around with
> you in every method that might need it, or to actually store the information
> in every object that might need it. I already see that with the logging. If
> it is needed, then OK, but I don't see it yet.

So I guess it's a matter of community decision what is preferred. Going
for statics and singleton is certainly easier but it'll carry you away
from the Avalon style of life. I have no problem if the majority of
committers think that Avalon should be thrown out. I didn't manage to
introduce the Avalon-patterns, yet, and it looks like I'm the only one
really pushing it so far but without enough power.


Jeremias Maerki


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

alt-design merits

[Peter B. West]

Peter B. West wrote:
If I have not answered your question, yell out.  I am quite happy to 
keep on at this until you at least understand my thinking on this, even 
if you don't agree with it.
But I will be keeping on with it tomorrow, as it is very late here.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

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

[vmote]

vmote   2003/06/17 09:35:58

  Modified:src/java/org/apache/fop/apps AWTStarter.java
CommandLineOptions.java CommandLineStarter.java
Driver.java FOInputHandler.java InputHandler.java
PrintStarter.java TraxInputHandler.java
XSLTInputHandler.java
   src/java/org/apache/fop/image XMLImage.java
   src/java/org/apache/fop/servlet FopPrintServlet.java
FopServlet.java
   src/java/org/apache/fop/svg SVGElementMapping.java
SVGUserAgent.java
   src/java/org/apache/fop/tools TestConverter.java
   src/java/org/apache/fop/tools/anttasks Fop.java
  Removed: src/java/org/apache/fop/apps Session.java
  Log:
  Revert refactoring of Driver to Session. Files affected should be identical to that 
which is two revisions earlier (e.g. if 1.3 is being checked in here, it should be 
identical to 1.1).
  
  Revision  ChangesPath
  1.4   +15 -15xml-fop/src/java/org/apache/fop/apps/AWTStarter.java
  
  Index: AWTStarter.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/AWTStarter.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- AWTStarter.java   17 Jun 2003 02:46:55 -  1.3
  +++ AWTStarter.java   17 Jun 2003 16:35:57 -  1.4
  @@ -3,34 +3,34 @@
* 
*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 promote products derived from this software without prior
*written permission. For written permission, please contact
*[EMAIL PROTECTED]
  - *
  + * 
* 5. Products derived from this software may not be called "Apache", nor may
*"Apache" appear in their name, without prior written permission of the
*Apache Software Foundation.
  - *
  + * 
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
  @@ -42,12 +42,12 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
* 
  - *
  + * 
* This software consists of voluntary contributions made by many individuals
* on behalf of the Apache Software Foundation and was originally created by
* James Tauber <[EMAIL PROTECTED]>. For more information on the Apache
* Software Foundation, please see .
  - */
  + */ 
   package org.apache.fop.apps;
   
   //FOP
  @@ -76,7 +76,7 @@
   public class AWTStarter extends CommandLineStarter {
   private PreviewDialog frame;
   private Translator translator;
  -private Session session;
  +private Driver driver;
   private XMLReader parser;
   
   /**
  @@ -101,8 +101,8 @@
   AWTRenderer renderer = new AWTRenderer(translator);
   frame = createPreviewDialog(renderer, translator);
   renderer.setComponent(frame);
  -session = new Session();
  -session.setRenderer(renderer);
  +driver = new Driver();
  +driver.setRenderer(renderer);
   parser = inputHandler.getParser();
   if (parser == null) {
   throw new FOPException("Unable to create SAX parser");
  @@ -115,10 +115,10 @@
* @throws FOPException FIXME should not happen.

Re: alt-design merits (WAS: Nomination of Glen Mazza as committer)

[Peter B. West]

Victor Mote wrote:
Peter B. West wrote:


Which modules?  I'm not sure what you mean.  The modularity of area
processing?  The Rec gives an utterly spurious view of this.  It has
been misleading developers since the drafts were first published, and
giving the impression that things can be neatly modularised.  Some of
the persistent difficulties of design arise from this misunderstanding.
 However, I may be misreading you here.  What modules do you
have in mind?


All right, educate me please. (I have read your doc and don't get it). In as
simple terms as possible (for my simple mind), why can't markers defer the
resolution of their properties until layout time?
They can.  They must.  But then what happens to the idea that the FO 
tree can be processed and refined before the layout occurs?  If you are 
going to defer the resolution, why not defer the parsing as well? 
Marker resolution requires the merging of the fo:static-content subtree 
(encountered *before* the corresponding fo:flow) with fo:marker subtrees 
which can only be determined as pages are laid out.  Furthermore, this 
process may repeat with *different* fo:marker subtrees being attached at 
the same fo:retrieve-marker point in the static-content.

With pull parsing, events are extracted from a parsing event buffer *as 
required*.  In general, this will occur "synchronously", but need not. 
The stream of static-content parsing events can be stashed away, the 
stream of fo:marker subtree events can be stashed away somewhere else, 
and the process of resolving the FO tree need never know that it is in 
fact reading an "asynchronous" stream of parser events in which 
fo:marker streams are attached by sleight-of-hand in place of the 
fo:retrieve marker dynamically and transparently, and that this parsing 
is happening after the event - well after the static-content was first 
encountered, and after the region-body has been laid out.  Furthermore, 
it can be "rewound" and repeated for as long as new pages with new 
fo.marker retrievals are required.

"Synchronous" and "asynchronous" are relative terms here.  It's all 
asynchronous, in the sense that the SAX component simply creates parse 
events and sticks them in a producer/consumer buffer.

The other problem is percentage lengths, where the percentage is defined 
against an enclosing area dimension.  Doesn't it make sense to create 
the area before you even look at the FOs which will fill it?  Creating 
the area also creates the context for the resolution of percentages.  In 
the difficult cases where the area dimension is initially indeterminate, 
the unresolvable percentage can at least be immediately "attached" to 
the area dimension whose resolution will in turn, resolve the 
percentage.  In most cases, however, the resolution will be immediate.

This approach, of having the containing area in place before parsing the 
contained FO subtree, is easy to implement with pull parsing, driven by 
the *areas*.

If I have not answered your question, yell out.  I am quite happy to 
keep on at this until you at least understand my thinking on this, even 
if you don't agree with it.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

alt-design merits (WAS: Nomination of Glen Mazza as committer)

[Victor Mote]

Peter B. West wrote:

> Which modules?  I'm not sure what you mean.  The modularity of area
> processing?  The Rec gives an utterly spurious view of this.  It has
> been misleading developers since the drafts were first published, and
> giving the impression that things can be neatly modularised.  Some of
> the persistent difficulties of design arise from this misunderstanding.
>   However, I may be misreading you here.  What modules do you
> have in mind?

All right, educate me please. (I have read your doc and don't get it). In as
simple terms as possible (for my simple mind), why can't markers defer the
resolution of their properties until layout time?

Victor Mote


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

RE: FOTreeBuilder/ElementMapping change ideas

[Victor Mote]

Peter B. West wrote:

> What's happened to the redesign?  I have nothing to prove - you guys do.
>   I'll just keep working, publishing design notes for anyone who is
> interested, and, when I get chunks of code working, I'll publish the
> comparisons.  Shall we put them to the vote?  Will a vote decide whether
> alt.design property handling is faster and smaller?

As I said before, there are opportunities to make redesign code faster and
smaller. To compare the two, we need to see the things that are unique to
the pull parsing approach. And more important than that, faster and smaller
will not trump cleaner and more flexible (at least for me).

> Note that I am quite happy to work towards integrating a fully-working
> FO and area tree susbsystem into the redesign.  I will not devote time
> to hacking such a working system apart to place nuggets of the original
> into a design in which I, as yet, have no confidence.

OK, this all-or-nothing approach is news to me. So Glen actually better
understood how matters stood on this issue than I did.

Victor Mote


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

RE: startup refactoring

[Victor Mote]

Jeremias Maerki wrote:

> I'm a bit concerned that you call this "startup refactoring" where it's
> really API redesign in the end, I think. And that's an important topic
> where I would have expected you to ask for a "go for it" before starting
> on this. Generally, JustDoIt (tm) is a good thing but this is about the
> API and I'd like use to reach consensus on the direction. From the Wiki
> page I read that there are substantial differences in our (you, Jörg, me)
> ideas.

I certainly thought I had tacit consent.

> I'm a bit unhappy that you placed/left Session in the apps package. I
> would like to see the apps package deprecated as a whole over time. I
> would like a cli package that only contains the stuff needed for the
> command line and I'd like to have (wish, not a demand) the main FOP api
> in the org.apache.fop package.

My humble apologies. What is the easiest way to roll it back? Is there an
automated way?

> And then I'm a bit unhappy about your terminology: Session, Document,
> RenderContext... Session and Document seem like "rubber terms" to me.
> Your Session looks very much like a FOProcessorFactory (analog to
> TransformerFactory). A session to me is a short-lived object used during
> one transaction. I think we should get consensus on the terminology
> first.

OK. In my terminology, Session is a long-lived object that lives, well, for
the Session. Document are children of Session. The only part of Session that
you have seen is a renaming of Driver to Session. That is all that has been
committed so far. But eventually nearly all of existing Driver gets pushed
down to Document, RenderContext, and RenderTask. The only thing that really
still lives in Session is the logging stuff, and it might belong with
Document (under my scheme).

> Sorry if I'm a bit negative here. I certainly don't want to kill any
> enthusiasm. FOP needs this more than ever.
>
> > 2. Logging. During the dry run, I realized that I don't know
> whether we want
> > to have logging for a Session, or for each Document, or even at
> some finer
> > level of granularity. Session will be implemented as a
> singleton, so if we
> > only need logging at that level, then a static construct can be
> used to get
> > logging from /anywhere/ without adding anything. Otherwise,
> I'll add logic
> > that allows the Document object to either be directly accessed
> or computed
> > (by going up the object hierarchy) to get the logger. That seems more
> > desirable to me than implementing logging in all of the
> classes, but perhaps
> > I am missing something there.
>
> You're talking about a singleton. I hope you don't mean a GoF Singleton.
> A GoF Singleton in Java usually involves a static variable which I would
> like to avoid in our new API.

Yes, I am talking about GoF Singleton. I understand the reluctance to use
static variables, but I haven't adopted the no-tolerance approach that you
have. The alternative is to either carry the static information around with
you in every method that might need it, or to actually store the information
in every object that might need it. I already see that with the logging. If
it is needed, then OK, but I don't see it yet.

> Static logging à la Commons-Logging is the easiest thing, sometimes even
> necessary if you ask people like Nicola Ken Barozzi. Even in
> Avalon-enabled software. The normal Avalon style of logging means a
> container is giving a logger instance to a service (see LogEnabled).
>
> As long as we're talking about services (Renderer, FOTreeBuilder,
> org.apache.excalibur.source.SourceResolver,
> org.apache.excalibur.xml.sax.SAXParser etc.), Avalon-style logging is
> superior (but more difficult to do right), because you can have multiple
> instances of the same service in a VM but logging to separate log files,
> for example, if you run two different applications in the same VM (in
> Avalon Phoenix, for example). You could have an invoicing system and a
> CRM system both running FOP for document production but logging to
> different log files. Ok, they could be separated by different
> classloaders but I still think not having statics in a server
> environment is better.

That sounds possibly useful for what we are doing.

Victor Mote


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

Eclipse Ant SerializeHyphPattern failure

[Peter B. West]

Trying to build HEAD using Ant under Eclipse, I get the following error 
when the hyphenation build is attempted:

[serHyph] Fatal Error: source directory ./src/hyph for hyphenation files 
doesn't exist.
[serHyph] BUILD FAILED: file:/home/pbw/workspace/fop-head/build.xml:453: 
org.eclipse.ant.core.AntSecurityException

Does anyone have any ideas about how to get around this?

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Ascii file generation questions

[Clay Leeds]

On 6/17/2003 6:37 AM, Illiano, Vincent wrote:
Thanks for your response to my posting.  I think a "mode" attribute to
indicate whether to preserve text or format is a good idea.
Either that, or add a '-ascii' attribute similar to '-txt' or 'pdf'... I 
realize this moves away from the 3 character extension (e.g., '-ps') but 
that may be better than adding a 'mode'... dunno. Unfortunately, I won't 
be able to help much, as my 'programming' skills are pretty much limited 
to hacking XSLT via the ol' trial and error method (emphasis on the 
error part...;-p).
--
Clay Leeds - [EMAIL PROTECTED]
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc

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

RE: Ascii file generation questions

[Illiano, Vincent]

Hi Art,

Thanks for your response to my posting.  I think a "mode" attribute to
indicate whether to preserve text or format is a good idea.  Formatting
issues can often be cleaned up by post-processing on the generated file.
I'm already doing this to remove the extra new line feeds that I've had to
add to solve the line overwriting problem.  But when 2 lines are rendered
onto each other - there is no way to fix that in a post-processing step.

Do you or anyone else reading this thread have an idea how hard it would be
to modify the TXTRenderer to preserve output text so that overwriting never
occurs?  Even though FOP's text output was never meant to be production
quality, it's pretty darn good.  I think a little tweaking to make it better
would be a nice feature to have.  I can volunteer to work on this.  A little
guidance would help me a lot.  Who is most familiar with the TXTRenderer?
Thanks, -V

Vincent Illiano
Senior Programmer/Analyst
Duke University Heart Center

> --
> From: [EMAIL PROTECTED]:[EMAIL PROTECTED]
> Sent: Monday, June 16, 2003 2:37 PM
> To:   [EMAIL PROTECTED]
> Subject:  RE: Ascii file generation questions
> 
> I do not know about the future of the TXTRenderer. But I do know a little
> bit about it's past.
> 
> The overwrite problem occurs because the TXTRenderer attempts to match the
> positioning/layout of the PDF/PCL Renderers. Unfortunately plain text of
> course does not have precise line positioning. Essentially the TXTRenderer
> attempts to fit the layout onto a fixed character matrix. Quantization
> effects cause the overwrite when a subsequent line ends up at the same
> line
> in the matrix as a previous line. I do not know that there is a perfect
> solution to this problem. Perhaps extra lines could be added if an
> overwrite
> would occur, but then the layout would be compromised (perhaps this would
> be
> better than an overwrite). One of the original constraints when the
> TXTRenderer was developed was that the text output fit within fixed page
> sizes (fixed number of rows/columns). Depending on your application, this
> may not be important. Perhaps a "mode" could be added to preserve text
> (versus preserving layout). The only consolation I have had with regard to
> the TXTRenderer is that I find its output superior to many commercial
> applications' lame text output (IMHO).
> 
> Art
> 
> -Original Message-
> From: Illiano, Vincent [mailto:[EMAIL PROTECTED] 
> Sent: Monday, June 16, 2003 2:28 PM
> To: Illiano, Vincent
> Cc: '[EMAIL PROTECTED]'
> Subject: Ascii file generation questions
> 
> 
> > Hi fellow Fop'ers,
> > 
> > I've built a dynamic document generation system using FOP.  I'm 
> > currently using version 0.20.4.  The 2 supported output formats are 
> > PDF and ASCII text.  I know that the ASCII renderer was never meant to 
> > be production quality.  However, with some tweaking, I have been able 
> > to get out of it what I need.  I'm including an example text output 
> > file that was generated by my system using FOP.
> > 
> > The main problem that I have found with the text output generation is 
> > the line-overwriting problem.  However, I have been able to fix this 
> > for the most part by adding extra space before the blocks where the 
> > overwriting occurs.  For example:
> > 
> > change
> > Procedure Comment
> > to
> > Procedure Comment
> > 
> > often fixes the overwriting problem that may occur in a particular 
> > paragraph of text.
> > 
> > Is there someone on this list who can explain to me why the 
> > overwriting problem occurs and if it's something that could be fixed?  
> > I can volunteer to dig in and do it myself with just a little 
> > guidance.  Also, is the text output feature planned in the redesign?  
> > I really hope so, because I think text is a valid output format.  
> > Again, I can volunteer to work on that feature if it's not already in 
> > the plan.
> > 
> > Here is the example text file.  Thanks, -Vincent
> > 
> >  <>
> > 
> 

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

Re: FOTreeBuilder/ElementMapping change ideas

[Peter B. West]

Glen Mazza wrote:
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:

I thought it was generally
agreed some time ago 
that my work on properties should be integrated, for
the simple reason 
that it is smaller and faster.  


Exactly!  Now you're talking my language--"smaller and
faster"--i.e., something that will generate more
same-size reports than trunk will
...
However, per the centripetal/centrifugal discussion of
Victor (*very* interesting, BTW), we need to see
*proof* that it is faster, and to help do that, we
should make the code more modular.
http://marc.theaimsgroup.com/?l=fop-dev&m=103890259919360&w=4
http://marc.theaimsgroup.com/?l=fop-dev&m=103918886413611&w=4
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[Peter B. West]

Victor Mote wrote:
Glen Mazza wrote:


No response on the below questions from any committer,
and I'm concerned about the drop-off on the FOP-DEV
mailing list over the past few weeks (at an
extrapolated 170 emails on FOP-DEV for the month, this
would be our lightest month since Dec. 1999!)  


Well, I think you solved that "problem" :-)
:-)

--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[Peter B. West]

Victor and fopdevs,

See below...

Victor Mote wrote:
Peter B. West wrote:


As to the necessary conditions for committer status, "Shall we take that
as read, darling?"*  The question remains, "If a another developer
happens along who 1) is persuaded that alt.design is worthwhile, and 2)
sees the existing properties code as a working implementation that is
better, and 3) wants to work on alt.design more or less exclusively,
will he/she be admitted to committer status with the - all other things
being equal - now customary alacrity?"
Will those existing committers who are not interested in alt.design
allow it to flourish in the (unlikely) event that it attracts the
interest of other developers, or will the Party line, necessary as that
may be considered, dictate the such a development be resisted?


I have exactly one vote on such matters, so I can't speak for the whole, but
as far as I am concerned, developers such as you describe are more than
welcome to join the party. In the event that alt-design remains on a branch,
I don't think any reasonable person could object. At the point in time that
we contemplate merging to the trunk, we need to come to an agreement. In the
unlikely event that we can't come to an agreement, we always have the option
to fork the project. My purpose here is to avoid that if possible.
BTW, I hope this isn't a Peter-vs.-Victor thing.
Absolutely not.  This is a question for all of the existing committers. 
 Your response above is exactly the one I would hope to see from 
everyone.  Incidentally, the project is already de facto forked - the 
purpose of integration is to bring the benefits of alt.design into the 
main redesign.

  For example, I know there
are opportunities to use less memory and more speed (which you report in
alt-design) in the FO tree creation. If memory serves, we are storing the
URL for the fo: namespace in every FONode object, which should be replaced
by an integer pointing into a table. I am very open to being educated, but I
think it is fair to say that I am not persuaded on all of it yet, and I
think the burden of proof lies heavily on you. Unless pull parsing is an
integral part of the whole, I think the alt-design changes will be best
swallowed in smaller pieces.
alt.design is a complete rewrite of the front end.  It could possibly be 
broken up and rejigged to use a standard SAX approach, but that would 
require major surgery, and would obviate a great deal of the advantage 
of doing away with the design convolution which is imposed by SAX.

There is no great design rationale in the basics of the current approach 
to FO tree parsing.  It is that way because it is obliged to be by SAX. 
 SAX imposes itself on design, unless it is forcibly restrained, and 
that imposition will, IMO, always be to the detriment of the design of 
complex systems with a well-understood structure to their data.

Clearly, that is a view that is not shared here, but it is one, which, I 
believe, has been and is being debated at length elsewhere.  Andy 
Clark's NekoPull variations on Xerces XNI are an attempt to provide a 
pull alternative for Open Source parsing.  It seems unproductive to try 
to debate the issue here; one either takes to it or one doesn't.

Also, if pull parsing can be implemented in a pluggable, configurable way
(ie. choose either push parsing or pull parsing at runtime), it will have a
much better chance of being accepted. My understanding of it is that it has
a pervasive effect, making separation between the modules more difficult
instead of less. IMO, absent a /significant/ benefit that cannot be achieved
some other way, this would be a deal-killer.
Which modules?  I'm not sure what you mean.  The modularity of area 
processing?  The Rec gives an utterly spurious view of this.  It has 
been misleading developers since the drafts were first published, and 
giving the impression that things can be neatly modularised.  Some of 
the persistent difficulties of design arise from this misunderstanding. 
 However, I may be misreading you here.  What modules do you have in mind?

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20827] - Style and weight supported use one Normal TureType Font.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20827

Style and weight supported use one Normal TureType Font.





--- Additional Comments From [EMAIL PROTECTED]  2003-06-17 07:15 ---
FOP only uses Java's font subsystem for the AWT Renderer. The other renderers 
use their own font subsystem. The AWT fonts suffer from several deficiencies 
where the most problematic is the fact that the behvaiour is inconsistent over 
JDK versions.

I'm pretty sure that if you want to wait for FOP to implement such a 
functionality for the PDF renderer, for examples, you have to be prepared to 
wait for a long time. The other solution is: you implement it yourself. You'll 
be better off finding another font that has italic characters.

Please close this bug if you find a work-around and you don't think this is 
very important.

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

Re: startup refactoring

[Jeremias Maerki]

On 17.06.2003 01:38:14 Victor Mote wrote:
> I did a dry run of the startup refactoring (Session, Document, etc.) work
> yesterday & this morning, and am satisfied that the concepts work.
> Here are some comments:
> 
> 1. I am going to start committing changes, hopefully this evening. Much of
> the work is refactoring, but there are some substance changes as well,
> specifically to allow multiple output options, multiple documents, etc. I
> have therefore decided to implement it as a series of self-contained
> changes, rather than dropping the entire change in at once. This will make a
> better doc trail. Let me know if you object.

I'm a bit concerned that you call this "startup refactoring" where it's
really API redesign in the end, I think. And that's an important topic
where I would have expected you to ask for a "go for it" before starting
on this. Generally, JustDoIt (tm) is a good thing but this is about the
API and I'd like use to reach consensus on the direction. From the Wiki
page I read that there are substantial differences in our (you, Jörg, me)
ideas.

I'm a bit unhappy that you placed/left Session in the apps package. I
would like to see the apps package deprecated as a whole over time. I
would like a cli package that only contains the stuff needed for the
command line and I'd like to have (wish, not a demand) the main FOP api
in the org.apache.fop package.

And then I'm a bit unhappy about your terminology: Session, Document,
RenderContext... Session and Document seem like "rubber terms" to me.
Your Session looks very much like a FOProcessorFactory (analog to
TransformerFactory). A session to me is a short-lived object used during
one transaction. I think we should get consensus on the terminology
first.

Sorry if I'm a bit negative here. I certainly don't want to kill any
enthusiasm. FOP needs this more than ever.

> 2. Logging. During the dry run, I realized that I don't know whether we want
> to have logging for a Session, or for each Document, or even at some finer
> level of granularity. Session will be implemented as a singleton, so if we
> only need logging at that level, then a static construct can be used to get
> logging from /anywhere/ without adding anything. Otherwise, I'll add logic
> that allows the Document object to either be directly accessed or computed
> (by going up the object hierarchy) to get the logger. That seems more
> desirable to me than implementing logging in all of the classes, but perhaps
> I am missing something there.

You're talking about a singleton. I hope you don't mean a GoF Singleton.
A GoF Singleton in Java usually involves a static variable which I would
like to avoid in our new API.

Static logging à la Commons-Logging is the easiest thing, sometimes even
necessary if you ask people like Nicola Ken Barozzi. Even in
Avalon-enabled software. The normal Avalon style of logging means a
container is giving a logger instance to a service (see LogEnabled).

As long as we're talking about services (Renderer, FOTreeBuilder,
org.apache.excalibur.source.SourceResolver,
org.apache.excalibur.xml.sax.SAXParser etc.), Avalon-style logging is
superior (but more difficult to do right), because you can have multiple
instances of the same service in a VM but logging to separate log files,
for example, if you run two different applications in the same VM (in
Avalon Phoenix, for example). You could have an invoicing system and a
CRM system both running FOP for document production but logging to
different log files. Ok, they could be separated by different
classloaders but I still think not having statics in a server
environment is better.


Jeremias Maerki


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