On Thu, 2005-02-24 at 10:31 +0000, Ross Gardler wrote:
> Johannes Schaefer wrote:
>
> > With what is proposed now would I have to define a
> > lot of classes like class="color_ff00ff" and define
> > these classes in the file-specific config?
>
> Take a look at the OOo plugin. It does exactly this with a similar file
> format, although it places the style stiff in the xdoc so this is only a
> partial solution, but at least it uses classes. Perhaps you can try and
> replicate for the Excel sheet to see if it works. Here's a where to
> start looking:
>
> In the root template we have
>
> <header>
> <title>
> ....
> </title>
> <xsl:call-template name="style"/>
> </header>
>
> The style template looks like this:
>
> <xsl:template name="style">
> <style>
> <xsl:apply-templates select="//office:styles/style:style"/>
> <xsl:apply-templates select="//office:automatic-styles/style:style"/>
> </style>
> </xsl:template>
>
> The rest of the templates you can easily trace from here. We match all
> the style information that we want to allow through to the skinning
> stage, therefore it would be possible to configure which style
> information we allow and which we disallow on a per document basis.
>
> With this RT this style information would be extracted with the request
> for the plugin config stuff rather than embedded in head.
>
> Can this work for Excel sheets?
>
> > Or would I need to extend the DTD to validate this
> > single file and provide an XSL fragment (like extra-XSL)
> > to translate it?
>
> No, we do not want style information in our intermediate format so no
> extending the DTD.
>
The problem that I see is that if you have a table with many colored
fields and all have different colors that can be pretty soon overkill. I
understand that the intermediate format should be clean of style
information but I reckon it will be pretty hard to achieve.
Now to the promised example, I would place the style information into a
forrest:view like:
...
<forrest:hook name="color_ff0000">
<css>
<background-color value="#ff0000"/>
</css>
</forrest:hook>
...
Then I would add this to fileSpecific.ft (ft = forrest template) add it
to an aggregation and match it in the xsl.
In the document I would recommend to add an attribute <td
ft="color_ff0000"/> that will be matched in the xsl.
The whole thing do not have much to do with fbits. I am just using the
forrest:views as config file format for the fbits.
fbits are capsuled code snippets that can be called by a forrest:view.
The fbit plugin has a method "get.fbits.*" (in form of an URL) which
will return the snippets. * has to be replaced by the name of the fbit.
The only problem that I am facing and that is why I do not really get to
the point of releasing it is that I am facing the problem of how to
resolve the variables of the snippets before I parse them to the code.
e.g. <img class="skin" src="{$skin-img-dir}/poddoc.png" alt="POD -
icon" />.
I will have to return to work, but fell free to ask question and suggest
alternatives.
> > Just my part of RT ;-)
>
...and my. ;-)
> I'm glad you spoke up, it is your post that prompted me to write this RT
> it has been knocking around on my To Do list for some time. Now there
> are three of us with a strong use case (Thorsten is the third) it should
> be easier to discover a suitable solution.
>
yeah I will hope as much as I can ATM.
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
