On 05/11/11 09:38, Lex Trotman wrote:
On 5 November 2011 06:53, Stuart Rackham<[email protected]> wrote:
Hi Lex
Have I missed something with the "Preserve line-breaks and whitespaces in
listing blocks " issue?
No, my suggested solution was more replacement types so we could be
sure that we didn't interfere with uses of the existing replacement
types. So replacement3 sounds fine.
Apologies Lex, I didn't see that you had previously come up with exactly the
same suggestion, I should read the threads more carefully :-(
Have implemented your suggestion:
http://code.google.com/p/asciidoc/source/detail?r=05257f9b440922e8971a1e313df036b2d3a629c4
Putting this in the odt conf file should hopefully eliminate the need for the
line_break.py filter:
[miscellaneous]
subsverbatim=specialcharacters,callouts,replacements3
[replacements3]
(\n|$)=<text:line-break/>\n
\s=<text:s/>
At the moment I'm not doing things in strict reverse chronological order (as
I should), have been skirting around the hard stuff and going for the low
hanging fruit.
Sorry for being a bit unclear and non-specific, it was getting late.
The comment was a more based on the fact that at the moment we seem
to be stuck on how to "flatten" nested blocks since ODF doesn't
support them. For example, a para inside an example needs to become
just a para but with a style reflecting para-in-example, not para.
How that is solved I thought might affect how some of the other issues
can be addressed. And if it can't be solved it makes the other issues
somewhat moot.
I tried things like adding options to the [blcokdef-example] but they
don't seem to be available to the paragraph nested inside the example,
although http://www.methods.co.nz/asciidoc/userguide.html#X73 seems to
suggest they might be. And inspection of asciidoc.py doesn't show
where they are passed, so no surprise I guess.
So whether a general means of selecting a template based on context
was introduced or some other method is used is likely to change the
backedn conf arrangement.
OK I now think I understand the problem but I can't think of any easy way round
this.
The progress to date on the ODF backend is impressive, converting to ODF is a
complex business, what I'm not clear on though are the benefits. From what I've
read it seems to come down to finding a less complex way of styling PDF output
than FOP offers, I'm just not convinced that the cure isn't worse than the disease.
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.
Cheers, Stuart
BTW:
- I'm learning a lot from your responses on the ML, great stuff!
Hmmm, thats a worry :)
- Hope your HDD failure is behind you, got to be on my list of worst things
to wake up to.
Finally, part of the delay is taking the opportunity to find a new
Linux distro to use, and now putting the data on a raid array.
Restoring backups is a real pain.
- I don't ever want to sit through another nail biting ruby final like the
one we had a couple of weeks back thank you!
Yeah, good game.
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.
