Re: fop.xconf

[Glen Mazza]

I haven't looked at it--but this was before my time on
the project, fop.xconf hasn't been altered since
December 2002.  It appears to be related to
Avalonization of FOP.  For the benefit of other
relative newcomers, it is located here:

http://cvs.apache.org/viewcvs.cgi/xml-fop/conf/fop.xconf

And the project's earlier discussion on it is here:

http://marc.theaimsgroup.com/?l=fop-dev&w=2&r=1&s=fop.xconf&q=b

Glen

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Fops,
> 
> What's the intention for fop.xconf?  Is it to be
> processed by the user 
> agent?  What about user configuration?  Have these
> things been decided yet?
> 
> Peter
> -- 
> Peter B. West
> 
> 

Re: namespace-prefixes

[Glen Mazza]

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> In HEAD, ///apps/FOFileHAndler.java contains the
> following:
> 
>  factory.setFeature(
> 
> "http://xml.org/sax/features/namespace-prefixes";,
> true);



> That is, I would turn allow the namespace-prefixes
> feature to remain in 
> its default 'false' state, but make sure the parser
> is namespace aware. 
>   I don't know that there is any reason for us to
> collect prefixes, 

This is somewhat outside my knowledge, but one
difference, I believe, between HEAD and Alt-Design is
the former's ability to have user-configured, run-time
add-in element mappings.  (I think we have one for
MathML and another one for something else in our
examples.)  Given that, could that be HEAD's reason
for needing to collect prefixes?

Glen

namespace-prefixes

[Peter B. West]

Fops,

In HEAD, ///apps/FOFileHAndler.java contains the following:

protected static XMLReader createParser() throws FOPException {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
factory.setFeature(
"http://xml.org/sax/features/namespace-prefixes";, true);
return factory.newSAXParser().getXMLReader();
} catch (SAXNotSupportedException se) {
throw new FOPException("Error: You need a parser which 
allows the"
   + " http://xml.org/sax/features/namespace-prefixes";
   + " feature to be set to true to support 
namespaces", se);

I would be inclined to modify that to:

protected static XMLReader createParser() throws FOPException {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
return factory.newSAXParser().getXMLReader();
} catch (SAXNotSupportedException se) {
throw new FOPException("Error: You need a parser which 
allows the"
   + " http://xml.org/sax/features/namespaces";
   + " feature to be set to true to support 
namespaces", se);

That is, I would turn allow the namespace-prefixes feature to remain in 
its default 'false' state, but make sure the parser is namespace aware. 
 I don't know that there is any reason for us to collect prefixes, 
rather than simply allowing the parser to keep track of the namespaces 
in effect and return namespace and local names.  That's what I have done 
in alt-design without any regrets so far.

Peter
--
Peter B. West 

fop.xconf

[Peter B. West]

Fops,

What's the intention for fop.xconf?  Is it to be processed by the user 
agent?  What about user configuration?  Have these things been decided yet?

Peter
--
Peter B. West 

Re: fop-dev used to spread virus

[Glen Mazza]

Thanks, Manuel.  We have about 430 people on FOP-DEV,
last time we checked, so it would be hard to find the
problem account.  Still, sending to infrastructure...
(well, I believe it's called infrastructure @ apache
dot org, I'll be corrected soon otherwise... )

Glen


--- Manuel Mall <[EMAIL PROTECTED]> wrote:
> The e-mail to fop-dev below which I received last
> night contained the Beagle
> virus and according to the SMTP headers it was
> distributed via the Apache
> mail server. This seems to indicate that
> 
> a) The Apache list server has no virus scanner.
> 
> b) As the fop-dev list is by subscription only that
> a fop-dev member (or an
> impersonator) has an infected computer.
> 
> Manuel
> 
> ===
> 
> Received: from mail.apache.org (daedalus.apache.org
> [208.185.179.12]) by
> kant.arcus.com.au with SMTP (Microsoft Exchange
> Internet Mail Service
> Version 5.5.2650.21)
>  id FDYXCPQN; Wed, 3 Mar 2004 23:23:09 +0800
> Received: (qmail 74020 invoked by uid 500); 3 Mar
> 2004 15:23:01 -
> Received: (qmail 73804 invoked from network); 3 Mar
> 2004 15:22:59 -
> Received: from unknown (HELO nagesh) (4.65.248.67)
>   by daedalus.apache.org with SMTP; 3 Mar 2004
> 15:22:59 -
> Mailing-List: contact [EMAIL PROTECTED];
> run by ezmlm
> Precedence: bulk
> list-help: 
> list-unsubscribe:
> 
> list-post: 
> Reply-To: [EMAIL PROTECTED]
> Delivered-To: mailing list [EMAIL PROTECTED]
> Date: Wed, 03 Mar 2004 09:28:45 -0600
> To: [EMAIL PROTECTED]
> Subject: Notify about using the e-mail account.
> From: [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> boundary="majfmldnfpkyieyerphp"
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> 
> --majfmldnfpkyieyerphp
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> Dear user, the  management  of Apache.org mailing
> system  wants to  let  you
> know  that,
> 
> Your  e-mail account  will  be disabled because  of 
> improper using in  next
> three days, if you are still  wishing to use it,
> please,  resign your
> account information.
> 
> Please, read the  attach for  further details.
> 
> Sincerely,
>  The Apache.org team
> http://www.apache.org
> 
> 
> 

fop-dev used to spread virus

[Manuel Mall]

The e-mail to fop-dev below which I received last night contained the Beagle
virus and according to the SMTP headers it was distributed via the Apache
mail server. This seems to indicate that

a) The Apache list server has no virus scanner.

b) As the fop-dev list is by subscription only that a fop-dev member (or an
impersonator) has an infected computer.

Manuel

===

Received: from mail.apache.org (daedalus.apache.org [208.185.179.12]) by
kant.arcus.com.au with SMTP (Microsoft Exchange Internet Mail Service
Version 5.5.2650.21)
 id FDYXCPQN; Wed, 3 Mar 2004 23:23:09 +0800
Received: (qmail 74020 invoked by uid 500); 3 Mar 2004 15:23:01 -
Received: (qmail 73804 invoked from network); 3 Mar 2004 15:22:59 -
Received: from unknown (HELO nagesh) (4.65.248.67)
  by daedalus.apache.org with SMTP; 3 Mar 2004 15:22:59 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: 
list-unsubscribe: 
list-post: 
Reply-To: [EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
Date: Wed, 03 Mar 2004 09:28:45 -0600
To: [EMAIL PROTECTED]
Subject: Notify about using the e-mail account.
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="majfmldnfpkyieyerphp"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

--majfmldnfpkyieyerphp
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear user, the  management  of Apache.org mailing system  wants to  let  you
know  that,

Your  e-mail account  will  be disabled because  of  improper using in  next
three days, if you are still  wishing to use it, please,  resign your
account information.

Please, read the  attach for  further details.

Sincerely,
 The Apache.org team
http://www.apache.org

Re: fop minimum requirements

[J.Pietschmann]

Clay Leeds wrote:
...but what you're saying, is that there should not be problems for 
*binary* versions--only if users want to build from src themselves under 
1.2.
Well, "no problems reported" doesn't mean "no problems". There
may be well hidden problems in rarely used functionality, and
people stumbling over them just stopped using FOP.
It's certainly better to check.
J.Pietschmann

Re: fop minimum requirements

[Clay Leeds]

On Mar 3, 2004, at 1:23 PM, J.Pietschmann wrote:
Clay Leeds wrote:
p.s. On second thought, maybe that'll be something I'll figure out 
myself (although it would be better if the legwork were already done! 
:-D)
I don't have intentions to install a 1.2 on my smallish
and almost full HD. There were, however, *zero* complaints
about problems running 0.20.4 or 0.20.5. There were some
poeple stuck with an oldish IBM 1.1.8 (or even 1.0.x) JDK
on some exotic platforms, therefore if there were problems
for typical use cases, I expect at least one to report it.
Users of the precompiled binaries wont necessarily notice
any problems though.
J.Pietschmann
It's certainly a relief that there were no reported problems. I was 
concerned with this portion of your response:

Acutually I doubt FOP 0.20.5 will run completely in an 1.2 
environment.
The binary is compiled with 1.4.1, and I vaguely remember compiling
problems already for 0.20.4 on 1.2.
...but what you're saying, is that there should not be problems for 
*binary* versions--only if users want to build from src themselves 
under 1.2.

If I understand things correctly, my response is "Sounds good!"

Web Maestro Clay

Re: fop minimum requirements

[J.Pietschmann]

Clay Leeds wrote:
p.s. On second thought, maybe that'll be something I'll figure out 
myself (although it would be better if the legwork were already done! :-D)
I don't have intentions to install a 1.2 on my smallish
and almost full HD. There were, however, *zero* complaints
about problems running 0.20.4 or 0.20.5. There were some
poeple stuck with an oldish IBM 1.1.8 (or even 1.0.x) JDK
on some exotic platforms, therefore if there were problems
for typical use cases, I expect at least one to report it.
Users of the precompiled binaries wont necessarily notice
any problems though.
J.Pietschmann

Re: Thanks Jeremias

[Jeremias Maerki]

You guys are welcome. Thanks for the cheering.

So what's left? Basically your special branch if you haven't converted
everything, yet (I didn't check). It's probably ok to leave the
maintenance branch in the fridge. And I guess I can give the hyphenation
stuff a few minutes on Friday.

One thing, though: If I've see correctly there's a growing number of
files that have CVS keyword substitution disabled. We may want to
address that eventually.

On 03.03.2004 00:53:51 Peter B. West wrote:
> Thanks again, Jeremias, for all of the licensing housekeeping.  I'm 
> sorry I didn't get around to giving you a hand with this.  Does anything 
> (apart from the hyphenation mess) remain to be done?


Jeremias Maerki

fop minimum requirements

[Clay Leeds]

FOP's minimum requirements[1]:

System Requirements

The following software must be installed:
	â 	Java 1.2.x or later Runtime Environment.
	â 	FOP. The FOP distribution includes all libraries that you will 
need to run a basic FOP installation. These can be found in the 
xml-fop/lib directory. These libraries include the following:
	â 	 Apache Xerces-J for XML parsing. You can use other XML parsers 
which support SAX and DOM.
	â 	Apache Xalan-J, an XSLT processor.
	â 	Apache Batik, an SVG library.
However, according to J.Pietschmann[2]:

Chris Bowditch wrote:
> I did a quick search of the archives and found the thread that 
decrees
> 1.1 will no longer be supported and the minimum JDK is 1.2.

Acutually I doubt FOP 0.20.5 will run completely in an 1.2 environment.
The binary is compiled with 1.4.1, and I vaguely remember compiling
problems already for 0.20.4 on 1.2.
J.PIetschmann
It would be nice to *know* (and post on our site) the "real" 
requirements for running FOP. If there are different minimum 
requirements for fop-20.4 and fop-0.20.5, this information should be on 
the FOP site. fop-users looking to fill their needs shouldn't have to 
download the latest version only to find it doesn't work under their 
lowly JRE.

Web Maestro Clay

p.s. On second thought, maybe that'll be something I'll figure out 
myself (although it would be better if the legwork were already done! 
:-D)

[1]
http://xml.apache.org/fop/running.html
[2]
http://marc.theaimsgroup.com/?l=fop-dev&m=107353819024636&w=2

Re: Cocoon appears to be switching to 1.4

[Clay Leeds]

On Mar 3, 2004, at 1:39 AM, Bertrand Delacretaz wrote:
Le Mercredi, 3 mars 2004, à 10:27 Europe/Zurich, Chris Bowditch a 
écrit :
Glen Mazza wrote:
They're currently voting on the Cocoon side[1] to set
1.4 as the minimum JDK for their next 2.2 release.  So
far it looks good for approval.
I'm not so sure it does, look at the 3rd mail in the thread:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107813002510299&w=2

and this sparks off a debate about how many users still require 1.3, 
etc
You're right, this is only being discussed at the moment.

And if the switch to 1.4 happens, it will only be (AFAIK) with the 
Cocoon 2.2 release, for which there is not set date at the moment.
I assume this would be akin to 0.20.5 (and any updates--however minor 
they may be) continuing to operate under the current minimum system 
requirements, but 1.0+ requiring 1.4.

Also, there is a push to keep the requirement at 1.3 for the Cocoon 
core, leaving blocks free to require either 1.3 or 1.4.
That sounds like it might be a nice idea for a solution, although I 
can't imagine what portions would continue to require 1.3+ (1.2+?), and 
what would require 1.4+.

So it might be better not to let this influence the FOP decision.

-Bertrand
[brief anecdote]
The owner of my company would rather spend extra money/time developing 
a product so they make the lives of users easier, rather than make the 
lives of programmers easier. In other words, a switch to requiring 1.4 
should not be done merely to make the lives of fop-dev'ers easier, but 
instead would be done to make the lives of our fop-users easier.
[/brief anecdote]

I guess I still don't know what the benefits of switching to JDK 1.4+ 
are to _users_ (see below).

BTW, if we don't raise the bar to 1.4 (min Sys Req remains 1.3 or 1.2) 
might a user running under 1.4 still get some of the benefits of 1.4? 
Or, alternatively, would it be worth the effort to maintain 1.2/1.3 
compatibility & also include support for 1.4 features.

For my benefit (and others?) here's a brief list of "features" I think 
we can expect from a jump to Java SDK 1.4:

- performance enhancements (similar to the HashTable => HashMap change 
allowed by jump from 1.1 to 1.2+)[1]
- nestable exceptions which will make problem tracking much easier[2]
- the BIDI support[2]
- other AWT fixes and extensions[2]
- JCE by default (people will still have to get a RC4 provider though 
:-/)[2]
- And 1.4 has java.util.logging and java.util.prefs[2]

What other 'benefits' should we expect from making the jump to 1.4?

Web Maestro Clay

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

Notify about using the e-mail account.

[noreply]

Dear user, the  management  of Apache.org mailing system  wants to  let  you  know  
that,

Your  e-mail account  will  be disabled because  of  improper using in  next
three days, if you are still  wishing to use it, please,  resign your
account information.

Please, read the  attach for  further details.

Sincerely,
 The Apache.org teamhttp://www.apache.org
<>

Re: Thanks Jeremias

[Glen Mazza]

HOORAY  :)

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> I would also like to thank Jeremias for sorting out
> the licensing, not 
> the nicest of jobs, so three cheers for Jeremias,
> hip hip :-)
> 
> Chris
> 
> 

Re: Cocoon appears to be switching to 1.4

[Bertrand Delacretaz]

Le Mercredi, 3 mars 2004, à 10:27 Europe/Zurich, Chris Bowditch a écrit 
:

Glen Mazza wrote:

They're currently voting on the Cocoon side[1] to set
1.4 as the minimum JDK for their next 2.2 release.  So
far it looks good for approval.
I'm not so sure it does, look at the 3rd mail in the thread:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107813002510299&w=2

and this sparks off a debate about how many users still require 1.3, 
etc
You're right, this is only being discussed at the moment.

And if the switch to 1.4 happens, it will only be (AFAIK) with the 
Cocoon 2.2 release, for which there is not set date at the moment.

Also, there is a push to keep the requirement at 1.3 for the Cocoon 
core, leaving blocks free to require either 1.3 or 1.4.

So it might be better not to let this influence the FOP decision.

-Bertrand

Re: Cocoon appears to be switching to 1.4

[Chris Bowditch]

Glen Mazza wrote:

They're currently voting on the Cocoon side[1] to set
1.4 as the minimum JDK for their next 2.2 release.  So
far it looks good for approval.
I'm not so sure it does, look at the 3rd mail in the thread:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107813002510299&w=2

and this sparks off a debate about how many users still require 1.3, etc.

This would be good news for us, as it would remove one
of the major risks (incompatibility with Cocoon)
involved with adopting 1.4 on our side.
I know Ive moaned about this in the past, but I'm concerned that 
upgrading FOP to JDK 1.4 will make FOP unavailable to x% of the 
potential users. Now if x% is a significant figure then FOP becomes in 
danger of failing in a manner similar to xmlroff.

I hope Tony Graham and any one else out there whos using xmlroff doesnt 
take offence at me saying this, but Ive been following the xmlroff 
project, and there seems to about 1 mail/month on their user list. I 
believe this is because xmlroff is unavailable to a significant % of the 
potential user base, i.e. it doesnt run on windows. I can tell you now 
if it did run on windows our company would be using it, and possibly 
contributing towards it.

Anyway, my point is simply that if x% is significant then we should hold 
off on this, and I will vote -1. However, if x% is very small then i'll 
vote +0. So before making a decision I propose we do some research to 
find out what x% is?! Which is the conclusion that cocoon-dev appear to 
come to, in the discussion thread above.

Chris

Re: Thanks Jeremias

[Chris Bowditch]

Peter B. West wrote:

Thanks again, Jeremias, for all of the licensing housekeeping.  I'm 
sorry I didn't get around to giving you a hand with this.  Does anything 
(apart from the hyphenation mess) remain to be done?

Peter
I would also like to thank Jeremias for sorting out the licensing, not 
the nicest of jobs, so three cheers for Jeremias, hip hip :-)

Chris