Hi,
Sorry to drop in... Just ignore me if you don't see any relevance.
In any case, don't bother answering me.
Considering that tables are currently the only mean to control
pagination, all my documents have a tendency to include lots of tables
(and they all start with a TOC). I believe I'm not
Jeremias,
Done. The hyphenation works now. What's the story with the
documentation targets now that we are using forrest? Can they be removed?
Peter
Jeremias Maerki wrote:
Hmm, I've given up running Ant under Eclipse. Gave me too much of a
headache and it works well for me outside of
Jeremias,
Please forward off the following:
Thanks,
Glen
Full Name: Glen Mazza
Preferred Userid: gmazza
Forwarding email address: [EMAIL PROTECTED]
Karma: just xml-fop
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Can do.
Here's the new account request form that we need to
fill:
New
I would agree to Ricardo. We're using tables for inventory lists
containing about 500 pages. The memory situation in that reports is
really critical and we cannot force the users to set filters.
On the other hand: to us it doesn't matter if this enhancement comes
with 0.20.5 or with a later
Hi Victor,
If you're going to work on the RTFHandler I'd be happy to commit the
relevant jfor sources (the RTF library I assume) to the FOP codebase
with appropriate package name changes.
As Jeremias mentions, it might be better if I do it myself so that the
legal stuff is clear.
I should be
Glen,
the request is away. An important thing for you to do is to sign and
submit the Contributor's Agreement. You can find it here:
http://incubator.apache.org/drafts/newcommitters.html along with
important additional information.
As soon as your account is created you will need to set up the
Bertrand Delacretaz wrote:
If you're going to work on the RTFHandler I'd be happy to commit the
relevant jfor sources (the RTF library I assume) to the FOP codebase
with appropriate package name changes.
Yes, I think the RTF libs are the only parts that are needed. I don't want
to mislead
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Glen Mazza wrote:
Well, the public API has to have
some way to control
the whole show.
You don't mean that literally--e.g.., a servlet
programmer does not need useThisRenderer() and
attachAreaTree() functions in a public API. (i.e.,
the public (embedded) API would be a strict subset
Victor Mote wrote:
In my vision of the API, the
servlet programmer would not need useThisRenderer(), but would need
something like setOutputType(OUTPUT_PDF), which would ultimately cause the
correct renderer to be selected.
This has already been discussed up and down. There is still the
problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20923.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
victor quote
[Responding to Jeremias here] Or, better yet IMO, into
a RenderType
object
that is a child or grandchild of the Document, so that
there can be
multiple
RenderTypes for the same Document.
/victor quote
I can understand enhancements for logging and
threading, but multiple
Errr...this came across as harsher-sounding than I
would have liked.
If the API has some convenient ways for the user to
specify multiple output types for a single xsl-fo
stream, that should be fine.
Glen
--- Glen Mazza [EMAIL PROTECTED] wrote:
victor quote
[Responding to Jeremias here] Or,
14 matches
Mail list logo
