On Sat, 10 Dec 2011, Lex Trotman wrote:
On Sat, Dec 10, 2011 at 3:51 AM, Dag Wieers <[email protected]> wrote:
* How do we generate the styles ?
This is something that comes up from time to time, and the only solution I
have is to pre-add the styles that may never be used (to every theme). In
this case that means I have to provide styles for 2 to 5 column sections.
(I doubt 6 columns are really useful, 5 is already taking it far)
Agree, but I only suggest maximum 3 columns. Anyone who wants more
can add them themselves based on the birlliant documentation you are
going to write :).
Wishful thinking ;-)
* What would be the best construction to make this work ?
My idea was to do this:
[section,columns=2]
====
...
====
But maybe there is something better ? A section in ODF separates parts of
the text body and can contain everything that can be added to the body
itself. So titles, paragraphs, ...
In itself it's quite easy to do, but I wonder if this maps to existing
functionality in other output backends, and whether we can make a general
construction rather than implementing something myself (again).
What would we prefer in this case ?
IMHO it shouldn't be in asciidoc because no other backend supports it
in a non-toolchain dependent way:
a. dblatex specifies it in the latex class definitions which can't be
done from asciidoc
b. FOP specifies it in the XSL stylesheets which can't be done from asciidoc
How does FOP know which parts need columns ? Seems impossible to indicate
after AsciiDoc using XSL.
c. HTML specifies it in CSS3, the only way that *might* be able to be
done from asciidoc, but only for CSS3 compliant browsers.
Right, but for HTML output using columns may not be as desirable as for
PDF or print output. Still, it might be useful in some cases.
Two out of three current backend toolchains cannot support such markup.
Using this feature makes the document backend specific anyway so the
techniques such as passthrough of ODT or backend specific markup can
be used. Any technique that can be done in the backend and does not
require asciidoc support would be ok.
So what I propose is acceptable ? But documented outside the scope of
AsciiDoc so potentially implemented differently in another backend ? :-/
--
-- dag wieers, [email protected], http://dag.wieers.com/
-- dagit linux solutions, [email protected], http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
--
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.
