Commits

[Chris Bowditch]

Team,
thanks to everyone who agreed to hold off commits until the fate of Luca's 
patch had been decided. I think everyone is in agreement that this first patch 
needs more work, so I will re-sync with CVS. Therefore, it is safe to make 
commits to HEAD once more.

Thanks,
Chris

Re: InputHandler - re baseURL commits

[Peter B. West]

Glen Mazza wrote:
(Hmmm...I'm supposed to be learning Cocoon right now,
but am already suffering FOP-withdrawal.  Apache's got
me good...  ;)
[just removed the namespace-prefixes issue you were
mentioning earlier, btw.]
I noticed that.

FOFileHandler.createParser() is just a simple static
function that generates a parser.  It can be placed in
any class, and is not something that needs to be 
inherited. (Actually, the hyphenation class'
PatternParser also creates a parser, although it could
use the one in FOFileHandler as well.)

InputHandler has a abstract getParser() method which
is used by Driver et. al.  This method *does* need to
be overridden in each of the base classes, and of
course it is.  

It just so happens, but is not necessarily required,
that the current implementation of XSLTInputHandler
uses the createParser() of FOFileHandler for its
implementation of getParser().  This is just an
implementation detail. 

XSLTInputHandler's getXMLFilter() (called by its
getParser()):

// Create an XMLReader.
XMLReader parser = FOFileHandler.createParser();

I preferred the direct reference to the FOFileHandler
method (as opposed to simple inheritance) for reasons
of documentation:  this way, we're clearly stating
that XSLTInputHandler is using FOFileHandler's parser
as part of its XMLFilter.
(Also, at the time I was doing this, I was planning on
having a DOMInputHandler--but was running into
difficulty doing so--that I believe would have caused
a createParser() to not have been relevant in the base
class.)
Glen,

Thanks for the explanation, and thanks for surfacing.

Peter
--
Peter B. West 

Re: InputHandler - re baseURL commits

[Glen Mazza]

(Hmmm...I'm supposed to be learning Cocoon right now,
but am already suffering FOP-withdrawal.  Apache's got
me good...  ;)

[just removed the namespace-prefixes issue you were
mentioning earlier, btw.]

FOFileHandler.createParser() is just a simple static
function that generates a parser.  It can be placed in
any class, and is not something that needs to be 
inherited. (Actually, the hyphenation class'
PatternParser also creates a parser, although it could
use the one in FOFileHandler as well.)

InputHandler has a abstract getParser() method which
is used by Driver et. al.  This method *does* need to
be overridden in each of the base classes, and of
course it is.  

It just so happens, but is not necessarily required,
that the current implementation of XSLTInputHandler
uses the createParser() of FOFileHandler for its
implementation of getParser().  This is just an
implementation detail. 

XSLTInputHandler's getXMLFilter() (called by its
getParser()):

// Create an XMLReader.
XMLReader parser = FOFileHandler.createParser();


I preferred the direct reference to the FOFileHandler
method (as opposed to simple inheritance) for reasons
of documentation:  this way, we're clearly stating
that XSLTInputHandler is using FOFileHandler's parser
as part of its XMLFilter.

(Also, at the time I was doing this, I was planning on
having a DOMInputHandler--but was running into
difficulty doing so--that I believe would have caused
a createParser() to not have been relevant in the base
class.)

Thanks,
Glen

--- Peter West wrote:
> 
> Glen at al.
> 
> One of the things I noticed when I was looking for
> ways to bring the 
> apps classes of alt-design and HEAD closer together
> was that the 
> createParser method seemed to belong in
> InputHandler,
> because it is 
> required by both subclasses.  Any reason why it
> isn't
> there?
> 
> Peter
> 

InputHandler - re baseURL commits

[Peter B. West]

Glen at al.

One of the things I noticed when I was looking for ways to bring the 
apps classes of alt-design and HEAD closer together was that the 
createParser method seemed to belong in InputHandler, because it is 
required by both subclasses.  Any reason why it isn't there?

Peter

--
Peter B. West 

Re: Bug 11902 - who commits the fix?

[Arnd Beißner]

J.Pietschmann wrote:
> The area where the fix applies has changed considerably.
> I will the problam take into account in preparation of
> a 0.20.5 release.

Thanks,

if you want me to test it then, just give me notice.

Arnd Beissner
--
Cappelino Informationstechnologie GmbH
Arnd Beißner
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Fax: +49-7031-463460

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

Re: Bug 11902 - who commits the fix?

[J.Pietschmann]

Arnd Beißner wrote:
> I'd like to ask one of the committers to have a look at the fix and make
> sure it makes it into 0.20.5.

The area where the fix applies has changed considerably.
I will the problam take into account in preparation of
a 0.20.5 release.

J.Pietschmann



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

Bug 11902 - who commits the fix?

[Arnd Beißner]

Hi there,

I just found and fixed a bug (both in BugZilla with id 11902).

I'd like to ask one of the committers to have a look at the fix and make
sure it makes it into 0.20.5.

The impact can be quite severe: If you use the 
fopDriver.getResults().getPageCount()
method to count the number of pages (+1/2 = no. of sheets) in order to 
sort the
created documents by number of sheets you can run into big trouble during 
automated
envelope processing in the print shop. They don't like processing some 
ten-thousand
documents by hand...)

The fix has run with about 40.000 documents with between 1 and 40 pages 
here.

Thanks,

Arnd Beissner
--
Cappelino Informationstechnologie GmbH
Arnd Beißner
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Fax: +49-7031-463460
Mobile: +49-173-3016917


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