DO NOT REPLY [Bug 25248] - XSL Parameter passing

[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://issues.apache.org/bugzilla/show_bug.cgi?id=25248

XSL Parameter passing

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-20 03:46 ---
Maintenance branch is frozen (0.20.5), however this has just been implemented in
our upcoming (1.0) version:

Usage from command line: -param paramName1 value1 -param paramname2 value2 ...
For values with a space, delimit the value with double quotes.

1.0 is currently working only with RTF, however--it's not yet ready for general use.

Thanks,
Glen

Withdrawal of PMC nomination

[Peter B. West]

Fopsters,
I have been discussing with Jeremias offline the appropriateness or 
otherwise of my being on the XML Graphics PMC.  On reflection, I had 
some reservations, and I have decided to withdraw my nomination for the 
XML Graphics PMC, on the understanding that I will continue to take a 
keen interest in the factoring out of the graphics components.

Peter
--
Peter B. West 

RE: FOray 0.1 release

[Victor Mote]

Chris, Jeremias, and anyone else looking at FOray code:

I have created the following branch in FOray's CVS that you will want to use
for your evaluation:
rel_0_1_branch

I have started some other changes in the root that should probably be
evaluated separately.

I apologize for the inconvenience. I really should have done this from the
start.

Victor Mote

RE: FOray 0.1 release

[Victor Mote]

Jeremias Maerki wrote:

> I'm simply thinking that adding statics is a lot easier than 
> removing them again. I usually create non-static classes and 
> create singletons around them if necessary or convenient. 
> That's basically it.
> 
> > One of the main purposes of
> > FontServer was to share as much of the Font overhead as possible 
> > between documents in a heavy server environment, while 
> keeping a light 
> > footprint in the code. I actually tried to write it in a non-static 
> > way (with you in
> > mind) in the beginning, but it just ended up being silly, 
> at least for 
> > the purposes that it is currently designed for.
> 
> Of course, it makes sense to take the easy way to get quick results.
> I'm just thinking about the long run.

I didn't do it for the quick results, but for the lighter, cleaner effect in
the client application. Consider the pro-forma FontServer static method
someMethod(). Right now, using such a method is simply
FontServer.someMethod(). If I convert FontServer to a singleton, I see only
two choices:
1. Create a static method getInstance() to return the singleton. To use
someMethod(), I now need: FontServer.getInstance().someMethod().
2. Cache the FontServer instance somewhere in the application client and
pass it around. To use someMethod(), I now need:
someObject.getFontServer().someMethod().

The only reason I can think of to use a Singleton instead of statics is that
I might want to change my mind later & allow multiple instances. Since I
have been unable to find even a potential use case for multiple instances
that isn't covered by better client configuration, I didn't see the need for
the extra complexity. However, I am not really opposed to using a singleton,
and if it will make folks more comfortable, I'll reimplement it that way.
BTW, I was under the impression that you disliked GoF singletons as much as
statics. Are you OK with one here?

> > Second, I *know* that, while in many ways HEAD is superior to the 
> > maintenance branch, there are many specific instances where the 
> > maintenance branch is superior to HEAD. I also know that 
> there is no 
> > convenient list of such items. I have to choose between the 
> two evils 
> > of 1) losing benefit(s) in the old code, and 2) losing 
> benefit(s) in 
> > the new code. Of the two, I prefer the latter. The user is 
> not going 
> > to be happy if I remove his wheels while installing the new, more 
> > powerful engine. Better IMO for us to upgrade the engine in 
> a manner 
> > that ensures that the wheels stay on. FOP is kind of into 
> the chasm thing, and FOray is definitely not.
> 
> Right, but would you reconsider (in the long run) if we 
> worked towards seperately released components that could be 
> stabilized and shared between the different implementations? 
> All in the spirit of avoiding duplicate effort where this is possible?

I understand you to be asking whether I want to create components that can
be used by both the maintenance branch and HEAD. The answer is an emphatic
YES. And I want all of the features that are in HEAD in those components.
The only thing I meant to disagree with was the suggested approach of
starting with HEAD as the baseline. IMO the correct approach is to start
with the maintenance branch as the baseline and try to add in the code that
has been added to HEAD as we are able to identify it and port it. Neither
approach is ideal.

If I understood the above correctly, then you and I may be in pretty close
agreement on this whole approach. And, if you extend it a bit to other parts
of FOP, you can see where I was headed with the isolation of FOTree,
AreaTree, etc. It should be possible to factor everything out of FOP until
you are left with layout, which could be / should be / would be the only
difference between the maintenance branch and HEAD. Add in the concept of
LayoutStrategy, and you have everything back in one unified line of
development.

> > and we can
> > reconcile them. Ideally we want to get to the place where both 
> > branches are using the same code. I *think* that is pretty easy for 
> > Fonts and Graphics, but, as you say, probably not as easy 
> for PDF, and probably PostScript too.
> 
> If it's possible for fonts then I'm sure it's possible for PDF and PS.

My perception is that *not* many features have been added to fonts and
graphics in HEAD, but that many have been for PDF and (possibly) PS. So my
thinking is that if we missed a thing or two in fonts and graphics, we'll
just deal with it as it comes. But with PDF and PS, we run the risk of
losing some large chunks of utility if we don't have either 1) someone
familiar with the changes guide the porting, or 2) someone go through some
detailed diff work to try to ferret out the changes. I just want to make
sure that my insistence in starting with the maintenance branch code instead
of HEAD isn't perceived as underestimating the difficulty in that approach.
It is ugly -- I just think it is less ugly than t

Re: SAXParserFactory vs. TransformerFactory (was: Re: cvs commit: ....)

[Glen Mazza]

I agree; however we are none the worse off for Simon's
SAXParser example, and we even got a more powerful
DefaultHandler object in our API as a bonus.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I simply think that the
> Transformer pattern is very
> universal and quite easy to use and understand.
> 

Re: FOray 0.1 release

[Jeremias Maerki]

Sorry for the delay.

On 16.07.2004 19:00:25 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > Making these parts into separate components is in line with 
> > what I have in mind when can talk about a shared repository 
> > between Batik and FOP. I hope I can take a good look into 
> 
> Good. I think it has potential to be useful to many applications.
> 
> > what you did later. From a quick look, however, I wasn't very 
> > pleased that you propose to use a lot of statics in the 
> > "FontServer". I would prefer to have the possibility to 
> > define multiple configurations in a heavy server environment 
> > without having to go through the pains to separate multiple 
> > environments using classloader magic. The system fonts are ok 
> > like this, of course, but not the user-defined. Just my opinion.
> 
> I knew this would be controversial, and I'll be glad to consider changes.
> The use case that you mentioned will, I think, be handled by some of the
> other planned changes to configuration that are in the works. These changes
> will be more client-centered than server-centered. So, rather than having
> multiple servers configured different ways, each client will tell the server
> more about what it wants, and the server will react based on this. However,
> I may not see all of what you are thinking about here. If you can be more
> specific, I'll think through this some more.

I'm simply thinking that adding statics is a lot easier than removing
them again. I usually create non-static classes and create singletons
around them if necessary or convenient. That's basically it.

> One of the main purposes of
> FontServer was to share as much of the Font overhead as possible between
> documents in a heavy server environment, while keeping a light footprint in
> the code. I actually tried to write it in a non-static way (with you in
> mind) in the beginning, but it just ended up being silly, at least for the
> purposes that it is currently designed for.

Of course, it makes sense to take the easy way to get quick results.
I'm just thinking about the long run.

> > Concerning the PDF library, I suggest you start from the PDF 
> > lib in CVS HEAD instead of using the maintenance branch, even 
> > if it means that the API may be a bit different. I've 
> > invested a considerable amount of time to make the whole 
> > thing better. Things such as encryption are much more cleanly solved.
> 
> First, in relation to FOP 0.20.5 (approximately FOray's starting place), the
> changes that you are talking about are improvements, and I don't want to be
> introducing changes or improvements yet. The goal here is really to make
> sure nothing is broken. Then we can start making improvements, releasing
> them, and getting user feedback.

Valid approach. I'm trying to find ways to bring everyone together in
places where consensus may be possible. 

> Second, I *know* that, while in many ways HEAD is superior to the
> maintenance branch, there are many specific instances where the maintenance
> branch is superior to HEAD. I also know that there is no convenient list of
> such items. I have to choose between the two evils of 1) losing benefit(s)
> in the old code, and 2) losing benefit(s) in the new code. Of the two, I
> prefer the latter. The user is not going to be happy if I remove his wheels
> while installing the new, more powerful engine. Better IMO for us to upgrade
> the engine in a manner that ensures that the wheels stay on. FOP is kind of
> into the chasm thing, and FOray is definitely not.

Right, but would you reconsider (in the long run) if we worked towards seperately
released components that could be stabilized and shared between the
different implementations? All in the spirit of avoiding duplicate
effort where this is possible?

> Third, what you suggest is much easier said than done. I have made a note to
> specifically check the encryption stuff when I get a chance. I suppose that
> we can either diff the code (probably only useful to those who wrote it) or
> use "missing feature" hunt. IOW, if we get to the place where we are
> releasing code again, then, when issues come up on fop-user, hopefully you
> or someone else will say "I already fixed that in HEAD",

Oh, I said that a number of times already. ;-)

> and we can
> reconcile them. Ideally we want to get to the place where both branches are
> using the same code. I *think* that is pretty easy for Fonts and Graphics,
> but, as you say, probably not as easy for PDF, and probably PostScript too.

If it's possible for fonts then I'm sure it's possible for PDF and PS.


Jeremias Maerki

Re: SAXParserFactory vs. TransformerFactory (was: Re: cvs commit: ....)

[Jeremias Maerki]

I don't think there's a considerable difference. The identity
transformer in Xalan-J is essentially a SAXParser and a 1:1
piping-through of SAX events. It's just a bit more setup code for the
Transformer variant, I think. The choice about what to use is really
personal preference. I simply think that the Transformer pattern is very
universal and quite easy to use and understand.

On 18.07.2004 02:33:21 Glen Mazza wrote:
> Incidentally, is there any significant performance
> difference between the two methods?  I'm hoping "no",
> i.e., we can use internally whichever proves more
> convenient.



Jeremias Maerki

DO NOT REPLY [Bug 30138] - NullPointerException in rtf-renderer

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30138

NullPointerException in rtf-renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-07-19 11:50 ---
Thanks und vielen Dank!