On 05/11/11 21:36, Lex Trotman wrote:
On 5 November 2011 16:34, Stuart Rackham<srack...@gmail.com> 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
Thanks for the explanation, I hadn't picked up on the significance of the .ott
file, the whole thing makes a lot more sense now.
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.
I'm not sure if I fully understand the nesting problem, but would this work: a
global attribute {blockpath} that updates automatically as you enter and exit
blocks e.g. as we move through a sidebar block containing a nested example block:
{blockpath} = ''
****
{blockpath} = 'sidebar'
====
{blockpath} = 'sidebar-example'
====
{blockpath} = 'sidebar'
****
{blockpath} = ''
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
I extended the 'unbreakable' block option to block elements in xhtml11 and html5
backends and added a couple of FAQs which will help a bit:
http://code.google.com/p/asciidoc/source/detail?r=91afe869b38f905e16c3b4f1ed164165f834a34d
* 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.
I rechecked and they do work for me.
Cheers, Stuart
- 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 asciidoc@googlegroups.com.
To unsubscribe from this group, send email to
asciidoc+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
