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
> The style template looks like this:
> 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
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
| 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.
I will have to return to work, but fell free to ask question and suggest
> > 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.
"Together we stand, divided we fall!"
Hey you (Pink Floyd)