AW: Structure renderers area trees (Re: startup refactoring)
Bertrand Delacretaz wrote The whole point of the StructureHandler interface is to be able to reuse FOP's frontend for structure-based renderers. The impact of StructureHandler on the standard FOP output formats (PDF mostly) is minor, but it allows the FOP pipeline to branch cleanly, after the parsing and attributes resolution, to generate either structure-based or page-based formats. How do you plan to handle RTF styles? Is it difficult to transform tables and lists? Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs pdfencryption.xml
jeremias2003/06/23 01:36:13 Modified:src/documentation/content/xdocs pdfencryption.xml Log: Added instructions for embedding. Revision ChangesPath 1.6 +69 -1 xml-fop/src/documentation/content/xdocs/pdfencryption.xml Index: pdfencryption.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/pdfencryption.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- pdfencryption.xml 27 May 2003 00:02:42 - 1.5 +++ pdfencryption.xml 23 Jun 2003 08:36:13 - 1.6 @@ -7,6 +7,7 @@ titlePDF encryption./title authors person name=J.Pietschmann email=[EMAIL PROTECTED]/ + person name=Jeremias Märki email=[EMAIL PROTECTED]/ /authors /header body @@ -30,7 +31,7 @@ /p /section section - titleUsage/title + titleUsage (command line)/title p Encryption is enabled by supplying any of the encryption related options. @@ -58,6 +59,73 @@ code-noannotations/code options, which disable printing, copying text, editing in Adobe Acrobat and making annotations, respectively. /p +/section +section + titleUsage (embedded)/title + p +When FOP is embedded in another Java application you need to set an +options map on the renderer. These are the supported options: + /p + table +tr + thOption/th + thDescription/th + thValues/th + thDefault/th +/tr +tr + tdownerPassword/td + tdThe owner password/td + tdString/td + td/ +/tr +tr + tduserPassword/td + tdThe user password/td + tdString/td + td/ +/tr +tr + tdallowPrint/td + tdAllows/disallows printing of the PDF/td + tdTRUE or FALSE/td + tdTRUE/td +/tr +tr + tdallowCopyContent/td + tdAllows/disallows copy/paste of content/td + tdTRUE or FALSE/td + tdTRUE/td +/tr +tr + tdallowEditContent/td + tdAllows/disallows editing of content/td + tdTRUE or FALSE/td + tdTRUE/td +/tr +tr + tdallowEditAnnotations/td + tdAllows/disallows editing of annotations/td + tdTRUE or FALSE/td + tdTRUE/td +/tr + /table + note +Encryption is enabled as soon as one of these options is set. + /note + p +An example to enable PDF encryption in Java code: + /p + source![CDATA[ +Driver driver = new Driver(); +driver.setRenderer(Driver.RENDER_PDF); +Map rendererOptions = new java.util.HashMap(); +rendererOptions.put(ownerPassword, mypassword); +rendererOptions.put(allowCopyContent, FALSE); +rendererOptions.put(allowEditContent, FALSE); +rendererOptions.put(allowPrint, FALSE); +driver.getRenderer().setOptions(rendererOptions); +driver.setOutputStream(...]]/source /section section titleEnvironment/title - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Structure renderers area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 10:35 Europe/Zurich, J.U. Anderegg a écrit : ... How do you plan to handle RTF styles? In jfor we defined an extension to XSL-FO (the jfor-style attribute) to control RTF styles. Another way would be to recognize sets of attribute values in the input XSL-FO and map them to RTF styles. I think some form of extension is needed as (AFAIK) the concept of styles does not exist in XSL-FO, as it is meant for printed output. If you import XML in the newest versions of FrameMaker for example, you have to define a kind of style map which recognizes specific constructions in the XML and assigns styles to them. This might also be an option, use a second input file that tells FOP which (MIF or RTF) styles to assign when certain patterns are recognized in the input. ...Is it difficult to transform tables and lists? Not too much, but when we developed jfor we targeted it at RTF 1.5 which as no support for nested tables, so we had to fake them using joined cells (as older versions of Word did). Other than that, the tables and lists structures of XSL-FO map nicely to RTF. Possible problems are relative dimensions, for example it might be hard in RTF to say that a table must take 60% of the page height. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: AW: Structure renderers area trees (Re: startup refactoring)
Bertrand Delacretaz wrote: ... How do you plan to handle RTF styles? In jfor we defined an extension to XSL-FO (the jfor-style attribute) to control RTF styles. I think some form of extension is needed as (AFAIK) the concept of styles does not exist in XSL-FO, as it is meant for printed output. (1) This is not a FOP extension, but rather a fundamental change of the XSL-FO language, which does not know stlye sheets. Another way would be to recognize sets of attribute values in the input XSL-FO and map them to RTF styles. (2) I wrote a few weeks ago this and it is still my idea, how FOP should store properties: Apply the principles of relational databases to eliminate redundancies: set up tables of unique/used fonts, strokes, colors, ... and have the objects reference table entries. This will cost table lookups, CPU. However, it will also ease state processing. The program does not have to keep track of inherited properties set 300 FO elements earlier. The nuisance is that style sheets have acceptable redundancy (see DocBook), XSLT replicates properties innumerable times and FOP has to recollect and normalize all this stuff. My opinion: (1) is off FOP territory (2) to be considered, if FOP is implemented on this way Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 12:08 Europe/Zurich, J.U. Anderegg a écrit : Bertrand Delacretaz wrote: ...In jfor we defined an extension to XSL-FO (the jfor-style attribute) to control RTF styles (1) This is not a FOP extension, but rather a fundamental change of the XSL-FO language, which does not know stlye sheets. What I called extension applies to XSL-FO, or rather to the input documents handled by jfor, which use the jfor-style attribute in addition to standard XSL-FO. You're right that this is not a FOP extension. This can be implemented cleanly with namespaces, so as not to pollute the XSL-FO input, something like fo:block font-size=12pt style:name=someRtfStyle Meaning that the style names are decorations to the input document. ...(2) I wrote a few weeks ago this and it is still my idea, how FOP should store properties: Apply the principles of relational databases to eliminate redundancies: set up tables of unique/used fonts, strokes, colors, ... and have the objects reference table entries Sounds reasonable, but I don't know enough about the current properties code to comment on this. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Team page [OT]
On 6/21/2003 9:16 AM, Victor Mote wrote: OK. The web site repository has now been updated. It should go live sometime in the next 6 hours. Yahoo! My name in lights (and my son's too! ;p) We just celebrated his birthday this weekend. He turned 1 and got to swim with 4 girls in his new kiddie pool... Amazing how much fun can be had in two inches of water! -- 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: AW: AW: Structure renderers area trees (Re: startup refactoring)
Nice idea, but there's a problem. The xsl namespace gets filtered out by the XSLT engine, or IOW expanded to the FO attributes before they reach FOP. FOP never sees anything with the xsl: prefix. On 23.06.2003 18:51:45 Clay Leeds wrote: Forgive my intrusion, and perhaps this is not related, or just using a different namespace, but why not define a xsl:attribute-set for each style and then use the xsl:use-attributes to help with the definition of the RTF/MIF style? Consider this this example (the comments are meant for people who want to modify 'my' template to change their output): snip/ Is this related to the discussion? I see that I'm using xsl: namespaces, but I'm curious to learn how this relates... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers area trees (Re: startup refactoring)
On 6/23/2003 10:19 AM, Jeremias Maerki wrote: Nice idea, but there's a problem. The xsl namespace gets filtered out by the XSLT engine, or IOW expanded to the FO attributes before they reach FOP. FOP never sees anything with the xsl: prefix. Does this mean that just about every fo:block in the intermediary FO file (the one you can only see if you run xalan.bat instead) has a cagillion font-weight=bold and font-face=courier new, courier, monospace? Wow! Sounds inefficient, and tedious but I guess that's how it goes... Speaking of which, how does the file created by '-at' differ from the file generated by running xalan.bat? -- 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: AW: AW: Structure renderers area trees (Re: startup refactoring)
On 23.06.2003 19:33:23 Clay Leeds wrote: On 6/23/2003 10:19 AM, Jeremias Maerki wrote: Nice idea, but there's a problem. The xsl namespace gets filtered out by the XSLT engine, or IOW expanded to the FO attributes before they reach FOP. FOP never sees anything with the xsl: prefix. Does this mean that just about every fo:block in the intermediary FO file (the one you can only see if you run xalan.bat instead) has a cagillion font-weight=bold and font-face=courier new, courier, monospace? Wow! Sounds inefficient, and tedious but I guess that's how it goes... Yep. Speaking of which, how does the file created by '-at' differ from the file generated by running xalan.bat? That's the Area Tree XML: The layouted pages serialized to a proprietary XML format. It's only interesting for debugging purposes (in layout engine development). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Alternative API proposal (was: startup refactoring)
I have done so now. I've added a new (sub)page to the Wiki to avoid making the FOPAvalonization page even longer. http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltAPIProposalJM While writing down my thought about the API I have come to the realization that I cannot make up my mind about the inner context classes Victor has come up with. But I think he's quite close: - Session: Looks like my and Jörg's FOProcessor to me. The user interacts with this class to configure FOP and do processing runs. - Document and RenderContext: I'm not sure but I think these two should be merged. I've called it ProcessorContext in my proposal at first, but then chose not to include them in the proposal right now because I didn't quite know what to put in there. The thing I know is that we need a central data object that keeps references while the FOProcessor implementation coordinates the processing (data separated from logic). - Renderer: You guys hate me for that, I know, but I still refuse to give it so much visibility in these discussions. In my proposal I've separated the logic from the data again (with JAXP as role-model) and made the Renderer a totally normal Avalon service that is being looked up by MIME type in the background. The FOPResult classes account for the differences of output types. The FOProcessor impl is responsible to establish the link between FOPResults and Renderer. For AWT (I'd like to call it Java2D from now on if you guys agree. That's the official name of the API after all.) I've tried to introduce an interface that clients can use to interact with the Java2D renderer. So, I don't have anything more concrete on the inner glue that keeps the whole process together but maybe my proposal brings some new ideas. I'd like to hear your thoughts about my proposal (flaws, nodding, missing things etc.). I hope that we can find a common path for the whole thing. Important to me is to have a good terminology and an API that conforms to the requirements I've written down on the FOPAvalonization page. Side note WRT resolvers: I've only placed the SourceResolver in the API because I think that the other resolvers are not necessary. I'm not certain about that but this can be easily added later. On 20.06.2003 21:40:09 Jeremias Maerki wrote: On 20.06.2003 21:34:28 J.Pietschmann wrote: Could you outline your API ideas on the Wiki? Yes, please. I'm also in the process of writing down my ideas. That way it will be much easier to relate everyone's ideas to each other. At the moment I wish we could all sit together and figure it out by talking together and painting on a whiteboard. The Wiki will have to suffice I guess. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alternative API proposal
Jeremias Maerki wrote: I have done so now. I've added a new (sub)page to the Wiki to avoid making the FOPAvalonization page even longer. Interesting proposal. One thing I'm still missing: - Renderer: You guys hate me for that, I know, but I still refuse to give it so much visibility in these discussions. Suppose the PDFRenderer a set of encryption options, as obtained from the request in a web service environment (or the text renderer is supposed to use the output encoding specified by the request). This is parametrization, not configuration, and in any case not as easy to press through a configure(File) or configure(InputStream). Could you add an example how this would be handled in your proposal? Side note WRT resolvers: I've only placed the SourceResolver in the API because I think that the other resolvers are not necessary. I'm not certain about that but this can be easily added later. Image and font resolvers are needed as hooks for users who want to have their own caching implementation or want to implement metrics access for fonts mapping to several odd files in all kind of even more odd places. However, they can be implemented as Avalon services too. And, well, the hyphenator is also a good Avalon service... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers area trees (Re: startup refactoring)
Jeremias Maerki wrote: Speaking of which, how does the file created by '-at' differ from the file generated by running xalan.bat? That's the Area Tree XML: The layouted pages serialized to a proprietary XML format. It's only interesting for debugging purposes (in layout engine development). And people who want to feed back results from the rendering process into a second XSLT pass... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alternative API proposal
On 23.06.2003 21:28:56 J.Pietschmann wrote: Jeremias Maerki wrote: I have done so now. I've added a new (sub)page to the Wiki to avoid making the FOPAvalonization page even longer. Interesting proposal. One thing I'm still missing: - Renderer: You guys hate me for that, I know, but I still refuse to give it so much visibility in these discussions. Suppose the PDFRenderer a set of encryption options, as obtained from the request in a web service environment (or the text renderer is supposed to use the output encoding specified by the request). This is parametrization, not configuration, and in any case not as easy to press through a configure(File) or configure(InputStream). Could you add an example how this would be handled in your proposal? I've updated the Wiki page. The parametrization (as opposed to configuration) is done through set/getOutputProperty (also see my comment on the Wiki page). TraX has setOutputProperty on the Transformer. I've moved it to the Result class because that's the more intuitive place for me. Side note WRT resolvers: I've only placed the SourceResolver in the API because I think that the other resolvers are not necessary. I'm not certain about that but this can be easily added later. Image and font resolvers are needed as hooks for users who want to have their own caching implementation or want to implement metrics access for fonts mapping to several odd files in all kind of even more odd places. However, they can be implemented as Avalon services too. Right. I think I'm not wanting to much if I let someone, who wants advanced functionality, implement an Avalon service and register it in the main configuration file. Day-to-day usage is covered by the API, special behaviour through the Avalon container. And, well, the hyphenator is also a good Avalon service... I guess so. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
