I'm afraid I can't go into detail on what functionality that is not available, however I can say that handling the output in this way would provide the functionality we need.
Re arbitrary python: The only python that would be executed is the python that's included by the output engine author. This is a good thing because asciidoc would no longer be limited to building a single file from one single input. You could split the document up into multiple HTML documents (without a2x) or you could automatically post it to a website. Anyways, the system I've proposed is heavily based on the theme system from Drupal. On Mar 10, 2:59 pm, Lex Trotman <[email protected]> wrote: > 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.
