Nested paragraphs are not allowed in ODF

44 views
Skip to first unread message

Stuart Rackham

unread,
Nov 6, 2011, 10:28:14 PM11/6/11
to asci...@googlegroups.com
I don't understand what this issue
(https://github.com/dagwieers/asciidoc-odf/issues/18):

This:

.Sidebar
********
A sidebar block.
********

Generates this:

<text:p><draw:frame draw:style-name="sidebarblock" draw:name="frame"
text:anchor-type="paragraph" draw:z-index="0"><draw:text-box
fo:min-height="0mm"><text:p text:style-name="title">Sidebar</text:p>
<text:p>A sidebar block.</text:p>
</draw:text-box></draw:frame></text:p>

It contain a <text:p> nested in a <test:p> and it displays find in lowriter 3.3.2

So what am I missing?


Cheers, Stuart

Lex Trotman

unread,
Nov 6, 2011, 11:32:14 PM11/6/11
to asci...@googlegroups.com

Hi Stuart,

Nesting the inner <text:p> elements inside drawings is the solution
Dag came up with to allow the nesting and it works fine if everything
is default formatted like sidebar, but unless you manually mark the
embedded entities (as you suggested) there is no way of giving them a
style that depends on the fact that they are nested.

Where styles applied to HTML cascade and docbook has explicit
knowledge of the nesting, ODF has no way of applying a style to the
nested paragraphs other than explicitly. Neither styles applied to
the outer <text:p> nor the frame or text box affect the embedded
<text:p> (at least in our testing).

So if your nested text is to be a different style like verse is a
different colour, there is (so far) no way to do it. That has stopped
work on admonitions and the other example based blocks that have
different style text until we can find a way to do it. (ATM examples
are broke in odt.conf)

Cheers
Lex

PS Dag is also worried about outlawing some nesting, but I don't see
that as a problem.

>
> Cheers, Stuart
>
> --
> You received this message because you are subscribed to the Google Groups
> "asciidoc" group.
> To post to this group, send email to asci...@googlegroups.com.
> To unsubscribe from this group, send email to
> asciidoc+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/asciidoc?hl=en.
>
>

Lex Trotman

unread,
Nov 6, 2011, 11:34:08 PM11/6/11
to asci...@googlegroups.com
Pardon the serial post.

On Mon, Nov 7, 2011 at 3:32 PM, Lex Trotman <ele...@gmail.com> wrote:
> On Mon, Nov 7, 2011 at 2:28 PM, Stuart Rackham <srac...@gmail.com> wrote:
>> I don't understand what this issue
>> (https://github.com/dagwieers/asciidoc-odf/issues/18):
>>
>> This:
>>
>> .Sidebar
>> ********
>> A sidebar block.
>> ********
>>
>> Generates this:
>>
>> <text:p><draw:frame draw:style-name="sidebarblock" draw:name="frame"
>> text:anchor-type="paragraph" draw:z-index="0"><draw:text-box
>> fo:min-height="0mm"><text:p text:style-name="title">Sidebar</text:p>
>> <text:p>A sidebar block.</text:p>
>> </draw:text-box></draw:frame></text:p>
>>
>> It contain a <text:p> nested in a <test:p> and it displays find in lowriter
>> 3.3.2
>>
>> So what am I missing?
>>
>
> Hi Stuart,
>
> Nesting the inner <text:p> elements inside drawings is the solution
> Dag came up with to allow the nesting and it works fine if everything
> is default formatted like sidebar, but unless you manually mark the
> embedded entities (as you suggested) there is no way of giving them a
> style that depends on the fact that they are nested.

Also should have said sidebar also needs the draw to set its
background and frame.

Stuart Rackham

unread,
Nov 7, 2011, 3:22:03 AM11/7/11
to asci...@googlegroups.com

Nope, sorry to be obtuse but I still don't get it.
These nested frames work:

.Sidebar
********
A sidebar block.

NOTE: Lorum ipsum.

********

So why don't you wrap nested blocks in draw:frames?

I think I need some real ODF markup examples along the lines:

from this AsciiDoc source: ...
this is what asciidoc generates naturally: ...
but this is what we need it to generate: ...


Cheers, Stuart

>
> Cheers
> Lex
>
> PS Dag is also worried about outlawing some nesting, but I don't see
> that as a problem.
>

j>>

Lex Trotman

unread,
Nov 7, 2011, 4:12:38 AM11/7/11
to asci...@googlegroups.com
[...]

> So why don't you wrap nested blocks in draw:frames?
>
> I think I need some real ODF markup examples along the lines:
>
> from this AsciiDoc source: ...
> this is what asciidoc generates naturally: ...
> but this is what we need it to generate: ...

Thats a good idea :)

Example input:

[quote]
____
para 1

para 2
____


normally asciidoc would generate:

<draw etc if needed, this doesn't matter for the current discussion>
<text:p>para 1</text:p>
<text:p>para 2</text:p>
</draw>

expecting the inner paras to inherit their style from somewhere else
eg, the HTML is

<div class="quoteblock">
<div class="content">
<div class="paragraph"><p>para 1</p></div>

<div class="paragraph"><p>para 2</p></div>

</div>

etc

and the inner paras inherit from the quoteblock classed div

for ODF the output for the two paras would need to be:

<draw etc again, this doesn't matter for the current discussion>
<text:p text:style-name="quoteblock">para 1</text:p>
<text:p text-style-name="quoteblock">para 2</text:p>
</draw>

Note the encapsulated markup of para 1 and para 2 have both been given
a style based on the fact that they are in an example, not manually in
the input. In ODF those nested paras will NOT inherit styles from
anything outside themselves, they have to be explicitly styled.

Your last example applied the note: manually in the input, thats why it worked.

Sidebars seem to work because they don't try to change the default
style of the nested paras, but as I said last time, if you wanted to,
you couldn't change it except manually as you did with the note.

At the moment odt.conf doesn't do anything legal or useful for this
case because we don't know how to do it.

Cheers
Lex

Lex Trotman

unread,
Nov 7, 2011, 4:15:28 AM11/7/11
to asci...@googlegroups.com
[...]
[...]

> Note the encapsulated markup of para 1 and para 2 have both been given
> a style based on the fact that they are in an example, not manually in

I mean in a quote, been worrying about example too much :)

> the input.  In ODF those nested paras will NOT inherit styles from
> anything outside themselves, they have to be explicitly styled.
>

[...]

Stuart Rackham

unread,
Nov 7, 2011, 3:20:00 PM11/7/11
to asci...@googlegroups.com

Thanks for the explanatin Lex, the fog is starting to clear :-)
Would something as simple as a {blockname} attribute set to the name of the
current block ('quote', 'paragraph', 'example', 'sidebar' etc) work?
You could then do:

<text:p text:style-name="{blockname}block">para 1</text:p>

Cheers, Stuart

Stuart Rackham

unread,
Nov 7, 2011, 4:18:51 PM11/7/11
to asci...@googlegroups.com

Setting {blockname} to the CSS class names currently used in xhtml11 and html5
would be more consistent, the {blockname} could then replace the hardwired class
names in xhtml11 and html5 conf files.

Lex Trotman

unread,
Nov 7, 2011, 4:44:33 PM11/7/11
to asci...@googlegroups.com
[...]

>> Thanks for the explanatin Lex, the fog is starting to clear :-)
>> Would something as simple as a {blockname} attribute set to the name of
>> the
>> current block ('quote', 'paragraph', 'example', 'sidebar' etc) work?
>> You could then do:
>>
>> <text:p text:style-name="{blockname}block">para 1</text:p>
>>
>> Cheers, Stuart
>>
>
> Setting {blockname} to the CSS class names currently used in xhtml11 and
> html5
> would be more consistent, the {blockname} could then replace the hardwired
> class
> names in xhtml11 and html5 conf files.
>

This will allow a single nesting block only, but thats similar to the
limitations of docbook. I'd say it is ok for version one.

Thinking about the configuration file entry for paragraph, the logic
of the style part needs to be:

if user specified a [style] then
text:style-name={style}
else if {blockname} then
text:style-name={blockname}
else nothing

the first part is clearly {style? text:style-name="{style}"} but how
do I do the elseif part, ie test one attribute not defined and one is
defined? IIUC you can't nest conditional attributes.

Cheers
Lex

Stuart Rackham

unread,
Nov 7, 2011, 5:22:02 PM11/7/11
to asci...@googlegroups.com

On 08/11/11 10:44, Lex Trotman wrote:
> [...]
>>> Thanks for the explanatin Lex, the fog is starting to clear :-)
>>> Would something as simple as a {blockname} attribute set to the name of
>>> the
>>> current block ('quote', 'paragraph', 'example', 'sidebar' etc) work?
>>> You could then do:
>>>
>>> <text:p text:style-name="{blockname}block">para 1</text:p>
>>>
>>> Cheers, Stuart
>>>
>>
>> Setting {blockname} to the CSS class names currently used in xhtml11 and
>> html5
>> would be more consistent, the {blockname} could then replace the hardwired
>> class
>> names in xhtml11 and html5 conf files.
>>
>
> This will allow a single nesting block only, but thats similar to the
> limitations of docbook. I'd say it is ok for version one.

Would my previous {blockpath} suggestion help here?

http://groups.google.com/group/asciidoc/browse_thread/thread/843d7d3d671006fb/5f3b864bc3a36286?lnk=gst&q=blockpath#5f3b864bc3a36286

>
> Thinking about the configuration file entry for paragraph, the logic
> of the style part needs to be:
>
> if user specified a [style] then
> text:style-name={style}
> else if {blockname} then
> text:style-name={blockname}
> else nothing
>
> the first part is clearly {style? text:style-name="{style}"} but how
> do I do the elseif part, ie test one attribute not defined and one is
> defined? IIUC you can't nest conditional attributes.

Do you mean the 'role' (1st positional) block attribute?
e.g. this listing:

[source,c]
--------------------------------------
#include <stdio.h>
--------------------------------------

Has a blockname of 'listingblock' and the role is 'source'

So would it make sense to set 3 global attributes?

{blockclass} = 'listingblock'
{blockrole} = 'source'
{blockname} = 'source-listingblock'

Similarly for other roled blocks/paragraphs: verse, quote, literal


Cheers, Stuart

Lex Trotman

unread,
Nov 7, 2011, 5:51:17 PM11/7/11
to asci...@googlegroups.com
On Tue, Nov 8, 2011 at 9:22 AM, Stuart Rackham <srac...@gmail.com> wrote:
>
>
> On 08/11/11 10:44, Lex Trotman wrote:
>>
>> [...]
>>>>
>>>> Thanks for the explanatin Lex, the fog is starting to clear :-)
>>>> Would something as simple as a {blockname} attribute set to the name of
>>>> the
>>>> current block ('quote', 'paragraph', 'example', 'sidebar' etc) work?
>>>> You could then do:
>>>>
>>>> <text:p text:style-name="{blockname}block">para 1</text:p>
>>>>
>>>> Cheers, Stuart
>>>>
>>>
>>> Setting {blockname} to the CSS class names currently used in xhtml11 and
>>> html5
>>> would be more consistent, the {blockname} could then replace the
>>> hardwired
>>> class
>>> names in xhtml11 and html5 conf files.
>>>
>>
>> This will allow a single nesting block only, but thats similar to the
>> limitations of docbook.  I'd say it is ok for version one.
>
> Would my previous {blockpath} suggestion help here?
>
> http://groups.google.com/group/asciidoc/browse_thread/thread/843d7d3d671006fb/5f3b864bc3a36286?lnk=gst&q=blockpath#5f3b864bc3a36286

Yes, perhaps.

>
>>
>> Thinking about the configuration file entry for paragraph, the logic
>> of the style part needs to be:
>>
>> if user specified a [style] then
>>     text:style-name={style}
>> else if {blockname}  then
>>     text:style-name={blockname}
>> else nothing
>>
>> the first part is clearly {style? text:style-name="{style}"}  but how
>> do I do the elseif part, ie test one attribute not defined and one is
>> defined?  IIUC you can't nest conditional attributes.
>
> Do you mean the 'role' (1st positional) block attribute?
> e.g. this listing:
>
> [source,c]
> --------------------------------------
> #include <stdio.h>
> --------------------------------------
>
> Has a blockname of 'listingblock' and the role is 'source'
>

That wasn't what I was thinking about, but it is another factor,
especially as admonitions are example blocks with [NOTE] [IMPORTANT]
etc

> So would it make sense to set 3 global attributes?
>
> {blockclass} = 'listingblock'
> {blockrole} = 'source'
> {blockname} = 'source-listingblock'
>
> Similarly for other roled blocks/paragraphs: verse, quote, literal
>

Possibly, I was thinking of source

................................
[quote]
____
para 1

[some-non-standard-style]
para 2
____

[some-other-style]
and a para that is not nested

and a final para without styles
.................................

Since all the paragraphs go through the one paragraph backend template
it has to use the explicit style (role in docbook) else blockclass
else nothing giving the paragraph elements (ignoring all enclosing
stuff)

<text:p text:style-name="paragraph-quoteblock">para 1</text:p>

<text:p text:style-name="some-non-standard-style">para 2</text:p>

<text:p text:style-name="some-other-style">and a para that is not
nested</text:p>

<text:p>and a final para without styles</text:p>

so what does the backend paragraph template look like?

Cheers
Lex

Stuart Rackham

unread,
Nov 7, 2011, 7:37:14 PM11/7/11
to asci...@googlegroups.com

This will work:

{style}
{style%}{block}


>> Do you mean the 'role' (1st positional) block attribute?
>> e.g. this listing:
>>
>> [source,c]
>> --------------------------------------
>> #include<stdio.h>
>> --------------------------------------
>>
>> Has a blockname of 'listingblock' and the role is 'source'
>>
>
> That wasn't what I was thinking about, but it is another factor,
> especially as admonitions are example blocks with [NOTE] [IMPORTANT]
> etc
>
>> So would it make sense to set 3 global attributes?
>>
>> {blockclass} = 'listingblock'
>> {blockrole} = 'source'
>> {blockname} = 'source-listingblock'
>>
>> Similarly for other roled blocks/paragraphs: verse, quote, literal
>>
>
> Possibly, I was thinking of source

Sorry I was confusing role and style attributes, replace 'role' with 'style' in
above.


>
> ................................
> [quote]
> ____
> para 1
>
> [some-non-standard-style]
> para 2
> ____
>
> [some-other-style]
> and a para that is not nested
>
> and a final para without styles
> .................................
>
> Since all the paragraphs go through the one paragraph backend template
> it has to use the explicit style (role in docbook) else blockclass
> else nothing giving the paragraph elements (ignoring all enclosing
> stuff)
>
> <text:p text:style-name="paragraph-quoteblock">para 1</text:p>
>
> <text:p text:style-name="some-non-standard-style">para 2</text:p>
>
> <text:p text:style-name="some-other-style">and a para that is not
> nested</text:p>
>
> <text:p>and a final para without styles</text:p>
>
> so what does the backend paragraph template look like?

<text:p text:style-name="{style=}{style!{blockname}-paragraph}">
|
</text:p>

The {blockname} would need to default to 'default' for the outer non-block
level. This will give us the following styles:

8<-----------------------
[quote]
____
para 1 // quoteblock-paragraph

[some-non-standard-style]
para 2 // some-non-standard-style
____

[some-other-style]
and a para that is not nested // some-other-style

and a final para without styles // default-paragraph
8<-----------------------


Cheers, Stuart


>
> Cheers
> Lex
>

Lex Trotman

unread,
Nov 7, 2011, 7:57:19 PM11/7/11
to asci...@googlegroups.com
[...]

> This will work:
>
> {style}
> {style%}{block}
>

Of course, I have gotten out of the habit of thnking about multi-line
solutions because odf converts newlines to whitespace, but inside tags
it shouldn't matter.

>
[...]


>> so what does the backend paragraph template look like?
>
> <text:p text:style-name="{style=}{style!{blockname}-paragraph}">
> |
> </text:p>
>
> The {blockname} would need to default to 'default' for the outer non-block
> level. This will give us the following styles:
>
> 8<-----------------------
> [quote]
> ____
> para 1                            // quoteblock-paragraph
>
> [some-non-standard-style]
> para 2                            // some-non-standard-style
> ____
>
> [some-other-style]
> and a para that is not nested     // some-other-style
>
> and a final para without styles   // default-paragraph
> 8<-----------------------
>

Well, I was trying to pick up the default text style if something is
unmarked, but I suppose if there is no way other than having an
explicit default then we will have to. We will have to be careful to
apply it to anything else where it is needed though.

My head hurts from thinking about it, so I guess this needs to be
tried out in real life now :)

Cheers
Lex

>
> Cheers, Stuart
>
>
>>
>> Cheers
>> Lex
>>
>

Stuart Rackham

unread,
Nov 7, 2011, 8:20:52 PM11/7/11
to asci...@googlegroups.com

Here we go, insignificant whitespace to the rescue:

<text:p
text:style-name="{style}"
text:style-name="{style%}{blockname}-paragraph"
>
|
</text:p>


>
> My head hurts from thinking about it, so I guess this needs to be
> tried out in real life now :)

One {blockname} attribute coming up!


Cheers, Stuart

Stuart Rackham

unread,
Nov 8, 2011, 3:35:35 AM11/8/11
to asci...@googlegroups.com
I've added global 'blockname' attribute that is dynamically updated to the
current block short name. Applies to delimited blocks, lists and
tables.

http://code.google.com/p/asciidoc/source/detail?r=08d77b0075c5a4075d3167850afc4b3a41cc6fdd

To see what's going on run asciidoc with a block trace e.g.

asciidoc -a trace=block t.txt

The ``short name'' is the text following the last dash in the conf
file definition section name e.g. the quote delimited block is defined
in the [blockdef-quote] section so the short name is 'quote'. The
short name for tables is 'table'.

So hopefully templates like:

<text:p
text:style-name="{style}"
text:style-name="{style%}{blockname}-paragraph"
>
|
</text:p>

will work.


Cheers, Stuart


On 08/11/11 13:57, Lex Trotman wrote:

Lex Trotman

unread,
Nov 9, 2011, 8:47:18 PM11/9/11
to asci...@googlegroups.com
Hi Stuart,

Testing has shown two problems as below, source and the newsworthy
part of the output attached (gazillion style defs left off :).

On Tue, Nov 8, 2011 at 7:35 PM, Stuart Rackham <srac...@gmail.com> wrote:
> I've added global 'blockname' attribute that is dynamically updated to the
> current block short name. Applies to delimited blocks, lists and
> tables.
>

It needs to be the containing template, not the blockdef. Otherwise
we have no way of differentiating between examples and admonitions as
far as I can see. That means that admonition paragraphs are styled as
example not admonition.

If it used the template it would work, eg for [exampleblock]
{blockname} becomes "example", for [admonitionblock] it becomes
"admonition" etc.

Or some other method of differentiating of course :)


> http://code.google.com/p/asciidoc/source/detail?r=08d77b0075c5a4075d3167850afc4b3a41cc6fdd
>
> To see what's going on run asciidoc with a block trace e.g.
>
>  asciidoc -a trace=block t.txt
>
> The ``short name'' is the text following the last dash in the conf
> file definition section name e.g. the quote delimited block is defined
> in the [blockdef-quote] section so the short name is 'quote'. The
> short name for tables is 'table'.
>
> So hopefully templates like:
>
> <text:p
> text:style-name="{style}"
> text:style-name="{style%}{blockname}-paragraph"
>>
> |
> </text:p>
>

For paragraphs {style} is always defined to be "normal", never
undefined, so the above doesn't work. This does,

<text:p
text:style-name="{style$normal::{style}}"
text:style-name="{style$normal:}{blockname}-paragraph"
>|</text:p>

but doing regex checks twice on every para in a long document is kinda
expensive. Any thoughts.

Cheers
Lex

test.txt
output

Stuart Rackham

unread,
Nov 10, 2011, 3:09:01 AM11/10/11
to asci...@googlegroups.com

On 10/11/11 14:47, Lex Trotman wrote:
> Hi Stuart,
>
> Testing has shown two problems as below, source and the newsworthy
> part of the output attached (gazillion style defs left off :).
>
> On Tue, Nov 8, 2011 at 7:35 PM, Stuart Rackham<srac...@gmail.com> wrote:
>> I've added global 'blockname' attribute that is dynamically updated to the
>> current block short name. Applies to delimited blocks, lists and
>> tables.
>>
>
> It needs to be the containing template, not the blockdef. Otherwise
> we have no way of differentiating between examples and admonitions as
> far as I can see. That means that admonition paragraphs are styled as
> example not admonition.
>
> If it used the template it would work, eg for [exampleblock]
> {blockname} becomes "example", for [admonitionblock] it becomes
> "admonition" etc.
>
> Or some other method of differentiating of course :)

Hi Lex

OK, I've switched to using the block 'name' attribute (an obscure block
definition attribute hitherto only used in admonition styles). The output is
more fine-grained (e.g. you get 'note', 'tip', 'important', 'warning', 'caution'
in place of 'admonitionblock' template name).

Has the advantage of being able to be customized by the configuration file
author without affecting the template section name interdependencies.

I've got a couple of couple of things to tidy up but it seems to work, question
is will is solve the problem?

http://code.google.com/p/asciidoc/source/detail?r=136237afe5242216c2d567f57ddca2fb6cab1213


>
>
>> http://code.google.com/p/asciidoc/source/detail?r=08d77b0075c5a4075d3167850afc4b3a41cc6fdd
>>
>> To see what's going on run asciidoc with a block trace e.g.
>>
>> asciidoc -a trace=block t.txt
>>
>> The ``short name'' is the text following the last dash in the conf
>> file definition section name e.g. the quote delimited block is defined
>> in the [blockdef-quote] section so the short name is 'quote'. The
>> short name for tables is 'table'.
>>
>> So hopefully templates like:
>>
>> <text:p
>> text:style-name="{style}"
>> text:style-name="{style%}{blockname}-paragraph"
>>>
>> |
>> </text:p>
>>
>
> For paragraphs {style} is always defined to be "normal", never
> undefined, so the above doesn't work. This does,
>
> <text:p
> text:style-name="{style$normal::{style}}"
> text:style-name="{style$normal:}{blockname}-paragraph"
>> |</text:p>
>
> but doing regex checks twice on every para in a long document is kinda
> expensive. Any thoughts.

I'll have a think about this tomorrow.


Cheers, Stuart

>
> Cheers
> Lex
>

Lex Trotman

unread,
Nov 10, 2011, 3:39:28 AM11/10/11
to asci...@googlegroups.com

As I understand it, I think it will.

The expansion of names will probably cause a proliferation of ODT
styles, but hopefully that will just be one referring to another or
worst case a bunch of boring cut and paste, Dag is the ODT style
expert.


Cheers
Lex

>
>
>>
>>
>>>
>>> http://code.google.com/p/asciidoc/source/detail?r=08d77b0075c5a4075d3167850afc4b3a41cc6fdd
>>>
>>> To see what's going on run asciidoc with a block trace e.g.
>>>
>>>  asciidoc -a trace=block t.txt
>>>
>>> The ``short name'' is the text following the last dash in the conf
>>> file definition section name e.g. the quote delimited block is defined
>>> in the [blockdef-quote] section so the short name is 'quote'. The
>>> short name for tables is 'table'.
>>>
>>> So hopefully templates like:
>>>
>>> <text:p
>>> text:style-name="{style}"
>>> text:style-name="{style%}{blockname}-paragraph"
>>>>
>>> |
>>> </text:p>
>>>
>>
>> For paragraphs {style} is always defined to be "normal", never
>> undefined, so the above doesn't work.  This does,
>>
>> <text:p
>> text:style-name="{style$normal::{style}}"
>> text:style-name="{style$normal:}{blockname}-paragraph"
>>>
>>> |</text:p>
>>
>> but doing regex checks twice on every para in a long document is kinda
>> expensive.  Any thoughts.
>
> I'll have a think about this tomorrow.
>
>
> Cheers, Stuart
>
>>
>> Cheers
>> Lex
>>
>

Stuart Rackham

unread,
Nov 10, 2011, 8:41:50 PM11/10/11
to asci...@googlegroups.com

I've tidied up and documented the {blockname} code:
http://code.google.com/p/asciidoc/source/detail?r=9ff0270a0b796a57e7a4b3d5ed4b9fd0fdab46a2

The trace names have changed to 'push' and 'pop' e.g.

asciidoc -a trace=push t.txt


>
> Cheers
> Lex
>
>>
>>
>>>
>>>
>>>>
>>>> http://code.google.com/p/asciidoc/source/detail?r=08d77b0075c5a4075d3167850afc4b3a41cc6fdd
>>>>
>>>> To see what's going on run asciidoc with a block trace e.g.
>>>>
>>>> asciidoc -a trace=block t.txt
>>>>
>>>> The ``short name'' is the text following the last dash in the conf
>>>> file definition section name e.g. the quote delimited block is defined
>>>> in the [blockdef-quote] section so the short name is 'quote'. The
>>>> short name for tables is 'table'.
>>>>
>>>> So hopefully templates like:
>>>>
>>>> <text:p
>>>> text:style-name="{style}"
>>>> text:style-name="{style%}{blockname}-paragraph"
>>>>>
>>>> |
>>>> </text:p>
>>>>
>>>
>>> For paragraphs {style} is always defined to be "normal", never
>>> undefined, so the above doesn't work. This does,
>>>
>>> <text:p
>>> text:style-name="{style$normal::{style}}"
>>> text:style-name="{style$normal:}{blockname}-paragraph"
>>>>
>>>> |</text:p>
>>>
>>> but doing regex checks twice on every para in a long document is kinda
>>> expensive. Any thoughts.
>>
>> I'll have a think about this tomorrow.

I haven't been able to come up with an easy way round this, probably not going
to impact performance, if it does I'll take another look.


Cheers, Stuart

Stuart Rackham

unread,
Nov 10, 2011, 9:41:33 PM11/10/11
to asci...@googlegroups.com
Hi Lex

Is the {blockname} required to generate ODF list outputs? If yes does the naming
have to be so fine-grained, if not I'll drop it for lists till a real use-case
arises.

Cheers, Stuart


On 10/11/11 21:39, Lex Trotman wrote:

Lex Trotman

unread,
Nov 11, 2011, 4:03:37 PM11/11/11
to asci...@googlegroups.com
On Fri, Nov 11, 2011 at 1:41 PM, Stuart Rackham <srac...@gmail.com> wrote:
> Hi Lex
>
> Is the {blockname} required to generate ODF list outputs? If yes does the
> naming have to be so fine-grained, if not I'll drop it for lists till a real
> use-case arises.

Hi Stuart,

I didn't try it yet, but I think yes it is needed. If lists can be
nested in examples and admonitions then we need the distinction I'm
afraid, since the styles are different.

Since we have to define styles for allowed nestings they are going to
be a defined set, deciding which they should be will be the trick.
Luckily styles can inherit (explicitly) so we don't have to repeat the
unchanged contents.

Cheers
Lex

Stuart Rackham

unread,
Nov 11, 2011, 4:29:39 PM11/11/11
to asci...@googlegroups.com

On 12/11/11 10:03, Lex Trotman wrote:
> On Fri, Nov 11, 2011 at 1:41 PM, Stuart Rackham<srac...@gmail.com> wrote:
>> Hi Lex
>>
>> Is the {blockname} required to generate ODF list outputs? If yes does the
>> naming have to be so fine-grained, if not I'll drop it for lists till a real
>> use-case arises.
>
> Hi Stuart,
>
> I didn't try it yet, but I think yes it is needed. If lists can be
> nested in examples and admonitions then we need the distinction I'm
> afraid, since the styles are different.
>
> Since we have to define styles for allowed nestings they are going to
> be a defined set, deciding which they should be will be the trick.
> Luckily styles can inherit (explicitly) so we don't have to repeat the
> unchanged contents.

Ok, will leave things as they are until we're road-blocked.

Cheers, Stuart

Reply all
Reply to author
Forward
0 new messages