> -Original Message-
> From: Victor Mote [mailto:[EMAIL PROTECTED]
> Sent: woensdag 26 januari 2005 21:49
>
> Just to be clear (not argumentative), I was saying something quite
> different. For the example that Andreas has given, my
> understanding is that there would only be one child
> vi
try sending a message to '[EMAIL PROTECTED]'
> -Original Message-
> From: Feifei Lu [mailto:[EMAIL PROTECTED]
> Sent: woensdag 26 januari 2005 22:16
> To: fop-dev@xml.apache.org
> Subject: RE: block-containers with BPD set
>
>
> please remove my email address in this list. Thanks.
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> ...Anyway, maybe I should ask the question in a different way:
>
> Given a block-container where the BPD is specified, are its children
> subject to column/page breaking if the whole block-container doesn't fit
> int
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> --- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
> wrote:
>
Hi Glen,
> > the XSL 1.1 WD, but since that's all it is ATM, a
> > 'Working Draft', changing
> &
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
Hi Glen,
Very much in favor of changing the extension elements' names to conform with
the XSL 1.1 WD, but since that's all it is ATM, a 'Working Draft', changing
their namespace might be a bit premature (?[*]), unless we
> -Original Message-
> From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
>
> I have the great pleasure to announce that Jeremias Maerki has been
> elected as an ASF member at the last member's meeting during ApacheCon.
>
(Better late than never :-))
Congratulations! Well-deserved!
G
Happy Thanksgiving! (--that is the 25th, right? :-P)
Greetz,
Andreas
> -Original Message-
> From: The Web Maestro [mailto:[EMAIL PROTECTED]
>
> Also, Andreas is correct that the site is built from the source (and I
> didn't forget that! ;-)).
Yeah, make them sweat at least as hard as you --that way, your effort will
be even more appreciated :-)
Greetz,
An
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> --- The Web Maestro <[EMAIL PROTECTED]> wrote:
>
> > On a similar note, I am 'contemplating' committing
> > the xml-fop/build/ folder ('built' by apache-forrest-0.6).
> > My reasoning for this is two-fold:
> > 1. it conta
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> 1.0's bookmarks are different from 0.20.5's, the former has
> fox:bookmarks as the "parent" element.
> It's been that way in 1.0 for a long time,
> before I came on board I believe.
>
Yes, and it even has been discussed
> -Original Message-
> From: Web Maestro Clay [mailto:[EMAIL PROTECTED]
>
Hi Maestro,
> I updated the Apache FOP web site. It now uses Apache Forrest 0.6, a
> new skin/theme and (drum roll please...) new FOP logo.
(fireworks) Yeah! (applause) Oooh! (more applause) Aaah!
Compliments o
> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
> > [Me:]
> > which is then supposed to be rendered as two very
> > large letters 'A' and 'B' with, for example, a story
> > in very small letters in between.
>
> The layout you describe can be achieved using an inline-c
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
Just noticed a slight error...
> Maybe something like this makes it clearer:
>
> A
>
>
The smaller font-size should be added as a property to the inner block
instead of to the inline.
> -Original Message-
> From: Luca Furini [mailto:[EMAIL PROTECTED]
>
Hi,
> A block inside an inline inside a block
> creates:
> a) 3 different paragraphs too:
> b) a single paragraph with all the text:
> I'd say a), but I'm not sure.
My very first thought was a) too, but then again, I
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> --- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
> > I'm not too fond of this type of arguments:
> > everybody/nobody else is doing it, so why
> > shouldn't/should we.
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> That would definitely solve the second case, but still leaves the first.
>
Hmm.. On second thought, that would ultimately depend on:
- the parent of fo:retrieve-marker
- the child of fo:marke
> -Original Message-
> From: Luca Furini [mailto:[EMAIL PROTECTED]
>
> > Simon Pepping wrote:
Hi Luca / Simon,
> > Marker extends FObjMixed, which adds InlineStackingLM.
> I still have to really understand InlineStackingLM, I find it very
> enigmatic! It generates inline areas, but it ha
> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
Hi Simon,
> ...Sorry for the inconvenience in the mean time.
You must be joking! Inconvenience? Far from it. The remarks/additions so far
have been very helpful. Nobody --ahem, certainly not me-- expects you to
solve ev
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> Manpages are usually for C-language
Correct so far.
> Unix-specific applications, no?
Hmm... The manpages themselves obviously are Unix-specific, but I'm not so
sure whether the applications always are or necessarily h
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> When [argh!] the site goes live [argh!] it will be there. ([argh] still
> struggling with Compliance Page and a couple of other 'little'
> problems...). But I've still got a cheery attitude about it!
>
Well, FWIW, from
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> FWIW, here're a couple of Man Page HowTos:
Thank you, Maestro! (saved me the time to look them up, hehe ;-) )
It really sounds like a good 'marketing' idea to me (if this would
facilitate bundling with the different Uni
Team,
What do others think of this question?
If all our *nix users would benefit from it, I'm all for (--but I'm not all
too familiar with the syntax of manpages... yet ;-) Is the format generic
enough to be supported by all *nix platforms, or would we have to write
separate ones for Debian / Re
Simon,
> I applied a quick and dirty hack to prevent this Exception in the case of
> Andreas' test file. It will throw away the linebreak though.
There is actually no linebreak to throw away --it's a non-breaking space
(A0) not a linefeed (0A), so your 'quick and dirty hack' may just be what we
> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
> On Sun, Nov 14, 2004 at 10:11:01PM +0100, Andreas L. Delmelle wrote:
> >
> > While running some tests after updating to include
> > Luca's latest patch (bugzilla 31206),
&
Moving this issue to bugzilla.
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> (Reporting this here, since for some reason can't connect to
> nagoya.apache.org... is it just me or does anyone else have this problem
> too?)
>
Hi,
(Reporting this here, since for some reason can't connect to
nagoya.apache.org... is it just me or does anyone else have this problem
too?)
While running some tests after updating to include Luca's latest patch
(bugzilla 31206), I get a ClassCastException in LineLM.getNextBreakPoss()
line 4
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
Ignore this thread. Found the answer in the archives...
Sorry for the nuisance.
Greetz,
Andreas
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> Hope the use of the bookmarks extension wasn't meant to be
> changed in HEAD.
Oops. Just noticed that a Bookmarks class has been added to the extensions
package...
What's going t
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
Hi,
> Modified:src/java/org/apache/fop/fo/pagination Root.java
> Log:
> changed 'bookmarks' to 'outline' to avoid ValidateException for
> bookmarks extension
>
Hope the use of the bookmarks extension was
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
Hi Glen,
> Does anyone have a problem if I worked towards
> removing the initialize() method from our
> LayoutManager interface?
No objections here at first glance, however ... (see below)
> The relatively few cases in
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> On Nov 8, 2004, at 5:44 AM, Glen Mazza wrote:
> > I signed up for ApacheCon last night so I'll be there next week.
> >
> > Glen
>
> Wish I could be there to meet you, Glen.
>
Same here... Vegas, right?
Drag yourself
> -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
> -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'
> -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
> -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
> -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
> -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.
>
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> As the definition of its parent SAXException[1]
> states, "This class can contain basic error or warning
> information from either the XML parser *or the
> application*" So it can be used within FOP.
>
True, but I still
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
>
Hi Glen,
> I'm confused--why is OK to throw SAXExceptions but not
> its child SAXParseExceptions? With the latter, it
> just holds locator information necessary to pinpoint
> the problem for the user. Please elaborate
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
> [Finn:]
> > I couldn't get that working. As I see the it, the SAXException from the
> > xml parsing is not passed through to the ErrorListener.
> >
> > The source code from x
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
> >
> > Not sure if this is what you're looking for, but the
> > javax.xml.transform.Transformer class does offer a setErrorListener()
method
> > to use a custom Error Handler...
[Finn:]
> I couldn't get that working. As I s
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
Hi Finn,
Not sure if this is what you're looking for, but the
javax.xml.transform.Transformer class does offer a setErrorListener() method
to use a custom Error Handler... IIUC, all we have yet to do is provide an
implemen
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
Hi there,
> [Glen]
>
> > Why is it more efficient (I know it is, given your
> > metrics, but want to know why)--...
> In my proposal the specified and the cached properties are still stored
> in the property list but only
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
Hi Peter,
> Arguments enclosed in quotes, either double or single, are passed as a
> single argument to the shell script. I'm not sure about Win CMD
> systems, but I believe that they do the same thing.
>
Bam! This w
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
Hi Clay,
> Thanks for the heads up, Andreas. I'll keep that in mind. Does this
> mean one should do something like this for Unix:
>
That was exactly what I meant, indeed. Not sure whether it's about the shell
script inte
Hi,
In attempting to fix the break-before and break-after properties, I noticed
two methods that are commented out in PropertyManager, checkBreakBefore()
and checkBreakAfter() --used in maintenance branch to keep track of possibly
enforced page- or column-breaks.
I can only assume that the inte
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Hi Chris,
> Is anyone else on the team planning on making large commits over the next
> couple of days? I would be grateful if you could hold off for a
> couple of days
> whilst the problems with this large patch are r
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> Maybe sheds some light on the situation. As to what needs to be
> done to fix it... no particular idea for the moment.
>
>
Just ran a few tests of my own, with FOP's examples/fo/marke
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
Hi Chris,
> the markers are added to pageViewport in the BLM.addAreas method. Now my
> understanding is that addAreas are called once the BPs have been
> processed and the areas are about to be rendered. So how is t
> -Original Message-
> From: Tibor Vyletel [mailto:[EMAIL PROTECTED]
Hi,
> In previous versions (builds) of FOP areas have had set ID_AREA trait
> in order to allow identification of original FONodes (and XML elements)
> they had been created from.
> Why is this feature missing in recent
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Hi Arnd,
> As far as I understand the spec, table-column elements with a column-width
> property are mandatory for tables with fixed table layout.
>
*Vry* good point!
Yup, got me there... I was mixing the two
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
Hi Chris,
> This makes sense - what effect would you expect width on table
> cell to have? I maybe missing something, but the width is
> derived from table column and cant be overridden for a single cell.
>
Indeed,
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> BTW, Andreas, sorry for not responding to your emails
> on this thread, I'm juggling a bit much right now,
Well, don't worry about that... Just posting this all to see if it's just in
my head, or all crazy talk --and if
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
Posting this as a follow-up to my earlier ponderings. If we don't get it
implemented, or postpone this one indefinitely, at least we'll have it
nicely summed up for possible future use... (Who
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
Hi Chris,
> Huh? This is not true. Follow the link you provided to the spec.
> table-rows can have background and border properties
> (when border-collapse is on)
>
Hmm.. Yes, but... these properties are not specifi
Hi fellas,
As I awoke recently, trying to pick up where I left off end of January this
year (see bug 25933), and started digging deeper into the current status of
table-processing in HEAD, noticed the following in the FO Tree:
A TableRow FONode is created for every fo:table-row, and it is added
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> Team,
>
> I'd like us to go ahead and make Simon Pepping our
> newest FOP team member. He has provided steady ML
> help and numerous patch contributions for the past few
> months, and with the many layout patches that
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> PleaseI'm not implying intent here, or email owner
> capabilities.
Of course not. Sorry, was just a bit annoyed with the logic in the OP.
Cheers,
Andreas
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> Thanks, Manuel. We have about 430 people on FOP-DEV,
> --- 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
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> Sounds good to me... Looks 'snappier'! (sorry! ;-) and the added
> capabilities[1] look promising. There're a couple of other Wiki's I'm
I also had a look, and apparently, the bottom-part (below 5. Contact...) of
the pa
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> Perhaps I might even pick up a Java book and figure out how to add
> command line parameters to FOP (I'm hoping I won't have to figure out
> the issue that Glen and Andreas raised[1] in February, though...:-p).
>
Why...
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> So let me start off the voting: +1.
>
No need to think this over: +1.
Cheers,
Andreas
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> This simplification, even if
> temporary, drops the average IQ needed to understand
> the Renderer classes perhaps 30 points, more into my
> range*, hopefully opening the door for more developers
> to start filling out th
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
>
>
> BTW I don't think it's good style do ignore a veto and
> commit a change even before the discussion is resolved.
>
One of my points also:
The 'more correct' design, I believe, ...
after which he can _buy_ _som
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> We must be doing something right, if we're being used as an example
> (even if it is referring to how nicely FOP reacts when it fails)!
>
> :-)
>
Hmm, something like 'adapting Jakarta-Ant shell scripts' at the very leas
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> But the nice thing about our system is that they don't
> have to follow AbstractRenderer. AR implements an
> interface called Renderer, which is the bare minimum
> of methods needed to implement a FOP-compatible
> rende
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
>
Taking your pros into account:
on 1.) +1
Now that you mention it, I have a vague suspicion that this is somehow
related to the bug WRT basic-links I pointed out earlier (for which I was
going to send some test file, bu
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> There's a lot of subjective judgement in making such calls, which is why
> it's useful to have a number of different opinions kicking ideas around.
>
Yeah.. it probably is too subjective to settle in a few sentences
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> The borderline cases may be very much in the minority (and must be,
> judging by the degree of usage that FOP gets now) but they must be taken
> into account in the design of the solution. If we go for the
> low-hang
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> Thanks Andreas. Yes, I disagree, but then, so does the spec. What
> information *should* do is not terribly relevant. We need to work out
> and express what information *must* do to get this thing working.
>
Voila
> is being interrogated/perceived/discussed...
Sorry, it's late here...
> You are IMO very correct by stating that 'if the Layout info can
> be reused,
> so can the AT and the renderer', however, if I interpret correctly, the
> latter two are designed to dispose of their created objects ASAP.
> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
>
> In my view FOP consists of a number of subsystems that are ordered
> from upstream to downstream. The FO tree is the most upstream system,
> the area tree (or objects that are constructed by a renderer) is the
> most d
> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
>
> If in the re-use the layout would not change, the area tree could be
> reused. OTOH, if the layout would change, e.g. because another
> renderer would use a font with a different font metric, the layout
> information
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> So we not can assume the xml->xsl->fo
> processing was had via Xalan--and even if it were so, it also could have
> been done via its translets (compiled XSLT) feature.
>
Aw, great! You just *had* to come and throw that on
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
> Or, to describe in XSLT terms, I think closest would be: all
> elements in the
> vendor's redirection extension's namespace having their target
> URI attribute end in '.fo'
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> Can you give an example of how would his look? Would it be an ant task?
> Would it be some type of java class? Thanks!
>
Well, Maestro, started to think about subclassing, but I'm not sure in what
form *exactly* yet, nei
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> [Simon Pepping]
>
> > However, I am not happy with your
> > solution. During the layout process, you feed the page dimensions back
> > into the FO tree, in PageLayoutManager.createPageAreas.
>
> Yes, and in BlockLayoutMan
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
> Andreas L. Delmelle wrote:
>
>
>
> > The related class in Xalan: org.apache.xalan.lib.Redirect
> >
> > It contains a HashMap, m_outputStreams, which is,
> unfortunately,
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> I tried a little bit more, but was unsuccessful. XMLFilter +
> setParameter()
> unfortunately isn't currently available with JAXP, and I suspect the
> just-use-a-transformer alternative proposed by Michael Kay here:
> ht
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
> Far better would be if we could somehow get a handle to the streams the
> redirection extension writes to. Place a buffer in between, and we're set.
> Much faster, no need for a workaround of
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
>
> In my application we create multiple page-sequences using multiple
> "xsl:include" templates, which _look_ different, but are still one PDF
> file. If certain flags are set in my source XML, my app creates: 1) a
> bill;
> -Original Message-
> From: Kloeck, Erwin
> To: [EMAIL PROTECTED] mulberrytech. com (E-Mail)
>
> Hi,
>
> I have to create several pdf-files out of one xml document.
> Currently I write several fo-files using redirect:write to disk
> during xsl processing and then read them in again for
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
> > [Me:]
> > Errmmm... (Trick question?)
>
> Not so much a trick question as it is a question about a note on the FOP
> Fonts question.
Well, don't worry. Was just kidding there --I meant more: the question was
posed in a
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> [Peter B. West]
>
> > I have no problem with your continuing. If we need a formal vote,
> >
> > Jeremias to remain as one of our PMC representatives:
> >
> > +1
>
> +1 for Jeremias
>
+1 from me as well
Cheers,
An
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> I've been doing some updating documentation for my company's product, and
> noticed this tidbit on the FOP Fonts page[1] where it discusses PFMReader:
>
> Is this the requirement for the avalon-framework.jar just a requi
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> --- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
> wrote:
> >
> > AFAICT SAXTransformerFactory has its own
> > getTransformerHandler() method.
> > Maybe you can use th
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> Keep in mind, for FOP's xml+xsl->fo->pdf, we don't
> output an intermediate fo file. So there may be *no*
> redirected files to keep track of.
>
Yah... wonder where these redirected parts would end up in this case...
t
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> --- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
> wrote:
> > Started having strange ideas on the possibility of a
> > scenario like
> >
> > 1 XML + 1 XSLT => n
Hi all,
Started having strange ideas on the possibility of a scenario like
1 XML + 1 XSLT => n FOs => n PDFs
XSLT processors support extension functions for the output to multiple FOs,
but in what way could (or does) FOP support the multiple PDF rendering? How
would one go about such a task (i.
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
Hi Glen,
> Also, big issue--I'm trying to implement command-line
> XSLT handling. Most of the code came from
> Xalan--quite simple to add. The only problem is that
> I'm unsure how to configure the XMLFilter (line
> 17
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> When debugging the output using the AreaTree XML, the pages are in the
> proper sequence in there (only, outside of their page-sequences?*), so
Correction: they are all inside one and the sam
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> I had a similar thought process (0_20_2-maintain for pre-1.4 users--if
> it works, don't fix it?). As for 1.0 (forgive my playing the devil's
> advocate here), why stop at 1.4? Assuming Java 1.5 will be released by
> the
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> There's also jakarta commons configuration, which uses property
> files (IIRC, may well be wrong).
Not wrong necessarily, I think. Just maybe a bit outdated to some. The
Properties API is treated in many docs as a sort
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
> ... The settings themselves are stored in a
> system location where they are not meant to be found and edited by hand...
> (On Windows the more straightforward way to modify the prefs
> outside
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> If we go to 1.4, should we also use 1.4 logging (java.util.logging) and
> possibly also the preferences API (java.util.prefs) for
> configuration/user agent/user prefs?
>
I like this latter proposal (using preference
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> > -Original Message-
> > From: Glen Mazza [mailto:[EMAIL PROTECTED]
> >
>
> >
> > Keep in mind, Andreas, Apache Geronimo is already
> > running into h
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> Yes, indeed, of course. I don't know the difference
> between US and European laws here--but most companies
Actually there is probably not that much difference WRT the law 'in se' (for
those who remember the patentabili
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> Andreas L. Delmelle wrote:
> >
> > Peter / Nikolai,
> >
> > I think I should be the one to apologize here, as Nikolai seems
> > to have been offended by one of *my* unrefl
> -Original Message-
> From: John Austin [mailto:[EMAIL PROTECTED]
>
> I am surprised that MS or their minions at SCO haven't twigged to the
> following scheme"
>
> They could 'set-up' Open Source by masquerading as some student
> in netland and submit some provably proprietary code as o
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
> Nikolai,
>
> Please re-consider your decision. I, for one, am extremely pleased that
> developers on other XSL-FO projects, especially ones so successful as
> RenderX, are interested enough in FOP to monitor this list,
1 - 100 of 210 matches
Mail list logo
