Re: Need advice in implementing signed PDF files
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 trailer dictionary. That is, write out the signature with PDFDocument.outputTrailer? Or, add it to trailerObjects using addTrailerObject? Add a new object to the pdf file that is referenced in the trailer dictionary using the pdf object reference. The you would need to encrypt all pdf streams using the appropriate algorithm. If JCE can handle this then it would be used to encrypt the stream. Thus I will subclass PDFFilter. From my reading of the code, the scope of the PDFFilter is only inside the PDFStream, and the document is composed of multiple PDFStreams. If I am correct, then the signing process has to be closer to the output level. For instance, using a FilterOutputStream to peek at the data being written out at the PDFRenderer level. Or, I could use a single java.security.Signature instance for all the PDFFilter subclass instances. If I am wrong, and I can use a PDFFilter subclass, how can I extract my java.security.Signature instance from the PDFFilter, to write it out (java.security.Signature.sign())? The filters in PDFStream are not referenced by name. 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 signature number. If so then it sounds like there needs to be some adjustment to how the filters are created and used in order to accomodate what you want. - organise the configuration for password etc. If a PDFFilter subclass is to be used, how can this have access to the configuration file? I don't know. What do you think it should do? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Analysis
- 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 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 here. I've written a JVM profiling agent before, so I know my way around that block. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. -Original Message- From: Holger Prause [mailto:[EMAIL PROTECTED]] Sent: Friday, July 19, 2002 11:17 AM To: [EMAIL PROTECTED] Subject: Performance Analysis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Analysis
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 here. I've written a JVM profiling agent before, so I know my way around that block. That very nice, i could need it (Is JProf an api and u coded an profiler using that api?). I have to test it on a custom tag library - performing the xslt transformation. Can u mail the program to me ? My mail is [EMAIL PROTECTED] In the mean time i found out what takes so much memory, its a very brave way of programming (using strings as buffer instead of byte streams, etc...).As workaround i increased the heap of the vm to 256m. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. Thats what all ppl told me as answer for my question what takes most memory.Ill suggest our customer to reduce the use of images. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. Ok good to know, but thats not very new for me.Hmm is that Thread running in fop or not ? (I suppos its not because of the funny answers i got) If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. I think that will not be necessary. Thank you very much, Holger -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Specialized Classloader
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 use JAI in the background. There is also the PDFGraphicsConfiguration class (this has the added problem that both jdk1.4 and pre-jdk1.4 versions cannot be compiled by the same compiler). So there are issues that need to be dealt with, the question then is what is the best way: a runtime classloader solution or a compile time solution. Run time (if it works well) is better for distribution and users. From what I have seen most of the Classloader problems occur due to the classloader not properly implementing something and when classes it loads load other libraries it can get into trouble. It feels to me like a separate project: for example a wrapper that loads the jar, the default jar contains the all the classes for normal use and other jars contain a subset of classes for particular jdk versions, the configuration determines what jar contains classes for particular jdks. But it still needs a place to start. Sorry I can't give a definite yes or no answer. Will it be useful, quite possibly. Will it cause trouble, I don't think so. Is it the best solution, no idea. Hope that helps. Keiron. On Fri, 2002-07-19 at 21:09, Rhett Aultman wrote: I'm content being on my own. I just don't want to end up building something that nobody wants or needs, which was really why I'd put up a proposal and asked for comments. Honestly, the thumbs-up I was looking for was from someone like Keiron so that I'd know it was believed that I was correctly addressing an issue that needs addressing. The majority of the work on the classloader will be pretty easy stuff, and I can even take on the splitting system-dependant classes into their version-specific components and so forth. And write documentation on how to do that. I was just hoping that I could get a word from a higher-up or two that there was an interest in this being pursued. That you've suggested I go for it is definitely encouraging. Anyone else want to throw in? Any +1s, gang? -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Rhett, Judging by the deafening silence, I would say you are on your own on this one. You may take heart from the fact that no-one has said Don't! So go for it. If you don't do it, nobody will. However, It would probably be a good idea to send a message to the other Apache Java projects, briefly outlining what you are thinking about. It may be that similar efforts are underway elsewhere. One of the more experienced devops like Keiron may be able to make more informed comments on this. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Need advice in implementing signed PDF files
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 signature number. If so then it sounds like there needs to be some adjustment to how the filters are created and used in order to accomodate what you want. I read the spec. It turns out that signatures are part of Acrobat Forms (chapter 6.14). It's not clear to me, what in particular is being signed - the rest of the form, perhaps? I am going to find out. If a PDFFilter subclass is to be used, how can this have access to the configuration file? I don't know. What do you think it should do? Sorry, let me rephrase that. My question is, what is the proper way for a PDFFilter subclass to read values from the configuration file? The signing system would need access to the name of the private key, for instance. -- http://mparaz.com/journal/ +63-916-423-7922 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9144] - awt renderer failed to display region-start and region-start and region-end
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9144 awt renderer failed to display region-start and region-start and region-end [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-07-22 17:53 --- fixed in cvs already. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] text-transform support
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 isFirst = true;
+for (int i=0; ilength; i++) {
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. The other approach, doing text transformation
as the text is added to a line, wont work either because of
the current small-caps implementation (see FOText.addText()),
and I'd rather keep small caps than text transformations.
The third nail are the actual i18n issues, because text
transformations are language dependent. Ok, only for a very
few real characters (IIRC see Unicode special casing
http://www.unicode.org/Public/3.2-Update/SpecialCasing-3.2.0.txt),
but I think the German szlig is still widely used in the
FOP audience.
Actually, IIRC text transformations were added to FO because CSS
had them, but I can't quite remember the original use cases for
CSS. I vaguely remember some issues with pseudo classes, which
are not problems in XSLFO.
As long as nobody comlains loudly, I think we'll leave this out.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
FOP doc
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 site and included in the distribution. Is that correct? Has any thought been given toward using FOP to generate PDF manuals, perhaps broken down between user and developer issues? 2. Are doc change proposals intended to work the same way that source changes do -- ie. submit a patch to a committer? Or, is the doc function centralized? If the former, then continue with the remaining questions. If the answer is the latter, then to whom should documentation change requests be made? 3. Running build.sh usage indicates that build.sh docs should build the html documentation. There is no target for docs, but there is one for htmldoc. This appears to be a bug, for which I will submit a patch after I am more confident that I understand what should be happening. 4. Running build.sh htmldoc fails: /u/vic/xml-fop/build.xml:658: Could not find file /u/vic/xml-fop/docs/xml-docs/fop.xml to copy. My CVS download of the fop-0_20_2-maintain branch does not have this file anywhere (updated 7-22-02, approx 8:00 GMT). This is what makes me think that the doc function is perhaps centralized (??). I'm sorry if these are newbie questions. The good news is that after you all give me the answers, I will attempt to document them for the next guy. Thanks. Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 attachment: winmail.dat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDF output driver
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 level PDF library I've come across, a true undiscovered gem. Enough of the glowing praise :). I've noticed from the CVS logs that the separation of the PDF code is a recent thing; are there current plans to extend it's usefulness beyond that of mealy being an output renderer for FOP? Would you consider adding contributed classes (like the aforementioned XObjectForm) that there is no real XSL:FO imperative for? Separating the generation of the PDF support into an additional build target for people like me who what to use the PDF functionality without the additional XSL:FO components? Regards, -k. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDF output driver
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 level PDF library I've come across, a true undiscovered gem. Enough of the glowing praise :). I've noticed from the CVS logs that the separation of the PDF code is a recent thing; are there current plans to extend it's usefulness beyond that of mealy being an output renderer for FOP? Would you consider adding contributed classes (like the aforementioned XObjectForm) that there is no real XSL:FO imperative for? Separating the generation of the PDF support into an additional build target for people like me who what to use the PDF functionality without the additional XSL:FO components? Regards, -k. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] text-transform support
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 wrong place, but after testing on xep test suite decided all right. The other approach, doing text transformation as the text is added to a line, wont work either because of the current small-caps implementation (see FOText.addText()), and I'd rather keep small caps than text transformations. That doesn't help either, they are 3 different chunks till LineArea's addText() method and I have not enough courage to sink into this 400 lines method, so... forget it. :) -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Analysis
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 call sequences that allocated objects and so forth. It's quite expansive, and even comes with an attractive GUI frontend if you don't like looking at reports on the command line. Just do a Google search for jProf -Original Message- From: Holger Prause [mailto:[EMAIL PROTECTED]] Sent: Mon 7/22/2002 10:40 AM To: [EMAIL PROTECTED] Cc: Subject: RE: Performance Analysis 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 here. I've written a JVM profiling agent before, so I know my way around that block. That very nice, i could need it (Is JProf an api and u coded an profiler using that api?). I have to test it on a custom tag library - performing the xslt transformation. Can u mail the program to me ? My mail is [EMAIL PROTECTED] In the mean time i found out what takes so much memory, its a very brave way of programming (using strings as buffer instead of byte streams, etc...).As workaround i increased the heap of the vm to 256m. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. Thats what all ppl told me as answer for my question what takes most memory.Ill suggest our customer to reduce the use of images. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. Ok good to know, but thats not very new for me.Hmm is that Thread running in fop or not ? (I suppos its not because of the funny answers i got) If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. I think that will not be necessary. Thank you very much, Holger -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] winmail.dat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Specialized Classloader
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 removes only one - of your three- the concern about a specialized classloader in a webapp/EJB environment. The other two issues remain- testing on multiple systems and increased complexity. In all honesty, there isn't a good answer to system dependancies in a system independant language. Any path we take is going to have some ick to it. I believe we may be safe in having a specialized classloader even in webapps as long as it is designed in a careful fashion. I've used specialized classloaders several times in my webapps without too many problems; however, what if maybe we considered more flexibility, allowing the dynamic classloader to be switched off in cases where it's going to be a nuisance? To be fair, I'm pensive about a lot of this, too, because it's very, very new ground in general. I just want to help give FOP everything it so richly deserves. If that's the classloader, I'm here to do it. If it's helping to refine source builds, count me in. There haven't been any black balls cast on this, though, so I'm thinking I may proceed, pending any further commentary in the next day or two. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Mon 7/22/2002 2:24 AM To: [EMAIL PROTECTED] Cc: Subject: Re: FOP Specialized Classloader Rhett, I've read through your proposal and I end up being -0. Here are some pros and cons that came to my mind (disclaimer: no scientific research behind those points): + Works around certain problems in an elegant fashion. We can provide the best code for each JDK-version. + Interested parties may be able to restore JDK 1.1 functionality more easily. It's easier to maintain JDK 1.2 support. - Working with classloaders may increase the difficulty of embedding FOP especially in a web or EJB container where a bunch of special classloaders is already active. Increased difficulty means more support effort. - Increased effort necessary to maintain the code over multiple platforms. All target platforms have to be tested prior to a release. - Increased time for familiarizing oneself with the code. The main point that leads to my -0 is my first negative point. The classloaders won't hurt in standalone usage but could develop into a PITA when used in a more complex environment. -0 means I won't stand in the way but I would like the stuff be well tested. Not being a classloader specialist I only state my concerns about something that has caused problems in the past. I appreciate your effort in following down this path and I hope I'm proven wrong because if this works great this is a very powerful addition to FOP (and possibly other projects like Batik). Sorry for not being more positive. On the other side I keep thinking if improving the build process to produce JDK-specific jars wouldn't be a better (and less painful) approach of handling this. Just a thought... I'm content being on my own. I just don't want to end up building something that nobody wants or needs, which was really why I'd put up a proposal and asked for comments. Honestly, the thumbs-up I was looking for was from someone like Keiron so that I'd know it was believed that I was correctly addressing an issue that needs addressing. The majority of the work on the classloader will be pretty easy stuff, and I can even take on the splitting system-dependant classes into their version-specific components and so forth. And write documentation on how to do that. I was just hoping that I could get a word from a higher-up or two that there was an interest in this being pursued. That you've suggested I go for it is definitely encouraging. Anyone else want to throw in? Any +1s, gang? Cheers, Jeremias Märki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] winmail.dat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Re: the license of Chinese hyphenation pattern file
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 to make the text broken if I would not use hyhens.?? === 2002-07-19 £º=== On Thu, 2002-07-18 at 22:58, stoneson wrote: hello: who can help me to make the license of Chinese hyphenation pattern file, such as the following hyphenation patterns are part of the Fop distribution da Danish ... Why? I'm sure you know that Chinese doesn't use hyphens, and that Chinese text can be broken between any two characters. Some typesetters don't even bother to suppress line breaks in front of punctuation marks. A hyphenation file would do no good at all. What's needed is for FOP to implement http://www.unicode.org/unicode/reports/tr14/ instead. -Peter- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] = = = = = = = = = = = = = = = = = = = = stoneson [EMAIL PROTECTED] 2002-07-23 face-6.gif Description: GIF image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
