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,
> -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 co
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, Graphi
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 c
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 anyb
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
implement
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 excepti
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
> final
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, whic
> -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 s
Finn Bock wrote:
[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 start
11 matches
Mail list logo