Can't use 2 subsections with the same name

My personal feeling is that this is rather a fop issue - duplicate id's should be ignored and not lead to a build failure. In principle I could work around that by enumerating identical id's, however, it would be impossible to resolve the ambiguity when two identical id's are referenced. For that reason I think it would be better to just document the issue.

Note that the issue only applies to id's within the same document, and that identical <a name="id"> tags lead to the same problem.

Also note that the xdoc plugin will generate identical id's for the example above as well.

certainly the same issue

Actually,your example above leads to an invalid HTML document, because according to the HTML 4.01 specs ( http://www.w3.org/TR/html4/struct/links.html#h-12.2.1 ), anchor names must be unique within one document.

You're right but the end user musn't know that a subsection name generates an id which must be unique. It's the plugin's problem to generate an unique id ? WDYT ?

Even if we would generate a unique id, it would be completely useless for the end user if he doesn't know how to reference it
(how would you link to your two subsections above from a different source document?). We would have to document and tell the user
how we generate the ids, but then we can also tell him to use unique ids in the first place.

The only alternative that I see is to abandon the id generation from section names completely and tell the user to use a unique <a name=""/> element for every
section he wants to reference. That would be the cleanest solution, but it would break compatibility with the xdoc plugin
and I would only support it if the same change would be made in the xdoc plugin.
(thinking about it, one should actually open the very same issue for the xdoc plugin, for the reason I stated above).

I agree that this needs to be fixed in xdoc first. I didn't see that anyone had yet reported it, so I opened a feature request to allow <section name="Some Long Description" href="desc"> to allow users to pick the anchor name they want.

See: http://jira.codehaus.org/browse/MPXDOC-159

This should do the job: I introduce an optional 'id' tag like I indicated in my original description for MPXDOC-158.
If this id tag is present, it will be used for referencing, if it is omitted, the 'name' tag will be used. Like that we stay compatible with xdoc (well, almost, links will behave differently, but that is an xdoc problem). We just have to document that for identical sub/section names, it is mandatory to specify unique id tags.

Note that this patch only fixes the problem of identical sub/sections, identical links in navigation.xml will still fail (but I don't think it is necessary to fix that).

I will submit an analogous patch for the xdoc plugin but the current patch can be applied independently of that.

Another idea to improve ids with the default naming is to generate them from the section/subsections tree.
For exemple :
<section name="A"> ==> Generates id="A"
<subsection name="B"> ==> Generates id="A_B"
<subsection name="C"> ==> Generates id="A_B_C"
</subsection>
</subsection>
<subsection name="D"> ==> Generates id="A_D"
</subsection>
</section>
I don't know if there's a maximum number of chars in an id.

In your example, a <section name="A B"> would generate the same id as the first subsection, so this is not fool proof.

My personal opinion is that the plugin should not auto-generate id's at all (except where they are only used internally, like for the table of contents, in which case the user does not need to know anything about it). The only raison d'etre for the id generation for sub/sections is to make it referencable for the user. If the user wants to reference a sub/section, he should provide an id himself.

Note that in the old version of the plugin, before my fix for MPPDF-24, ids for sub/sections were generated using xslt's generate-id() function, which gave a unique id in all cases. However, they were completely useless because they were re-generated dynamically at each build time and the user couldn't know how to reference them. I conclude that if you want to ensure unique ids, you would have to auto-generate them according to some algorithm, but in that case they are useless because they can't be referenced. If you want id's that the user can reference easily, there is no way to ensure they are unique.

I'd rather propose to remove the id generation from name tags altogether and keep the id tag as an option (that's how it should be in the xdoc plugin as well). Thus, we maintain backwards compatibility within the pdf plugin and avoid any build failures. The worst thing that can happen is that a link to a section does not work in the generated pdf if the user forgets to specify an id tag.

Reopen to change "fix for"