On 5 November 2011 16:34, Stuart Rackham <[email protected]> wrote: > > > On 05/11/11 15:44, Lex Trotman wrote: > >> The big idea as far as I was concerned was *interactive* styling. >> > > By *interactive* styling do you mean that you can style the document you've > just generated using the Libre/Open Office GUI and the styling changes will > somehow be retained after subsequent editing of the AsciiDoc source and > regeneration of the of the odt file using asciidoc? That would be a big > idea. >
Yes, exactly that. Its why I'm interested in it. The a2x backend plugin in the "packaged" subdirectory of the repo uses an existing ODF template document and applies the styles to the output generated from asciidoc. (yes backend plugins are somewhere on your to-do list, see http://groups.google.com/group/asciidoc/browse_thread/thread/b8e93740b7cd0e1d/b5e0b83fe37ae31a?lnk=gst&q=a2x+backend#b5e0b83fe37ae31a :) Instructions are in the readme, you need to use the a2x from the repo with backend plugin capability until it (or something like it) gets added to the official version. Basic process: 1. asciidoc -b odt document.txt 2. open the odt file in libreoffice and style as needed, using the asciidoc named styles obviously, and save as type OTT (template) 3. change document.txt content as needed 4. a2x --backend=odt --backend-opts="--base_doc=the_ott_file_from_step_2.ott" document.txt 5. document.odt is a zip package with the new document.txt content and the styles from step two 6. go to step 3 as needed 7. edit the ott from step 2 with libreoffice if styles need further adjustment and go to step 4 > >>> output than FOP offers, I'm just not convinced that the cure isn't worse >>> than the disease. >> >> Well, IMHO its getting towards that. As always the devil is in the >> details and, until we tried it, issues like the nested blocks were not >> visible. >> >> Now, this is an unthoughtout idea :) What about keeping a stack of >> nested blocks (well actually any nested element to be general) and >> allow it to be accessed via a system attribute say {parent: [n]} to >> access a particular parent (default immediate parent) and {has_parent: >> <element-name>} to look for a parent of that name somewhere up the >> tree and return its position. That allows things like: >> >> {{parent:}@example:the extra markup if immediate parent is example} or >> {{has_parent:example}?some more extra markup if example is somewhere a >> parent} >> > > The idea is probably sound but it's implementation would not be trivial, > it's not an itch that I would want to scratch :-) Told you it wasn't a thought through idea, I hadn't gotten to implementation yet :) > > Either it's been mooted before or I'm missing something: can you not > distinguish inner blocks by manually applying explicit AsciiDoc role > attributes in the AsciiDoc source? Probably would work, but having to label every nested entity manually is a significant increase in work required of users and its going to look rather less ascii. > > >>> >>> If this is the goal then wkhtmltopdf offers a much more straight-forward >>> solution >>> >>> (http://groups.google.com/group/asciidoc/browse_thread/thread/94196f780ca3ad46): >>> >>> - You only have to style once for HTML and PDF outputs. >>> - You style using familiar CSS stylesheets. >>> - You can use existing AsciiDoc themes. >>> - The wkhtmltopdf backend processor is fast, relatively light weight, and >>> doesn't require a GUI to work. >>> - wkhtmltopdf has pre-built binaries for both Windows and Linux. >> >> Yes, I tried it when you first posted it (with the asciidoc user guide), >> >> - I like the idea of CSS as the sole formatting language, at least one >> commercial docbook processor does this >> - As yet wkhtmltopdf isn't "book" quality so it can't replace >> dblatex/fop, the worst offences are: >> * page breaks inserted in random locations causing orphans and >> widows and splitting tables in the middle of rows > > This is a problem, it's discussed in the manual > (http://madalgo.au.dk/~jakobt/wkhtmltoxdoc/wkhtmltopdf-0.9.9-doc.html). I > applied the 'page-break-inside: avoid;' CSS property to tables with the > 0.11.0_rc1 static version and it worked, but it didn't work with row > elements (confirming the observations here > http://code.google.com/p/wkhtmltopdf/issues/detail?id=57). Still has the problem as per the issues (not surprisingly as they are not closed and don't appear to be immanent :) > > But don't forget you can use the AsciiDoc page break macro, it works with > wkhtmltopdf but is not quite the same > (http://www.methods.co.nz/asciidoc/userguide.html#_page_breaks). True if only I knew where the page breaks were > > >> * line wrapping didn't seem right >> * I had font size and rendering problems (that may be just me :) > > Are you saying that your results looked different from mine? Links seemed to render with bigger fonts than usual, maybe it can be CSSed down. > > >> * links in the document don't work > > Links worked fine for me, sounds like you used the non-static (reduced > functionality) version. No the bz2 file is 11.0_rc1-static and it generated a toc which is supposed to be the full version only. To be clear neither links to within the document or links to external documents worked but the toc links and the sidebar worked. > > >> - Unfortunately I suspect going through HTML loses too much >> information to easily fix all of these > > Given the effort being put into Webkit I would hope CSS paged media element > support would improve over time. I guess there's always going be a tradeoff: > to exercise fine-grain control over the output you need a language that > affords fine control which is the whole point of FOP/TeX/PostScript. Yes, as I said wkhtmltopdf isn't ready to replace these yet, maybe it can do an adequate job one day if someone puts the effort into webkit. I don't have a problem with the high quality toolchains except the difficulty of customising them, and as I said above at least one commercial renderer uses CSS for that purpose. But even CSS editing is difficult for pure document jockeys, their skillset is words not any form of programming. 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]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
