On 11/10/05, Bruce D'Arcus <[EMAIL PROTECTED]> wrote: > > Might be silly Bruce, but if you are trying to please a number of users; > > how about splitting it (to ease processing and reduce compromises).
> > By "it" you mean the processing code? That's certainly a possibility. Perhaps even the end to end options. Is it effectively 3 items? 1. Gloss entry (Is the xforms input helpful here?) 2. Integration with the remainder of the document. 3. Output transforms. What sense does it make viewing the path through the 3 bits in isolation (with hooks for the other stages?) > > However, the tricky thing, it seems to me, is not the actual processing > code, but rather the glue that integrates whatever processing into OOo > (and OD). Am not sure how that could or should work. Some of the SW > developers had mentioned the possibility of creating a container for > this sort of content, and then exposing it as a mini-DOM for processing. > I don't really know what they would mean practically though (am not > much of a coder!). Would x-forms help? Could you design a form which enabled a user to enter all the gloss entries? How to get that data back into the document processing chain is a question I can't answer. > > As for "traditions," to hell with them. If people are happy with LaTeX > and BibTeX, they can keep them. I want this to be a better alternative > for those that need them (and that includes end-users ultimately who > will never know or care about the implementation details, but just want > their stuff to work). If your actual presentation can match or better traditional options, you can win with both schools of thought? regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
