RE: Team page
Yeah...I know the rules. When I see stuff to patch, I patch it, if someone doesn't beat me to it. I don't mind not having CVS checkin, honestly...I'm just good at groaning. ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 5:00 AM To: [EMAIL PROTECTED] Subject: Re: Team page On 27.05.2003 22:57:48 Rhett Aultman wrote: Also, I'd prefer my email address be listed as [EMAIL PROTECTED], as I'll be transferring my devlist membership to that address soon. Done. I'd make the changes myself, but I don't have that kind of CVS access. ;) Start sending cool patches until we get tired always applying patches from you and we'll make you a committer in no time. Applies to every contributor, by the way! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
Peter B. West wrote: While I don't denigrate any of these ongoing efforts, I am increasingly of the view that everything occurring between the reading of the fo xml and the layout of the area tree is interconnected in very nasty and intricate ways. The description of this process in the Rec (I resisted the obvious temptation here) has done many developers, including the FOP developers, a great disservice. It's this intertwining that makes me skeptical about pluggable layout. It may be feasible, but I don't see that it is feasible until we have a very good understanding of the way layout will be achieved, and a full picture of the flow of control in the first full implementation. My naive understanding of the Area Tree is that it could / should be constructed as a view of the FO tree. It should not, for example, IMO, contain any Strings at all, but objects in it should contain offset and size values for the parent FOText object in the FO tree. Similarly, perhaps it should not contain the trait values at all, but should compute them from the parent on-the-fly. The FO tree should normalize the values as much as possible (which in many cases is completely), then the Area tree can complete whatever computation is necessary before returning the value to use. I realize that this violates your compute-it-once principle, but I was frankly confused by that principle. It seemed to me that the intertwining issues that you mention utterly prevent compute-it-once. Second, and more importantly, regardless of what design is used in the Area Tree, there is nothing that prevents us from factoring code that is common to more than one LayoutStrategy into a module that is usable by any LayoutStrategy. If there are issues that force things to be intertwined, then those could be common code. Factoring out the high-level control is still a valuable and achievable step forward, but I'm not sure about control of when layout is started, when FO trees are destroyed. I assume that refers to the patient vs. eager layout discussion. At that level, certainly, control values can be factored out. Actually the two examples listed are, in my mind, examples of the high-level control issues that we want factored out. Patient vs. eager is only part of the story. Also included here are such issues as reusing session and document objects in embedded environments. I don't want to discourage your efforts, but I think you will need to keep these things in mind. I will. Thanks. If I come back humbled from the effort, perhaps at least some useful documentation will emerge. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
Chris Bowditch wrote: What you say is true, but I think you missed one thing from your analysis: what if solution A took x seconds and B took x+2 seconds, but B had a greater level of compliance and produced better results than solution A? Then you would want to give the users the choice between better results or performance. Which solution you choose would then depend on the requirements of the situation. I dont think you could just discard solution B because it is slower. You would try to work with A, but if the document was too complex to get good results with A, then the user could switch to using B Well said, and I think it even goes deeper than this. It may actually be /useful/ to have non-compliant LayoutStrategies. If a minimally compliant LayoutStrategy required 120% memory, or 2x processing time over a leaner but noncompliant LayoutStrategy (like our maintenance branch code), there will be some, especially in embedded environments, that will prefer the noncompliant LayoutStrategy. It may be possible within a LayoutStrategy to allow the user to configure some of these tradeoffs as well. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
Response below (one of these glorious days, I can stop using Outlook...) -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 7:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: hack to avoid memory overflow with tables FOP is ultimately a mathematical entity, so we should be able to avoid the matter-of-opinion conclusions that would lead to multiple layout strategies. While I believe this is generally true, I remain skeptical that there is always a perfect layout strategy available every time. I think this might especially be true in cases of overconstraint relaxing or recovering from anomalous documents. My first impression is that either of these processes will largely be governed by heuristics, and it's my experience that where heuristics are involved, matters of opinion quickly follow. Moreover, is FOP really that far from, say, the HTML rendering engine in a web browser with respect to layout decisions? I see a lot of interpretations and opinions going on in those engines, which is why two browsers sometimes interpret my HTML table layouts in different ways. While there can be plenty of discussion of how best to obtain #1 and #2, once it is determined that solution A takes x seconds and solution B takes x + 2 seconds, you tend to go with solution A. So over the long term, multiple layout strategies may not be needed. They may not, but I think they might. I can safely say that I haven't read all of the FO spec, but I do see the word may cropping up from time to time with respect to spec compliance. I don't think we can create a single layout strategy that correctly selects the correct side of that may every time. For certain classes of documents (which, for argument's sake, aren't readily detectable in a programmatic way), the choice has to be made, and why not leave that choice in the hands of programmers and operators? I just mention these sorts of things because, all too often, spec compliance eventually becomes a matter of opinion anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
--- Rhett Aultman [EMAIL PROTECTED] wrote: Moreover, is FOP really that far from, say, the HTML rendering engine in a web browser with respect to layout decisions? I see a lot of interpretations and opinions going on in those engines, which is why two browsers sometimes interpret my HTML table layouts in different ways. Exactly--note there are two *different* browsers, each choosing to implement the HTML standard differently, each hoping their decision is the best for the most number of users. To me, multiple layout strategies is really like saying multiple applications. (After all, the layout handler and renderers *form* an XSL FO formatter.) There are already plenty of teams trying to implement the XSL FO spec, each making its own decisions on which layouts/goals/tradeoffs, etc. are best. FOP is one of them--hopefully it will make the right decisions to have a large market share. FOP's goals should be (1) to be compliant/accurate with the spec, and (2) be able to generate the largest numbers of huge files in the smallest amount of time. Instead of pluggable layout strategies, it may be better to have compiler switches for the various output types that would allow the user to make goal #1 vs. goal #2 tradeoffs where appropriate. We can put them in the CLI, and others wishing to build a GUI on top of FOP can nicely include them on options screens, etc. Glen __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Setting up CVS on Mac OS X (was Re: A couple of FAQ items)
Jeremias, On 5/28/2003 12:02 AM, Jeremias Maerki wrote: I'm grateful that you indicate problem spots in our documentation and offer suggestions. But may I encourage you to just do (TM) the changes yourself and submit patches in the future? Your suggestions would make it on the website a lot faster that way. We are eager to help you set up your environment to do this. Sounds good. I've got a Mac OS X machine (my personal machine) that comes with CVS built-in but I've never used it. Unfortunately, I'm limited on my work PC to what I can download there (*everything* I download has to be pre-approved). Don't know much 'bout CVS yet, but I've got a couple of places to look (http://www.macslash.org/article.pl?sid=02/05/31/1934236mode=nested, http://developer.apple.com/internet/macosx/cvsoverview.html, and http://cvsbook.red-bean.com/cvsbook.html if anyone's interested). I just haven't found the need to use CVS yet. I've just downloaded MacCvsX 3.3a2 (a cvsgui from http://cvsgui.sourceforge.net/--yes they have a Mac OS X version, albeit BETA ALPHA versions--but it seems to work!) and have begun plugging away to get set up. I've downloaded CVS xml-fop. However, I don't know how to use it. Also, I don't know where the web site docs are located so I wouldn't know how to patch/submit patches for the web site. Any clues? Can someone point me in the direction of the web site CVS? I'd love to start patching away. (NOTE: to Victor et al, the docs are already in *much* better shape than when I first got here ~1 year ago!) -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: A couple of FAQ items
On 5/28/2003 12:02 AM, Jeremias Maerki wrote: A comment concerning the hyphenation patterns: I think what you suggest is necessary but there was also the idea of sparing the average FOP user the necessity to dig into licensing issues. A really frustrating experience. Just for the record. :-) On 27.05.2003 19:42:19 Clay Leeds wrote: HYPHENATION INFO: 3.9. Hyphenation does not work. Set the language attribute somewhere. Check whether you use a language for which hyphenation is supported. Supported languages can be deduced from the files in the hyph directory of the FOP source distribution. While I agree we should spare the average user of licensing issues, my point is that there are places where the average user can legally download the same hyph patterns Apache cannot incorporate into their products for licensing reasons. As long as they are links to pages (I don't recommend links to the files themselves! ;-p), it would seem helpful to provide such links. The average user may not have to deal with the licensing issues the Apache Foundation has to deal with (they may have to deal with them, but may be in their rights to use them or to fulfill the licensing requirements to use them). As for the Hyphenation FAQ, it's so brief it begs to have questions submitted to fop-user by anyone having hyphenation problems. I, for one, still don't even understand how it works. It would be great to merely put something like this: Hyphenation === You can find an example of implementing hyphenation patterns in this example xsl-fo document: examples\fo\basic\hyphen.fo The relevant code for adding hyphenation to an fo:block is: language=en country=US hyphenate=true hyphenation-push-character-count=2 hyphenation-remain-character-count=2 [..] Of course, I still don't know how to apply a language attribute to my XML source file. The XML Bible Gold Edition shows this: q xml:lang=fr-FR cite=ftp://movie0.archive.org/pub/etext/etext01/swann10h.htm; Longtemps, je me suis couche' de bonne heure[..] /q After reading this, I would try adding the following to my document: doc xml:lang=en-US EOB children-of-EOBYeehaw!/children-of-EOB paragraph-pertaining-to-EOB-childrenYata yata yata /paragraph-pertaining-to-EOB-children [..] /EOB /doc (or I could use doc xml:lang=en-GB or merely doc xml:lang=en because of our current licensing problems)... BTW, how does one allow the en-GB hyphenation pattern (which is included with the FOP distribution) to work for en-US (which I believe isn't included due to licensing issues)? I remember someone mentioning somewhere a workaround, but I don't recall what it was. Something like naming it en instead of en-GB or something. -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RC4 (was Re: hack to avoid memory overflow with tables)
J.Pietschmann schrieb: Hi all, now that there are a few more modifications in the maintenance branch, waht about including the fixes mentione here: http://marc.theaimsgroup.com/?l=fop-userm=105371539508744w=2 It would need some testing (read 0.20.5rc4) Nooo, no more RCs for 0.20.5 please It's almost one year after the last release and as it seems quite stable now so I would really like to make the release soon. Yes I know we agreed on 0.20.5 beeing the last release from maintenance branch but making RCs after RCs is IMHO worser than making changes after the last release and providing daily builds or whatever. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
How to lock / disable saving of PDF file
Hi, Can we stop the generated PDF file from being saved? If yes, how? Can we lock the generated PDF file so that it can't be altered by any adobe acrobat creator? If yes, how to do that? Really need this information urgently. Thanks. -Susan- _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: How to lock / disable saving of PDF file
You can use PDF encryption to do that. Please read the documentation: http://xml.apache.org/fop/pdfencryption.html I recommend you use FOP 0.20.5rc3a. (Please post questions about FOP on the fop-user mailing list next time so other users can profit from questions and answers, too. Thank you!) On 29.05.2003 11:32:51 susan atmaja wrote: Can we stop the generated PDF file from being saved? If yes, how? Can we lock the generated PDF file so that it can't be altered by any adobe acrobat creator? If yes, how to do that? Really need this information urgently. Thanks. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
