On Sat, 2002-07-20 at 16:55, Miguel A Paraz wrote:
Hi,
I've been reading the code and I hope to get some tips.
On Wed, Jul 17, 2002 at 02:58:13PM +0200, Keiron Liddle wrote:
If I understand it properly you would need to add an Encrypt pdf object
that is referenced in the documents
- Original Message -
From: Rhett Aultman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 19, 2002 5:26 PM
Subject: RE: Performance Analysis
If you're really concerned about finding the source of the memory drain,
I really have to :-)
Yyou may want to run the JVM with a
If you're really concerned about finding the source of the memory drain,
I really have to :-)
you may want to run the JVM with a JVMPI memory profiling agent running.
jProf is a pretty good one. If you do a Google search for jProf,
you'll find it, and if you need help using it, I'm
Hi,
If I remember correctly (and read the right archive messages) the
original trigger was the jdk1.3 specific code for AWT fonts. Suggesting
the need to handle jdk version specific issues.
There are a number of potential issues.
For jdk1.4 I recently discovered they have image IO classes that
On Mon, Jul 22, 2002 at 11:51:05AM +0200, Keiron Liddle wrote:
As I misunderstood the original question it appears there is a slight
difference to what needs to be done.
What exactly does it need to do to sign a pdf file. Does it need to read
all data in all streams and then create a single
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=9144.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Oleg Tkachenko wrote:
Hello there!
In spite of text-transform non-recommended status and i18n issues I
believe fop can rely on java i18n support and implement this property
using toUpperCase()/toLowerCase() stuff.
+case TextTransform.CAPITALIZE:
+boolean
FOP developers:
As I am trying to get my arms around FOP, I am finding some things that I
probably ought to propose as changes to the documentation, but I am confused
about the mechanism for doing so.
1. It appears that the main documentation deliverable is the HTML pages that
are on the web
I'm new to fop, so please give me a little leeway :).
I've been looking at FOPs PDF library to help me with some direct PDF
generation tasks that are not presently suited to XSL:FO (I need
absolute positioning, layering and the ability to use XObject Forms).
FOP has about the nicest and low
I'm new to fop, so please give me a little leeway :).
I've been looking at FOPs PDF library to help me with some direct PDF
generation tasks that are not presently suited to XSL:FO (I need
absolute positioning, layering and the ability to use XObject Forms).
FOP has about the nicest and low
J.Pietschmann wrote:
The problem is that
fo:wrapper text-transform=capitalizeefo:wrapper
x/fo:wrappertensible/fo:wrapper
will create three FOText objects, holding e, x and
tensible. With your algorithm it would probably capitalize
to EXTensible.
You right. I had feeling it's
jProf is actually its own complete memory profiling system. It's based on the JVMPI
API, much like my much simpler homebrew profiler was. jProf will give you a pretty
detailed analysis of how much of the heap got used up by which types of objects, and
IIRC it also gives information on method
My primary concern with utilizing different source build paths is that it will require
everyone to build from source. I think this could hamper FOP's acceptance, which is
the main reason I didn't support that originally. Additionally, when you think about
it, altering the source build
Peter S. Housel,
the problem is : when I use to write a part of Chinese in the block or
table-cell, the Chinese text could not broken in the end of line. so I use the hyhens
to fixed it, the problem solved, but there is not hyhens file of Chinese for FOP, I
wonder is there any good way
14 matches
Mail list logo
