On Sat, Dec 10, 2011 at 3:51 AM, Dag Wieers <[email protected]> wrote: > Hi, > > For one of my documents a long list of items spans multiple pages and makes > the document quite spacious. I would like to fix this by adding a > multi-column section that would stretch the list over these columns. > > The output in ODF looks like this for a 3 column section. > > Stylesheet > ---- > <style:style style:name="Sect1" style:family="section"> > <style:section-properties fo:background-color="transparent" > text:dont-balance-text-columns="false" style:editable="false"> > <style:columns fo:column-count="3" fo:column-gap="4.97mm"> > <style:column style:rel-width="3165*" fo:start-indent="0mm" > fo:end-indent="2.49mm"/> > <style:column style:rel-width="3307*" fo:start-indent="2.49mm" > fo:end-indent="2.49mm"/> > <style:column style:rel-width="3166*" fo:start-indent="2.49mm" > fo:end-indent="0mm"/> > </style:columns> > <style:background-image/> > </style:section-properties> > </style:style> > ---- > > Content > ---- > <text:section text:style-name="Sect1" text:name="Section1"> > ... > </text:section> > ---- > > The brings two problems to the table. > > > * 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 :). > > > * 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 ? Dag, 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 c. HTML specifies it in CSS3, the only way that *might* be able to be done from asciidoc, but only for CSS3 compliant browsers. 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. Cheers Lex > -- > -- 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. > -- 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.
