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.
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 :-)
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?
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).
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).
* 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 in the document don't work
Links worked fine for me, sounds like you used the non-static (reduced
functionality) version.
- 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.
Cheers, Stuart
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.
