-Original Message-
From: Victor Mote [mailto:[EMAIL PROTECTED]
Jeremias Maerki wrote:
Hi guys,
(Just catching up on the postings of the last few days, this one caught my
eye...)
although I'm still a bit concerned that you based your PDF
part on the maintenance branch code
Andreas L. Delmelle wrote:
Victor, IIC, Jeremias' concern is about the PDF lib in HEAD
containing substantial improvements over the code in the
maintenance branch. One aspect that springs to mind is WRT
encryption support --as I recall, maintenance still had some
problems with this, for
Jeremias Maerki wrote:
from the website I don't quite get the scope of the project.
That might have to be made clearer. Anyway, I didn't want to
Yes, just as soon as it is totally clear to me :-) Right now, it boils down
to here are some things that I think could/should be shared, can
Ah, now I'm starting to see where this is going. I think this something
extremely difficult to do. To a certain degree it sounds like my
ideas/plans for the XML Graphics project, namely to separate certain
peripheral components (fonts, PDF lib, Graphics2D implementations etc.)
from FOP so efforts
Jeremias Maerki wrote:
Ah, now I'm starting to see where this is going. I think this
something extremely difficult to do. To a certain degree it
Agreed.
sounds like my ideas/plans for the XML Graphics project,
namely to separate certain peripheral components (fonts, PDF
lib, Graphics2D
Finn Bock wrote:
Do you mean that the 3 different processors should ideally
report the same validation errors in the same manner? That
can only happen after someone standardize a SAFO API (Simple
API for FO parsing). Until then all implementation will throw
different exceptions, which is
I am impressed by your seemingly boundless dedication
to XSL and its related fields.
Glen
--- Victor Mote [EMAIL PROTECTED] wrote:
I actually toyed with this idea about two weeks ago.
IIRC, the SAFO name is
already taken, but at the time I registered the
axsl.org domain, and I
finally went
Victor Mote wrote:
Finn Bock wrote:
Do you mean that the 3 different processors should ideally
report the same validation errors in the same manner? That
can only happen after someone standardize a SAFO API (Simple
API for FO parsing). Until then all implementation will throw
different
Victor,
from the website I don't quite get the scope of the project. That might
have to be made clearer. Anyway, I didn't want to talk about it just yet,
because it's not ready, but recently I started writing a JAXP-like API
for XSL-FO processors (I called in JAFOP for now). It basically
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
Would anyone expect that Defoe would
subclass SAXException for document validation errors? If not (it
doesn't), why not?
Yes, if you use a SAX parser, why not? My point is that at the top-level, no
SAXExceptions
[Peter]
On the topic of exceptions, and now that it's all over...
I was puzzled by this discussion. Would anyone expect that Defoe would
subclass SAXException for document validation errors?
That is your choice. Surely exceptions that occured during SAX event
handling (eg startElement) should
11 matches
Mail list logo