Re: Designing PDF extensions: form fields
Hi Hansuli, I see your point. A mininmal implementation that puts the effort onto the users would be easier to implement and maybe it can be improved from that starting point. Exactly how complicated are these things if it would take 96 pages to describe it to a user? Wouldn't one form type simply require an example and a brief explanation of the variables. On 2002.04.04 12:07 J.U. Anderegg wrote: Hi Keiron, Let's fix a DESIGN GOAL. What can be realized in which time frame? I see 2 ways to go ahead: 1. Low level implementation using native PDF syntax: users have to learn PDF syntax and to some extent PDF file structure. They can try experimentally everything with the risk of invalid PDF in the document test phase. The document development might look like this: - get documentation: PDF reference manual or see PDFmarks in http://www.math.uakron.edu/~dpstory/tutorial/pdfmarks/forms.pdf - develop document without form fields - use Acrobat to add the form fields to the document - view the PDF document in ASCII e.g. with Windows WordPad and copy form field PDF objects into FOP markup - test, modify FOP markup 2. Perfect, complete XML syntax for PDF forms covers all functions. Perhaps XHTML could do this job. The system is fully documented, so that users never have to care about PDF internals (my favorite reference document has 96 pages). The PDFextension takes over FOP properties and uses existing PDF methods. Additional properties needed for PDF form fields are handled. Of course a clean system (2) is preferable. Where is the expert to take over this task? Not very elegant system (1) can be set up within 1 month assumed the pdf library offers an API to allow PDF extensions - the base for other developments. Once priorities are set, technicalities will be solved efficiently. Hansuli Anderegg, Zurich, Switzerland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some comments on the build system
This page has the cvs keywords: http://www.loria.fr/~molli/cvs/doc/cvs_12.html None of them seem to be useable for the version of a product. You still need to change something to make this update anyway. On 2002.04.05 00:44 Peter B. West wrote: Keiron, I don't know the nuts and bolts of CVS, but I always assumed that tags were somehow related to the RCS symbolic name, accessible via $Name$. $Name$ has some peculiarities due to the fact that there is not a unique name attached to the current version; I think it is set in the output files from the symbolic name under which the file is retrieved. I don't know, off hand, what the deault behaviour is. I can check the RCS characteristics here. Do you want to install $Name$ in one of the CVS files and see what it looks like when retrieved? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: How to get 20.3 to build
Using xalan from jaxp1.1 and manually transforming ./build/src/codegen/allprops.xml ./build/src/codegen/genconst.xsl to ./build/src/org/apache/fop/fo/properties/Constants.java caused same error. Using xalan from jaxp1.2ea2 generated it o.k From: Paul Hussein on 05/04/2002 08:17 To: [EMAIL PROTECTED] cc: Subject: Re: How to get 20.3 to build (Document link: Paul Hussein) Ah!! Looks like the autogenerated file is not generated in the first pass, and second pass error as described occurs cos file does not exist. Here is the autogeneration of file error : Building with classpath /dvl/sw/jdk_1.2.2_09/lib/tools.jar:/dvl/sw/jdk_1.2.2_09/lib/classes.zip:lib/ant.jar:lib/ant-1.3-optional.jar:lib/batik.jar:lib/buildtools.jar:lib/xerces-1.2.3.jar:lib/xalan-2.0.0.jar:lib/xalanj1compat.jar:lib/bsf.jar:lib/jimi-1.0.jar:lib/logkit-1.0.jar:lib/avalon-framework-4.0.jar Starting Ant... Buildfile: build.xml init-avail: init-filters-xalan1: init-filters-xalan2: [copy] Copying 1 file to /home/husseinp/java/fop/fop-0.20.3/build/src/codegen init: [echo] --- Fop 0.20.3 [1999-2002] prepare: [echo] Preparing the build directories [mkdir] Created dir: /home/husseinp/java/fop/fop-0.20.3/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /home/husseinp/java/fop/fop-0.20.3/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir: /home/husseinp/java/fop/fop-0.20.3/build/src/org/apache/fop/svg [mkdir] Created dir: /home/husseinp/java/fop/fop-0.20.3/build/classes/conf [mkdir] Created dir: /home/husseinp/java/fop/fop-0.20.3/build/classes/hyph [copy] Copying 3 files to /home/husseinp/java/fop/fop-0.20.3/build/classes/conf codegen: [echo] Resetting codegen directory [copy] Copying 37 files to /home/husseinp/java/fop/fop-0.20.3/build/src/codegen [echo] Generating the java files from xml resources xslt in: ./build/src/codegen/allprops.xml style: ./build/src/codegen/genconst.xsl out: ./build/src/org/apache/fop/fo/properties/Constants.java java.lang.StackOverflowError at java.util.Vector.elementAt(Compiled Code) at org.apache.xpath.VariableStack.getCurrentFrame(Compiled Code) at org.apache.xpath.VariableStack.getVariable(Compiled Code) at org.apache.xpath.XPathContext.getVariable(Compiled Code) at org.apache.xpath.operations.Variable.execute(Compiled Code) at org.apache.xpath.functions.FuncConcat.execute(Compiled Code) at org.apache.xpath.functions.FuncSubstringAfter.execute(Compiled Code) at org.apache.xpath.XPath.execute(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.pushParams(Compiled Code) at org.apache.xalan.templates.ElemCallTemplate.execute(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.templates.ElemChoose.execute(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.templates.ElemTemplate.execute(Compiled Code) at org.apache.xalan.templates.ElemCallTemplate.execute(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.templates.ElemChoose.execute(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.templates.ElemTemplate.execute(Compiled Code) at org.apache.xalan.templates.ElemCallTemplate.execute(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Compiled Code) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Co Christian Geisert [EMAIL PROTECTED] on 04/04/2002 16:25:40 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: How to get 20.3 to build [EMAIL PROTECTED] wrote: I get this error when running build.sh compile: [echo] Compiling the sources [mkdir] Created dir: /home/husseinp/java/fop/fop-0.20.3/build/classes/org/apache/fop/viewer/resources [copy] Copying 11 files to /home/husseinp/java/fop/fop-0.20.3/build/classes/org/apache/fop/viewer/resources [mkdir] Created dir: /home/husseinp/java/fop/fop-0.20.3/build/classes/org/apache/fop/viewer/Images [copy] Copying 5 files to /home/husseinp/java/fop/fop-0.20.3/build/classes/org/apache/fop/viewer/Images [javac] Compiling 497 source
File locked by driver.render?
Hi! I have atrouble with FOP I have an aplication which generates a temporary XMLfor generating a PDF document. After doing that, the XML file is removed. It worked right with FOP 0.18.1. Now I've had to update itto FOP 0.20.3rc and it doesn't work propertly. The problem is that the driver.render method locks the XML file and I can´t delete it (and INEED todo it) Here's the code around the driver.render that causes de trouble. driver.setErrorDump(true); driver.setRenderer(Driver.RENDER_PDF); driver.setOutputStream(out); // --- Here I can delete de XML file driver.render(xsltPfInput.getParser(), xsltPfInput.getInputSource()); byte[] content = out.toByteArray(); objPfResponse.setContentLength(content.length); objPfResponse.getOutputStream().write(content); objPfResponse.getOutputStream().flush(); objPfResponse.getOutputStream().close(); out.close(); // --- Here I can't delete de XML file Thanks a lot to anyone for any help
Re: Some comments on the build system
Keiron, As I suspected, $Name$ is the tag used to check out the file. In my maint checkout, I have a sticky CVS/Tag specifying fop-0_20_2-maintain (symbolic names cannot contain dot, because a revision is composed of one or more numeric or symbolic fields separated by periods - `man co'). Whenever I update, I am going to get that tag, and any $Name$ fields will contain that text. If the original conf/config.xml contains keyversion/key value$Name$/value I will actually see (given the default -kv flag to CVS) keyversion/key value$Name: fop-0_20_2-maintain $/value when I checkout or update. As I can't commit, I can't test this. Does it work that way? If so, the basis for providing the version string in the code is already in place. If that's unbearably ugly, add some code to Version.java to massage it. Symbolic names can contain any character except [0-9$@.;:], so there's plenty of room for establishing a conventional character to represent a space in the transformed output. E.g. FOP@0_20_2-maintain. I would be inclined to leave the underscores; I would be inclined to leave FOP-0_20_2-maintain untouched, just stripping off the keyword noise. $State$ is also available, but seems to require a cvs admin -s. What about HEAD? Just set a sticky tag of, say, FOP-1_0dev for commits, and notify that development checkouts must use this tag. If somone forgets when checking out, I don't think it's critical for development, as long as the commits use the tag. Releases will be frozen with the appropriate release tag, e.g., FOP-0_20_2-RC3, as I assume is currently done using rtag. Peter Keiron Liddle wrote: This page has the cvs keywords: http://www.loria.fr/~molli/cvs/doc/cvs_12.html None of them seem to be useable for the version of a product. You still need to change something to make this update anyway. On 2002.04.05 00:44 Peter B. West wrote: Keiron, I don't know the nuts and bolts of CVS, but I always assumed that tags were somehow related to the RCS symbolic name, accessible via $Name$. $Name$ has some peculiarities due to the fact that there is not a unique name attached to the current version; I think it is set in the output files from the symbolic name under which the file is retrieved. I don't know, off hand, what the deault behaviour is. I can check the RCS characteristics here. Do you want to install $Name$ in one of the CVS files and see what it looks like when retrieved? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some comments on the build system
Arved, Obviously, I share many of your attitudes to properties, but I differ in one respect. I think of properties not as rich, but as impoverished. To me, they are just associations of names with values. The richness lies in their treatment in the process of layout, where all of those constraints and interactions will have to be accommodated and resolved in the application of properties to FOs and areas. Interactions, e.g., are inherently outside any individual property. Constraints, I have to admit, are generally property-centric, even where they involve testing the value of other properties. This view underlies my attempt to reduce property handling to a set of arrays. I still have an individual (though nested) class for each property, from which commonalities are extracted, while special cases are handled by methods peculiar to the class. Your concerns (and mine) about the association of build.xml release number and the tag would be resolved by making them identical, or at least deriving the first from the second. If my understanding of the relationship between RCS and CVS is correct, we can do this. Peter Arved Sandstrom wrote: Hi, Peter I personally agree that the properties don't need the XML+XSLT approach. Even if one leaves aside the aural properties there are over 250 properties, and on close inspection the commonalities are limited. I believe the largest group size of properties that are identical is 4. Many properties have extra constraints (they interoperate with other properties, for example), they accept different combinations of input generic types, percentages have meaning only in the context of the property, and so on and so forth. One could come up with a super-sophisticated XML+XSLT system to embody all this, but why bother? I'm not going to bad-mouth the current system that FOP has. I acquiesced at least implicitly in the choice to at least continue with it, at an early stage. But I now believe that the right place for a lot of logic related to properties is actually in the properties. I think an XML+XSLT approach pushes a lot of that out into places where it ought not to be. Most of the common handling has actually little to do with the properties per se - it has to do with expressions and datatypes. This is not the same thing. An XSL property is not a datatype, IMO, and shouldn't be regarded that way. I don't think it's a pressing issue unless someone then immediately proposes and moves forward with work to make the properties rich, interesting things. It's not really an IDE issue - there are IDEs that handle the current FOP setup just fine. I also agree that ease of making changes to properties is not a compelling argument for XML files, nor for using XSLT to generate the code. The properties are simply not that similar. So you may as well work on Java properties files directly. And since properties _are_ what make XSL, if there are significant changes in properties in the spec then the disruption is going to be widespread. I agree with Keiron's observations regarding the other point, about versioning. Our numbers are release numbers (major, minor, patch, plus stage info, as he puts it), and these require human decision-making. You can't automate release numbers sensibly. Anything else Ant supports (timestamping, token filtering, build number incrementing) makes a lot of sense in the right contexts, mostly in the sense of configuration management and builds. I'd like to see a stronger link between the release number in the build.xml and the presence of a matching tag in the CVS, myself. I've been personally guilty of forgetting to tag the CVS when buildng a distro and it's because there was no mechanism to jog my memory. I don't think the tagging itself should be automated but some aspect of the source code retrieval prior to building a dist* target should be dependent on the presence of a matching tag. Let's face it, right now we have no configuration management at all - maybe this isn't much better but at least it's something. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: License Issue Inquiry
On Thursday 04 April 2002 14:47, you wrote: At 08:34 AM 4/4/02 -0500, Charles Marcus wrote: like it could be the answer. The only question is, can OOo use it? license of it's software. My question is why does OOo require FOP to be LGPLed? You can integrate it into OpenOffice without it being LGPL. You can't change the Apache license into LGPL but you can license YOUR CODE under LGPL (or GPL or even MicroSloth EULA). This will require anyone using YOUR CODE to observe LGPL (or whatever), which is what you want to do, as I understand it. This would allow anyone else to extract the Apache-licensed code out of your distribution and use it under Apache terms, as long as they removed all of the LGPL code from it. Of course, it would be easier to go out and get a pristine copy of FOp instead. The only thing you can create license terms for is YOUR CODE and then it still has to be provably original etc. etc. If you do this it would also be fair if you contribute changes to FOP back to the Apache tree. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Multithreaded failure
Scott Moore wrote: org.apache.fop.configuration.Configuration.put(strokeSVGText, new Boolean(false)); Nitpick: there is a predefined Boolean.FALSE :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Question for FOP
Cai, Jenny (US - Dallas) wrote: I just successfully run the examples (simple.fo) provided in 'fop-0.20.3-bin.tar.gz' file under fop-0.20.3\docs\examples\fo subdirectory in the command prompt and I got a pdf file successfully . I still have the following question: 1. How can I view the source code for this example? 2. I also looked over all the rest of the folders included in 'fop-0.20.3' and there are a lot other folders like design, html-docs(some .html files in it), xml-docs(some xml files in it), etc. What are all those files used for? 3. Actually what I want to do is: convert a XML file to PDF file and display this PDF file on the web page. How to do this? What you are asking for is somewhat akin to I attended a guided tour at a military airbase. What I want to do is: attack some real life hostile jet fighters and have them shot down. How to do this? Your best bet is probably to hire a professional who does the job for you. Of course, you can go all the way yourself. Others did it, though they didn't start with the questions above. Good luck. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Question for FOP
On Thu, 2002-04-04 at 14:31, Cai, Jenny (US - Dallas) wrote: Hi, Hi Jenny, I just successfully run the examples (simple.fo) provided in 'fop-0.20.3-bin.tar.gz' file under fop-0.20.3\docs\examples\fo subdirectory in the command prompt and I got a pdf file successfully . I still have the following question: 1. How can I view the source code for this example? I think, based on your third question below, that you're looking for an XML file that is then converted to PDF. The simple.fo is the source, written in XSL:FO, which is XML. But, probably not what you were expecting. I personally don't write my documentation directly in XSL:FO but instead write them in some other XML format (such as DocBook, http://docbook.org/ ) and then write stylesheets (or using existing stylesheets) to convert the XML format to XSL:FO. I then use FOP to render the XSL:FO as PDF. I think that's the kind of thing that you would be looking for as well. 2. I also looked over all the rest of the folders included in 'fop-0.20.3' and there are a lot other folders like design, html-docs(some .html files in it), xml-docs(some xml files in it), etc. What are all those files used for? These would just be the documentation for FOP. The html-docs folder contains the FOP documentation in HTML format, generated from the xml-docs/fop folder. I noticed that under the xml-docs folder, there is the skins folder which contains stylesheets (used in converting the XML documents to HTML, PDF, etc). Think of the xml-docs folder as the source and the the html-docs folder as the output (programatically speaking). 3. Actually what I want to do is: convert a XML file to PDF file and display this PDF file on the web page. How to do this? There would be a couple of ways of doing this. The first would be to generate the PDF in a batch mode and create a static web site containing web pages that reference the static PDF documents. The second would be to dynamically create the PDF documents. This would be done with a servlet using a servlet engine such as Apache Tomcat. There is an example of doing this on the Apache FOP website ( http://xml.apache.org/fop/embedding.html ). Another method would be to use Apache Cocoon (which can also be found on http://xml.apache.org/ ) I am new to this and really like to have your advices and help. So if you could provide further information, I would appreciate it very much. Hope this helps. -- Rick Tessner [EMAIL PROTECTED] There are no bad days. Only good days and great days. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
