Maven 1.x PDF Plugin
  1. Maven 1.x PDF Plugin
  2. MPPDF-40

Can't use 2 subsections with the same name

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.3
    • Fix Version/s: 2.5
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      If 2 subsections have the same name the pdf generation fails because they have the same id.

      For exemple :
      <section name="Section 1">
      <subsection name="SubSection">
      </subsection>
      </section>
      <section name="Section2">
      <subsection name="SubSection">
      </subsection>
      </section>

        Issue Links

          Activity

          Hide
          Wendy Smoak added a comment -

          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

          Show
          Wendy Smoak added a comment - 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
          Hide
          Lukas Theussl added a comment -

          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.

          Show
          Lukas Theussl added a comment - 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.
          Hide
          Arnaud Heritier added a comment -

          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.

          Show
          Arnaud Heritier added a comment - 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.
          Hide
          Lukas Theussl added a comment -

          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.

          Show
          Lukas Theussl added a comment - 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.
          Hide
          Arnaud Heritier added a comment -

          Reopen to change "fix for"

          Show
          Arnaud Heritier added a comment - Reopen to change "fix for"

            People

            • Assignee:
              Lukas Theussl
              Reporter:
              Arnaud Heritier
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: