[new exporter] [html] Tables of Contents

[new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello,

The new exporter currently puts the generated Table of Contents at the
beginning of the exported document in addition to the location of 
"#+TOC: headlines".  I don't think it should insert it at the beginning
when it is called later.

However, I think the new exporter introduces disparities in the output
options that give us a chance to do something better.

In the new exporter, the type of generated Table of Contents depends on
two different configurations:

1. In the #+OPTIONS line, the toc: option determines whether to include
a TOC at the beginning, and how many levels /any/ TOC's should have.

2. The keyword #+TOC: can also be used to insert a generated TOC at a
specific location in the document.  This keyword allows options of
headlines, images, and listings, but it has no provision for levels.

Currently, using the OPTION toc:nil suppresses a default TOC.  Later on,
the #+TOC keyword is still recognized and acted upon, which I think is
the correct behavior, but then it includes all levels in the generated
TOC, because there no way to tell it otherwise.

IMHO, the #+OPTIONS line toc: option is unnecessary.  However, if used,
it should only provide the document default options for generated TOC's.

Instead, the #+TOC keyword should be changed to support the plist
structure that has been adopted elsewhere.  Thus, an example might be:

#+TOC: :type headlines :levels 2

Other options might be included, too, such as the option to suppress
dates or TODO states as Carsten requested, or perhaps even user-supplied
options, something like this:

#+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil
       :extra-function my-custom-toc-headline-processor

(In this example, the :title property means the "Table of Contents" at
the top of the TOC, not the title of the headline.)

I don't know how the current options (or these I've proposed) could be
designated in the OPTIONS line.  If we dropped support for the toc:
option in the OPTIONS line, people would have to insert the #+TOC:
keyword with its options where they wanted it.  Would that be so bad?

I was going to post a bug report saying that the initial generated TOC
should not be included if there was a following #+TOC line, but then I
couldn't answer what to do if the later TOC was only images or listings.
My proposal eliminates this problem.

All the best,
Terry
-- 
T.F. Torrey

Re: [new exporter] [html] Tables of Contents

[Nicolas Goaziou]

Hello,

tftorrey@tftorrey.com (T.F. Torrey) writes:

> The new exporter currently puts the generated Table of Contents at the
> beginning of the exported document in addition to the location of 
> "#+TOC: headlines".  I don't think it should insert it at the beginning
> when it is called later.

I think it should. There's no reason for it to go against user's will,
is there?

> However, I think the new exporter introduces disparities in the output
> options that give us a chance to do something better.
>
> In the new exporter, the type of generated Table of Contents depends on
> two different configurations:
>
> 1. In the #+OPTIONS line, the toc: option determines whether to include
> a TOC at the beginning, and how many levels /any/ TOC's should have.
>
> 2. The keyword #+TOC: can also be used to insert a generated TOC at a
> specific location in the document.  This keyword allows options of
> headlines, images, and listings, but it has no provision for levels.

Of course it has:

  #+TOC: headlines 2

It is documented in the manual.

> Currently, using the OPTION toc:nil suppresses a default TOC.  Later on,
> the #+TOC keyword is still recognized and acted upon, which I think is
> the correct behavior, but then it includes all levels in the generated
> TOC, because there no way to tell it otherwise.

See above.

> IMHO, the #+OPTIONS line toc: option is unnecessary.

If you remove it, you have no way to insert a table of contents in the
header anymore. It may be important for some back-ends.

> However, if used, it should only provide the document default options
> for generated TOC's.

> Instead, the #+TOC keyword should be changed to support the plist
> structure that has been adopted elsewhere.  Thus, an example might be:
>
> #+TOC: :type headlines :levels 2

Indeed. I have to change this. But I need to modify the parser for such
attributes first.

> Other options might be included, too, such as the option to suppress
> dates or TODO states as Carsten requested, or perhaps even user-supplied
> options, something like this:
>
> #+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil
>        :extra-function my-custom-toc-headline-processor
>
> (In this example, the :title property means the "Table of Contents" at
> the top of the TOC, not the title of the headline.)

Interesting. But that's some additional work for back-end developers.

> I don't know how the current options (or these I've proposed) could be
> designated in the OPTIONS line.

Some defcustom could be used. But we're not there yet.

> If we dropped support for the toc: option in the OPTIONS line, people
> would have to insert the #+TOC: keyword with its options where they
> wanted it. Would that be so bad?

Yes, see above.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> tftorrey@tftorrey.com (T.F. Torrey) writes:
>
>> The new exporter currently puts the generated Table of Contents at the
>> beginning of the exported document in addition to the location of 
>> "#+TOC: headlines".  I don't think it should insert it at the beginning
>> when it is called later.
>
> I think it should. There's no reason for it to go against user's will,
> is there?

With the old exporter, the OPTIONS toc: option controlled whether a TOC
was generated at all.  With toc:2 (for instance), if you had
"[TABLE-OF-CONTENTS]" somewhere in the document, it would put the TOC
there *instead* of at the top.  I favor the new behavior.

IIUC, your response means that what I proposed is already, mostly, the
way things are intended: that the OPTIONS: toc: directive already only
applies to the default settings and the TOC at the top.

One small problem, though: I see that if there is a TOC at the top and
then one included later using #+TOC, the exporter gives them both the
same id (<div id="table-of-contents">).  Duplicate ID's makes the XML
invalid.

>> However, I think the new exporter introduces disparities in the output

[... 10 lines omitted ...]

>> headlines, images, and listings, but it has no provision for levels.
>
> Of course it has:
>
>   #+TOC: headlines 2
>
> It is documented in the manual.

I didn't realize that this had been updated.  Thanks for the info.

[... 15 lines omitted ...]

>> Instead, the #+TOC keyword should be changed to support the plist
>> structure that has been adopted elsewhere.  Thus, an example might be:
>>
>> #+TOC: :type headlines :levels 2
>
> Indeed. I have to change this. But I need to modify the parser for such
> attributes first.

I'm sure there is no hurry.

>> Other options might be included, too, such as the option to suppress
>> dates or TODO states as Carsten requested, or perhaps even user-supplied
>> options, something like this:
>>
>> #+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil
>>        :extra-function my-custom-toc-headline-processor
>>
>> (In this example, the :title property means the "Table of Contents" at
>> the top of the TOC, not the title of the headline.)
>
> Interesting. But that's some additional work for back-end developers.

They could ignore what they can't or don't want to use, of course.

>> I don't know how the current options (or these I've proposed) could be
>> designated in the OPTIONS line.
>
> Some defcustom could be used. But we're not there yet.

This approach seems obtuse and perhaps over-engineered to me, but I'll
let it go.

The new TOC design solves a thorny problem I had with the old exporter.
Thanks a lot!

Best regards,
Terry
-- 
T.F. Torrey

Re: [new exporter] [html] Tables of Contents

[Nicolas Goaziou]

Hello,

tftorrey@tftorrey.com (T.F. Torrey) writes:

> One small problem, though: I see that if there is a TOC at the top and
> then one included later using #+TOC, the exporter gives them both the
> same id (<div id="table-of-contents">).  Duplicate ID's makes the XML
> invalid.

What do you suggest instead? id="table-of-contents-1" for the first
#+TOC: keyword and so on?


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] [html] Tables of Contents

[T.F. Torrey]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> tftorrey@tftorrey.com (T.F. Torrey) writes:
>
>> One small problem, though: I see that if there is a TOC at the top and
>> then one included later using #+TOC, the exporter gives them both the
>> same id (<div id="table-of-contents">).  Duplicate ID's makes the XML
>> invalid.
>
> What do you suggest instead? id="table-of-contents-1" for the first
> #+TOC: keyword and so on?
>
>
> Regards,

If I were implementing this with abundant resources, I'd probably opt
for a schema of base-type[-levels][-sequence], with these definitions:

- base :: probably "toc" to group and identify these id's
- type :: "headlines", "images", or other current or future types
- level :: depth of map, if it makes sense for the type
- sequence :: if necessary, the number of the copy of this configuration
  in this document

This schema would produce id's such as these:

- toc-headlines-1 :: lone instance of toc/headlines/one level
- toc-headlines-2 :: lone instance of toc/headlines/two levels
- toc-headlines-2-2 :: second instance of toc/headlines/two levels
- toc-images :: lone instance of toc/images (do levels make sense?)
- toc-tables :: first instance of list of tables
- toc-tables-2 :: second instance of list of tables

You get the idea.

This gives a significant advantage in that authors can link to the
various instances just by knowing their own usage.  For instance, if
they provided a top-level toc at the beginning of their book, and a
deeper-level toc later on, they could link to each separately by id by
knowing this plan.

Another idea for achieving the same linkability without the plan, would
be to support assigning an id in the plist (that isn't implemented yet),
such as "#+TOC: :type headlines :levels 2 :id toc-headlines-2".  With
this power would come the responsibility for the users to make sure id's
were not duplicated.

As a minimum, your suggestion ("table-of-contents-1", etc.) would be
reasonable for most use cases, and it's the shortest route to valid XML.

Some users of Org are producing complex documents that will probably be
active users of multiple toc types.  I'm curious what kind of schema
would work best for their use cases.

Best regards,
Terry
-- 
T.F. Torrey

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

Torrey

>>> One small problem, though: I see that if there is a TOC at the top and
>>> then one included later using #+TOC, the exporter gives them both the
>>> same id (<div id="table-of-contents">).  Duplicate ID's makes the XML
>>> invalid.
>>
>> What do you suggest instead? id="table-of-contents-1" for the first
>> #+TOC: keyword and so on?

Why do you need two table of contents?

> This gives a significant advantage in that authors can link to the
> various instances just by knowing their own usage.  For instance, if
> they provided a top-level toc at the beginning of their book, and a
> deeper-level toc later on, they could link to each separately by id by
> knowing this plan.

This seems like a valid use-case.  

I would recommend that you just specify just the use-case and leave out
the "how"s of implementation.

Put your user hat and set aside the developer's hat.
-- 

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

>> This gives a significant advantage in that authors can link to the
>> various instances just by knowing their own usage.  For instance, if
>> they provided a top-level toc at the beginning of their book, and a
>> deeper-level toc later on, they could link to each separately by id by
>> knowing this plan.
>
> This seems like a valid use-case.  

Brainstorimg here: Why not export a subtree (with displaced section
numbers) and splice the exported strings together to produce the
compelete document.

Subtree export of headline 1, but with section numbers starting at 1.
Subtree export of headline 2, but with section numbers starting at 2.
Splice them together.

----------------------------------------------------------------

There are books where each chapter could be written by different
authors.  The chapters are later spliced together to produce the master
document.  In case of OpenDocument, such files have *.odm extension.  I
can look up what the OpenDocument spec says or LibreOffice does.

----------------------------------------------------------------

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

>>> This gives a significant advantage in that authors can link to the
>>> various instances just by knowing their own usage.  For instance, if
>>> they provided a top-level toc at the beginning of their book, and a
>>> deeper-level toc later on, they could link to each separately by id by
>>> knowing this plan.
>>
>> This seems like a valid use-case.  
>
> Brainstorimg here: Why not export a subtree (with displaced section
> numbers) and splice the exported strings together to produce the
> compelete document.
>
> Subtree export of headline 1, but with section numbers starting at 1.
> Subtree export of headline 2, but with section numbers starting at 2.
> Splice them together.

Considering that HTML exporter can export a subtree, I believe you can
do some XSLT magic so that the individual HTML generated by Org is
transformed before being spliced.

Do you really want this to be supported within the scope of the Org
exporter?  Are you sure you have explored all the tricks in your bag
before raising this request.  Just wanted to confirm, because you seem
to be the HTML expert among the three of us...

> ----------------------------------------------------------------
>
> There are books where each chapter could be written by different
> authors.  The chapters are later spliced together to produce the master
> document.  In case of OpenDocument, such files have *.odm extension.  I
> can look up what the OpenDocument spec says or LibreOffice does.
>
> ----------------------------------------------------------------

Or

Allow a subtree to take EXPORT_TOC property.  (There should be a way to
specifiy where this TOC will end up in - beginning of that chapter or
end of the chapter)

Similarly, one could introduce EXPORT_ENDNOTES property whereby each
chapter can have it's own self-contained "End Notes section".

Re: [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:

[... 13 lines omitted ...]

>> Subtree export of headline 1, but with section numbers starting at 1.
>> Subtree export of headline 2, but with section numbers starting at 2.
>> Splice them together.
>
> Considering that HTML exporter can export a subtree, I believe you can
> do some XSLT magic so that the individual HTML generated by Org is
> transformed before being spliced.
>
> Do you really want this to be supported within the scope of the Org
> exporter?  Are you sure you have explored all the tricks in your bag
> before raising this request.  Just wanted to confirm, because you seem
> to be the HTML expert among the three of us...

I'm not sure we are talking about the same issues.  For one thing, you
are replying to yourself here.  I did not suggest this.  My request was
merely for valid XML ID's for tables of contents from the HTML exporter,
given that most of the XML tricks in my bag depend on valid XML input.

[... 11 lines omitted ...]

> Allow a subtree to take EXPORT_TOC property.  (There should be a way to
> specifiy where this TOC will end up in - beginning of that chapter or
> end of the chapter)
>
> Similarly, one could introduce EXPORT_ENDNOTES property whereby each
> chapter can have it's own self-contained "End Notes section".

I don't think these are related to my original concern, but they do
sound like interesting ideas that might be of use to me.  They also
sound like a lot of work.  Should this be taken up again after the 8.0
release?

Best regards,
Terry
-- 
T.F. Torrey

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

> My request was merely for valid XML ID's for tables of contents from
> the HTML exporter

I understand the request but I will not comment upon whether or not it
will be supported in the exporter because that would be Nicolas call.
He has to work out the details not only for HTML exporter but also for
other backends.  It will take time and you need to argue your case
convincingly. There are going to be questions stupid and intelligent
which you need to be willing to answer.

> given that most of the XML tricks in my bag depend on valid XML input.

Given the current limitation of HTML exporter and since you say that you
are comfortable with XSLT, I was merely asking whether or not you see
any problem with this.

   Final Document = Transform(Subtree-Export) + Transform(Subtree-export)

Each transformer can rewrite TOC IDs and you will valid HTML export.
You may or may not wish to answer my questions.

ps: I still think that duplicate TOCs was an error on your part, meaning
it was un-intentional.  Can you convince me that it was really
intentional.  HTML export is not intended for books and I still cannot
understand why two TOCs are needed.

Jambunathan K.

Re: [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Torrey
>
>>>> One small problem, though: I see that if there is a TOC at the top and
>>>> then one included later using #+TOC, the exporter gives them both the
>>>> same id (<div id="table-of-contents">).  Duplicate ID's makes the XML
>>>> invalid.
>>>
>>> What do you suggest instead? id="table-of-contents-1" for the first
>>> #+TOC: keyword and so on?
>
> Why do you need two table of contents?

I don't, though some might.  As was explained earlier in this thread, if
toc: options are set in the OPTIONS line, and a #+TOC is specified
later, two tables of contents are generated, and they have the same ID.
It is a feature of the new exporter, but duplicate ID's are not valid in
XML.

It is common for technical manuals to have a top-level table of contents
at the front of the manual and a detailed table of contents later on.
For instance, the GNU project Info manuals have that structure.

>> This gives a significant advantage in that authors can link to the
>> various instances just by knowing their own usage.  For instance, if
>> they provided a top-level toc at the beginning of their book, and a
>> deeper-level toc later on, they could link to each separately by id by
>> knowing this plan.
>
> This seems like a valid use-case.  
>
> I would recommend that you just specify just the use-case and leave out
> the "how"s of implementation.
>
> Put your user hat and set aside the developer's hat.

What a strange, semi-insulting thing to say.

And misguided, too, as I was suggesting a design, not its
implementation.  As someone with all my own documents in Org and
extensive experience developing XSLT and lisp to process the XHTML
output of Org, I appreciate when the design of the HTML output is
logical and useful.

I would rather see a good design implemented in hacks than a poor design
implemented in beautiful code.

Regards,
Terry
-- 
T.F. Torrey

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

tftorrey@tftorrey.com (T.F. Torrey) writes:

>>> This gives a significant advantage in that authors can link to the
>>> various instances just by knowing their own usage.  For instance, if
>>> they provided a top-level toc at the beginning of their book, and a
>>> deeper-level toc later on, they could link to each separately by id by
>>> knowing this plan.
>>
>> This seems like a valid use-case.  
>>
>> I would recommend that you just specify just the use-case and leave out
>> the "how"s of implementation.
>>
>> Put your user hat and set aside the developer's hat.
>
> What a strange, semi-insulting thing to say.

There is nothing strange in what I said.  I wasn't insulting.

> And misguided, too, as I was suggesting a design, not its
> implementation.  As someone with all my own documents in Org and
> extensive experience developing XSLT and lisp to process the XHTML
> output of Org, I appreciate when the design of the HTML output is
> logical and useful.

When you were suggesting 

        #+toc: :a b :b c :c d

that is implementation specifics and you were arguing from a HTML
standpoint.  If you were in fact designing, you would have articulated
your case for other backends and how your suggested changes would impact
ox.el.

> I would rather see a good design implemented in hacks than a poor design
> implemented in beautiful code.

If you have better ideas, show us the patch.  

Otherwise, I suggest that you wear your user hat and place the use-case
before use while others can take care of the details.

Re: [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

I admire your energy and coding skill, but I wish you would stop
occupying our time with replies like this.  Your tone is insulting, and
seems deliberately so, and none of this response is helpful to the
original thread.

I won't reply to more of your posts like this, so if you don't get a
reply, know that it's because your message was insulting and off-topic.
I'm only sending this on the odd chance that you are not aware of what
you are doing, in which case this might be helpful to you.

If you want to follow up to this message, I invite you to do so
off-list, where it might have been best for me to post this as well.

Best regards,
Terry

Jambunathan K <kjambunathan@gmail.com> writes:

> tftorrey@tftorrey.com (T.F. Torrey) writes:
>
>>>> This gives a significant advantage in that authors can link to the
>>>> various instances just by knowing their own usage.  For instance, if
>>>> they provided a top-level toc at the beginning of their book, and a
>>>> deeper-level toc later on, they could link to each separately by id by
>>>> knowing this plan.
>>>
>>> This seems like a valid use-case.  
>>>
>>> I would recommend that you just specify just the use-case and leave out
>>> the "how"s of implementation.
>>>
>>> Put your user hat and set aside the developer's hat.
>>
>> What a strange, semi-insulting thing to say.
>
> There is nothing strange in what I said.  I wasn't insulting.
>
>> And misguided, too, as I was suggesting a design, not its
>> implementation.  As someone with all my own documents in Org and
>> extensive experience developing XSLT and lisp to process the XHTML
>> output of Org, I appreciate when the design of the HTML output is
>> logical and useful.
>
> When you were suggesting 
>
>         #+toc: :a b :b c :c d
>
> that is implementation specifics and you were arguing from a HTML
> standpoint.  If you were in fact designing, you would have articulated
> your case for other backends and how your suggested changes would impact
> ox.el.
>
>> I would rather see a good design implemented in hacks than a poor design
>> implemented in beautiful code.
>
> If you have better ideas, show us the patch.  
>
> Otherwise, I suggest that you wear your user hat and place the use-case
> before use while others can take care of the details.

Re: [new exporter] [html] Tables of Contents

[Bastien]

Hello Jambunathan,

You are not welcome on this list anymore, please ban yourself.

Thanks,

-- 
 Bastien

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

Bastien <bzg@altern.org> writes:

> Hello Jambunathan,
>
> You are not welcome on this list anymore, please ban yourself.

I asked you to exercise moderator controls.  Why should I ban myself?

> Thanks,

Re: [new exporter] [html] Tables of Contents

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> Hello Jambunathan,
>>
>> You are not welcome on this list anymore, please ban yourself.
>
> I asked you to exercise moderator controls.  Why should I ban
> myself?

I am not a moderator of this list.  And I would not like moderators to
exercise their control on anybody on this list.  Why should they make
you a favor?  I suspect you would enjoy it.  So this is a "no".

I think staying away from this list would be good both for the list
and for you.  We could continue working without dealing with your
weird and sometimes insulting messages.  You could realize that what
you really want is to contribute to Org and Emacs, and that the best
way to achieve this is to amend your behavior, not to send patches.

There is a persistent myth among programmers: because some great
coders are plain jerks, we have a tendancy to believe jerks are often
great programmers.  But this is not the case.  And you are not a great
programmer, you are just an average one, good at some things, with
time at hand.

So step aside for a while, think about what you can learn from others,
and come back when you learned how to behave correctly.  This is much
harder to achieve than contributing code, it can take a lifetime.  A
high-hanging fruit, like the ones you love.

-- 
 Bastien

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

Bastien <bzg@altern.org> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Bastien <bzg@altern.org> writes:
>>
>>> Hello Jambunathan,
>>>
>>> You are not welcome on this list anymore, please ban yourself.
>>
>> I asked you to exercise moderator controls.  Why should I ban
>> myself?
>
> I am not a moderator of this list.  And I would not like moderators to
> exercise their control on anybody on this list.  Why should they make
> you a favor?  I suspect you would enjoy it.  So this is a "no".

Oh, Ok.  It looks like we are in a pissing contest.

Jambunathan K.

Re: [new exporter] [html] Tables of Contents

[Samuel Wales]

On 3/6/13, Bastien <bzg@altern.org> wrote:
> Hello Jambunathan,
>
> You are not welcome on this list anymore, please ban yourself.
>
> Thanks,

Thank you, Bastien.  This has been necessary since around May of 2011.
 How do we make it a reality NOW?

Samuel Wales

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  It attacks
MANY body systems.  ANYBODY can get it.  There is NO hope without
activist action.  This means YOU.

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

Samuel Wales <samologist@gmail.com> writes:

> On 3/6/13, Bastien <bzg@altern.org> wrote:
>> Hello Jambunathan,
>>
>> You are not welcome on this list anymore, please ban yourself.
>>
>> Thanks,
>
> Thank you, Bastien.  This has been necessary since around May of 2011.
>  How do we make it a reality NOW?

I said I want to be banned.  Let me suggest ways:

1. Quarantine my posts.

2. Remove ox-html.el (atleast the lines I have made substantial
   modifications to) and ox-odt.el from Org repo.

I will move the stuff to GNU ELPA and obsolete my work if a better
replacement comes along.  

ox-html.el and ox-odt.el is no rocket science, if Bastien or Samuel or
even a college intern sits for a day, I promise you they will do a
better job than I have done.

Don't talk, do.  

Write your own exporters and then ban me from the list.  Otherwise it is
just childish prant.  Removing me from the list, without disowning my
contributions is also ethically/morally reprehensible act which elders
will condemn (silently or vocally)

Bottomline: Who dares, wins.

>
> Samuel Wales

-- 

Re: [new exporter] [html] Tables of Contents

[Bastien]

Hi Samuel,

Samuel Wales <samologist@gmail.com> writes:

>  How do we make it a reality NOW?

No, I stated my reasons here:
http://article.gmane.org/gmane.emacs.orgmode/67829

-- 
 Bastien

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

Torrey

I don't mind being insulted publicly and in this mailing list.  I have
weathered even better insults both on and off the list.

So you are welcome.

Jambunathan K.

tftorrey@tftorrey.com (T.F. Torrey) writes:

> Hello Jambunathan,
>
> I admire your energy and coding skill, but I wish you would stop
> occupying our time with replies like this.  Your tone is insulting, and
> seems deliberately so, and none of this response is helpful to the
> original thread.
>
> I won't reply to more of your posts like this, so if you don't get a
> reply, know that it's because your message was insulting and off-topic.
> I'm only sending this on the odd chance that you are not aware of what
> you are doing, in which case this might be helpful to you.
>
> If you want to follow up to this message, I invite you to do so
> off-list, where it might have been best for me to post this as well.
>
> Best regards,
> Terry
>
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> tftorrey@tftorrey.com (T.F. Torrey) writes:
>>
>>>>> This gives a significant advantage in that authors can link to the
>>>>> various instances just by knowing their own usage.  For instance, if
>>>>> they provided a top-level toc at the beginning of their book, and a
>>>>> deeper-level toc later on, they could link to each separately by id by
>>>>> knowing this plan.
>>>>
>>>> This seems like a valid use-case.  
>>>>
>>>> I would recommend that you just specify just the use-case and leave out
>>>> the "how"s of implementation.
>>>>
>>>> Put your user hat and set aside the developer's hat.
>>>
>>> What a strange, semi-insulting thing to say.
>>
>> There is nothing strange in what I said.  I wasn't insulting.
>>
>>> And misguided, too, as I was suggesting a design, not its
>>> implementation.  As someone with all my own documents in Org and
>>> extensive experience developing XSLT and lisp to process the XHTML
>>> output of Org, I appreciate when the design of the HTML output is
>>> logical and useful.
>>
>> When you were suggesting 
>>
>>         #+toc: :a b :b c :c d
>>
>> that is implementation specifics and you were arguing from a HTML
>> standpoint.  If you were in fact designing, you would have articulated
>> your case for other backends and how your suggested changes would impact
>> ox.el.
>>
>>> I would rather see a good design implemented in hacks than a poor design
>>> implemented in beautiful code.
>>
>> If you have better ideas, show us the patch.  
>>
>> Otherwise, I suggest that you wear your user hat and place the use-case
>> before use while others can take care of the details.
>
>

-- 

Re: [new exporter] [html] Tables of Contents

[Jambunathan K]

tftorrey@tftorrey.com (T.F. Torrey) writes:

> extensive experience developing XSLT and lisp to process the XHTML
> output of Org,

Is there a way your specific problem could be solved if we were to use
CSS counters for numbering various things?  Would you like to submit a
patch to ox-html.el that uses CSS-based counters rather than counters
computed with hand.

ps: I don't know HTML or CSS.
-- 

Re: [new exporter] [html] Tables of Contents

[T.F. Torrey]

Hello Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Is there a way your specific problem could be solved if we were to use
> CSS counters for numbering various things?  Would you like to submit a
> patch to ox-html.el that uses CSS-based counters rather than counters
> computed with hand.

No.

I'm not sure I understand your motives here, but I think you would like
to make changes to ox-html.el that would address the bug report/feature
request I sent.  If so, read on.

The problem is that in situations where the HTML exporter produces two
tables of contents, it gives them both the same ID.  That makes the XML
invalid, breaks some linking, and tends to choke XSLT processors.

I suggested three different strategies for the ID:

1. A detailed schema (see original email)
2. Allowing user to designate the ID
3. Just adding a sequence number to the end

Of these,

1 would probably be the hardest to implement, but would
provide the most accessibility for users and post-processors.

2 would probably be the easiest to implement, but would have the problem
that users wouldn't know they had to do it until something didn't work.

3 is probably the easiest to implement, but with the lowest utility.

My personal choice would be for both 1 and 2 to be implemented, but as
I'm not doing the work, that might be too much to ask.  Just doing 3
would make the XML valid again (in these cases), and would be good
enough for now.

So, if you're looking to implement a solution, 1 and 2 please, or 3 if 1
and 2 are too much work right now.  If, on the other hand, you're just
trying to find a way to make my suggestions sound dumb, please see my
previous e-mail.

Best regards,
Terry
-- 
T.F. Torrey