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: 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]
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)
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): > 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 3:08 AM, J.U. Anderegg wrote: 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. 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): #ff #00 courier new, courier, monospace 8pt Then couple this with these fo:page-sequence calls: Is this related to the discussion? I see that I'm using xsl: namespaces, but I'm curious to learn how this relates... -- 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)
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 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]
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: 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: 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]
