Re: custom IDs not exported

[Nick Dokos <nicholas.dokos@hp.com>]

Sten Lindner <s.lindner@stenlindner.de> wrote:

> On Sat, Jun 11, 2011 at 11:12:26PM -0400, Nick Dokos wrote:
> > 
> > I have a minimal patch that I think fixes this problem, but there are
> > other underscores used in various places in org-html.el so there might
> > be additional problems. I'd appreciate it if you (and/or others) test it
> > and report not only on this problem but on any other problems you find.
> 
> I'm having the same problem when exporting to Docbook, custom IDs are
> being ignored.
> 
> For example, when I export some org-mode text using C-c C-e D:
> 
> * heading1
>   :PROPERTIES:
>   :CUSTOM_ID: h1
>   :END:
> 
> ** heading2
>   :PROPERTIES:
>   :CUSTOM_ID: h2
>   :END:
> 
> some links:
> - see [[#h1][heading1]]
> - see [[#h2][heading2]]
> 
> I' getting the following XML output:
> 
> <section xml:id="sec-1">
> <title>heading1 </title>
> <section xml:id="sec-1_1">
> <title>heading2 </title>
> <para>
> some links:
> </para>
> <itemizedlist>
> <listitem>
> <para>see <link linkend="h1">heading1</link>
> </para>
> </listitem>
> <listitem>
> <para>see <link linkend="h2">heading2</link>
> </para>
> </listitem>
> </itemizedlist>
> </section>
> </section>
> </article>
> 
> I would expect to see my custom IDs "H1" and "H2" but instead get
> auto-generated IDs "sec-1" and "sec-1_1".
> 
> I'm using the latest org-mode version 7.7.
> 
> best regards,
> Sten
> 
> -- 
> Sten Lindner
> 
> e-mail: s.lindner@stenlindner.de
>


This is because org-docbook.el does not implement custom ID handling at
all. I don't know if Baoqiu Cui, the author of org-docbook.el, watches
this list any longer (I haven't seen any mail from him for some time):
if he is around, he would be the logical person to fix it.  But if you
are interested in fixing this problem, I'd be happy to provide
guidance.[fn:1]

The problem is the following code in the function
org-export-docbook-level-start in lisp/org-docbook.el:

      ...
      (setq section-number (org-section-number level))
      (insert (format "\n<section xml:id=\"%s%s\">\n<title>%s</title>"
		      org-export-docbook-section-id-prefix
		      (replace-regexp-in-string "\\." "_" section-number)
      ...

As you can see, the xml id is formed from
org-export-docbook-section-id-prefix (which has the value "sec-") and
the section-number (which is "1" for the top level heading and "1.1" for
the second level heading). We replace periods with underscores in the
section number and then construct the id as "sec-1_1". But there is no
provision anywhere for translating to custom IDs.

So one necessary change in order to conform to the changed convention is
to replace periods with hyphens in the section number. But in addition
to that, the xml id will have to be constructed differently if there is
a custom ID around.

Custom ids are passed to this function through a (dynamically scoped)
variable called org-export-preferred-target-alist which in the case
below has the value

    (("sec-1-1" . "h2") ("sec-1" . "h1"))

This variable provides the translations from the standard to the custom
IDs.

org-html.el provides a template to follow in reorganizing the above code
to do the translation. If you look at org-html-level-start [fn:2],
you'll find the following code

	(setq href (cdr (assoc (concat "sec-" snu) org-export-preferred-target-alist)))
        ...
	(setq href (org-solidify-link-text (or href (concat "sec-" snu))))
	(insert (format "\n<div id=\"outline-container-%s\" class=\"outline-%d%s\">\n<h%d id=\"%s\">%s%s</h%d>\n<div class=\"outline-text-%d\" id=\"text-%s\">\n"
			suffix level (if extra-class (concat " " extra-class) "")
			level href
			extra-targets
			title level level suffix))

In this case, snu is the section number (with periods already replaced
by hyphens).  The local variable href is used to construct the id: the
conventional section number ("sec-1-1" e.g.) is looked up in the alist
and it is either found, in which case href is set to the translation
("h2") or it is not found, in which case href is set to nil. Then the
second setq sets it to either the translated value or, if that is nil,
to the conventional value ("sec-1-1"). That is then used to fill in the
id in the html code.

With this information, do you think you could get a patch together?
Let me know if you have questions.

Nick

Footnotes:

[fn:1] For legal reasons, I cannot fix it myself.

[fn:2] As an aside, note the inconsistency in the function names. Bastien,
       is this worth fixing?