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
--- Tibor Vyletel <[EMAIL PROTECTED]> wrote:
> Hello fopsters,
>
> so I have finished (and published in bugzilla) the
> patch which have aroused
> quite a discussion around here.
>
> Just a short description:
> 1) org.apache.fop.area.AreaFactory
> - now contains specific create method for each
Hello fopsters,
so I have finished (and published in bugzilla) the patch which have aroused
quite a discussion around here.
Just a short description:
1) org.apache.fop.area.AreaFactory
- now contains specific create method for each (used) subclass of Area. The
generic Area create(FObj, LayoutMana
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> I only see a need for plugable LMs, but the
> AreaFactory patch is so
> small that I see no problem with throwing a bone to
> Tibor.
>
> regards,
> finn
>
OK, that opinion was what I was trying to get at.
Someone
g
your opinion here.
I only see a need for plugable LMs, but the AreaFactory patch is so
small that I see no problem with throwing a bone to Tibor.
regards,
finn
Andreas L. Delmelle schrieb:
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
I disagree with you that FOP should have ceased all
development during the four or five months you were
off the list. Open-source doesn't work that way.
Hmmm... One question:
Are you so
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> I disagree with you that FOP should have ceased all
> development during the four or five months you were
> off the list. Open-source doesn't work that way.
Hmmm... One question:
Are you so bent on misinterpreting one'
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> To be completely honest, I was a bit disappointed
> when after a couple of
> months absence, finally able to check out the
> sources again, I had to find
> that the whole Visitor design just got kicked out
Andreas, we thoroughly discussed the
Andreas L. Delmelle wrote:
> Not only that. The use-case he described doesn't seem at all
> far-fetched.
> Imagine FOP/FOray/Defoe having an AWT renderer that displays
> an editable XSL-FO in one window, the rendered result in the
> other, and allows for updates/modifications made in the first
> -Original Message-
> From: Victor Mote [mailto:[EMAIL PROTECTED]
>
Hi Victor,
> I know better than to take this bait, but ...
>
No matter... +1 for starters
> It has already been pointed out that, if the Visitor stuff was so
> terribly complex, there were other solutions that could b
Glen Mazza wrote:
> I've bought it due to my work with the apps package and
> removing AddLMVisitor, and how reducing the complexity
> allowed many other changes in other areas that weren't
> previously apparent to occur. I also think that many of your
> later enhancements in properties would
> -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 <[EMAIL PROTECTED]> wrote:
> [Chris]
>
> >>I'm definitely in agreement with you on this one
> Glen. Lets keep
> >>Layout simple whilst its still unfinished.
> >>Pluggable LMs can be added once we have an
> >>initial release.
>
> [Andreas]
>
> > Well... (sigh)... well ('nutha sigh)
Finn Bock wrote:
> I got some minor suggestions to the patch:
>
> - It should be strict typed: createBlock(..), createInline(..)
> - It should be complete so that all area creation was done through the
>factory, not just the 3 areas that Tibor needs.
Yes.
Victor Mote
Andreas L. Delmelle wrote:
Hi fellas,
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
*solid* argument pleading against the proposed change. Of course, something
like LM Makers can be added later on --the proposed AreaFactory shouldn't
h
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
[Chris]
I'm definitely in agreement with you on this one Glen. Lets keep
Layout simple whilst its still unfinished.
Pluggable LMs can be added once we have an
initial release.
[Andreas]
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
*sol
[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 be
Andreas L. Delmelle wrote:
All right, all right, maybe I'll just 'agree to disagree' in this case ;-)
--mind you, *not* WRT to Exceptions, though... I declined to further the
debate, but I'd much rather see GM read Sun's APIDoc for
java.lang.Throwable --makes sense, no? Enough, maybe, to convince o
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
> Glen Mazza wrote:
>
> > Personally speaking, I am much more amenable to adding
> > some complexity (LM Makers, for example, or opening up
> > our validation) if it helps out Finn's work, because
> > of the sheer weigh
Glen Mazza wrote:
Personally speaking, I am much more amenable to adding
some complexity (LM Makers, for example, or opening up
our validation) if it helps out Finn's work, because
of the sheer weight of contributions he adds to Fop.
(We slow him down, we slow down Fop.) Making these
changes for
Hello,
- Original Message -
From: "Andreas L. Delmelle" <[EMAIL PROTECTED]>
>
> Hi,
>
> > I have attached first phase (a working example) of the refactoring I was
> > talking about in my previous mails. Please let me know, if this change
is
> > acceptable for you. If it is, I will finish
> -Original Message-
> From: Tibor Vyletel [mailto:[EMAIL PROTECTED]
>
Hi,
> I have attached first phase (a working example) of the refactoring I was
> talking about in my previous mails. Please let me know, if this change is
> acceptable for you. If it is, I will finish it afterwards.
>
on the interface for pluggable LMs, I can start to implement
this refactoring right away ...
Best regards,
Tibor Vyletel(not Tybor ;-)
ICQ# 79458455
- Original Message -
From: "Glen Mazza" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 01, 2
I'd rather we have pluggable LayoutManagers -- 1.0's
emphasis and I think our previous agreement with
Finn/Simon -- than have pluggable Area objects (where
much of layout used to be in 0.20.5.) I'm not sure if
Fop can realistically handle both at this time.
As for complexity, in our LM's, with Ty
Hello Fopsters,
I have attached first phase (a working example) of the refactoring I was
talking about in my previous mails. Please let me know, if this change is
acceptable for you. If it is, I will finish it afterwards.
Change description:
1) new interface: org.apache.fop.area.AreaFactory & def
34 matches
Mail list logo
