Thorsten Scherler wrote:
> 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
>>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.
I disagree, for the use case we have here it is very easy to achieve
since all the CSS style information is generated by the XSL which
extracts it from the original source document. All that is required to
turn the hack solution in the OOo plugin into a solution that produces
valid XDocs is to create a separate pipeline to create the CSS sheet
rather than have it created as par of the intermediate XDoc.
> Now to the promised example, I would place the style information into a
> forrest:view like:
> 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
| ft="color_ff0000"/> that will be matched in the xsl.
How is this any different from || as I was proposing?
I see a different attribute name, but not a different design. Wouldn't
it be better to stay consistent with XHTML2 since that will be our
The only other difference I see is where the CSS classes are defined. In
your proposal it is in a forrest:views definition file. In mine it is in
some other file (skinconf.xml, pdf-output.xml or whatever):
I feel I must be missing something important about forrest:views ...
> 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.
Yes, love the idea of fbits. However, fbits are about content in the
page whereas this RT is about the subsequent styling of the page. I do
not think there is *any* overlap between the two stages of production.
It may make sense to move the style configuration stuff into
forrest:views when it is implemented, but I don't think we need to wait
for it since I believe such a change will only require a few changes to
the skining pipelines and stylesheets.
Is there more to it than that?
> 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. .
> I will have to return to work, but fell free to ask question and suggest
Sorry, I don't understand your problem, where is the code snippet from,
is it in the intermediate docs, the XSL. I'd be happy to try and help
solve this problem but you'll need to explain it more completely
(probably in a different thread).