On 10 March 2010 11:38, cweagans <[email protected]> wrote: > Below is a paste of a conversation I had with Stuart via email. Any > input on this topic would be appreciated, as my company is wanting to > move forward on this. If the Asciidoc community is interested, we'll > build it on Asciidoc. Else, we'll go with another solution that > supports what we need (we want to contribute to an open source > project, hence my post. If the contribution just doesn't really fit > any projects, we'll either create our own or use Open Office or > something) > > > +-------------------------------------------------------- > from: [email protected] > to: [email protected] > date: March 8, 2010 > +-------------------------------------------------------- > Hi Stuart, > > First off, I'd like to thank you for all the work you've put into > asciidoc. We're using it internally for documentation and customer > manuals and such, and it's working really well! > > We've been having some difficulty with asciidoc, in that it's > difficult to do some of the things that we'd like to do (sorry for the > vagueness...I'm not really allowed to say too much about our > documentation, due to a super-strict NDA). I'm a programmer and I'd > like to implement our needed features, but I don't want to put a bunch > of time into it if it won't be accepted as a contribution to asciidoc. > > So, my question is, how would you feel about a major rewrite of how > asciidoc outputs formatted data? Existing documents will be > unaffected, as the modifications would only affect the output logic. > These changes would allow for more output formats, as well as the > ability for end-users to tweak how asciidoc outputs data (for example, > it would be a very very trivial matter to make asciidoc output <h1 > class="class1 class2 class3" id="header_123"> rather than just <h1>. > > Essentially, I'm talking about building an easily extensible output > layer for asciidoc. > > Interested? > > -Cameron Eagans > > > +-------------------------------------------------------- > from: [email protected] > to: [email protected] > date: March 8, 2010 > +-------------------------------------------------------- > Hi Cameron, > > You will need to be a bit more specific, some examples (input and > output) would be nice, any text is fine, no need to include any NDA > related stuff. Also the rationale and the advantages of you proposed > changes would be good. > > I suggest that you post it to the AsciiDoc discussion list (http:// > groups.google.com/group/asciidoc) to get input from other users. > > > Cheers, Stuart > > > +-------------------------------------------------------- > from: [email protected] > to: [email protected] > date: March 8, 2010 > +-------------------------------------------------------- > > Basically, what I'd like to do is this (I'll use the XHTML output > format for my examples): > > There is a set of entities that asciidoc supports for rendering. A non- > exhaustive list: headers (1 through 6), bold, italic, underline, > normal text, and code listings. > > Every output document has a set of entities that it requires. In my > vision for this implementation, you'd have a directory for every > output format that contains template files for each asciidoc supported > entity. > > /home/cweagans/asciidoc/output/xhtml: > document.tpl > h1.tpl > h2.tpl > h3.tpl > h4.tpl > h5.tpl > h6.tpl > bold.tpl > italic.tpl > underline.tpl > text.tpl > code_listing.tpl > xhtml.conf > > Each .tpl file is simply a python script that prints the appropriate > markup (or uses a python library to generate PDFs or to generate ODT > or....you get the idea). > > document.tpl might contain: > > print """ > <html> > <head> > <title>%(title)s</title> > </head> > <body class='%(body_classes)s''> > %(content)s > </body> > </html> > """ % variables > > variables would be created when the file is loaded and populated with > the needed information to build the document. > > Smaller entities are trivial: > > h1.tpl might contain: > > print """ > <h1>%(content)s</h1> > """ % variables > > > The .conf file might contain some information about what order to load > the entities, or maybe a reference to a pre-build or post-build script > that would get executed before or after the initial compile on the > document (for example, a .odt post-build script might write all the > needed files and compress them into the archive format needed for > opendocument) > > Since all of the entity templates would be standard python, there's no > reason why asciidoc couldn't support, for example, .odt output or even > (if you are feeling -really- daring) voice files or microsoft word > documents. > > I haven't fully fleshed out the idea because I haven't actually > started implementation, but that's the basic idea. > > What do you think? > > -Cameron >
Hi Cameron, I'm all for highly configurable systems, but I'm also wary of significant re-implementations that may change default behaviour, add bugs and reduce default functionality (KDE anyone? :-). Can you explain what functionality is gained over the existing configuration files system? Especially what you need that is not available, or can't be added to the current system? Also I would note that executing arbitrary Python from files is a HUGE security risk, it could mail your NDA docs to me each time you asciidoc them :-) Cheers Lex > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<asciidoc%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/asciidoc?hl=en. > > -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
