Maven Doxia

Doxia generates wrong xdoc when generating book from docbook

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1
  • Fix Version/s: 1.1.1
  • Component/s: None
  • Labels:
    None
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    3

Description

When generating a book from a docbook input the output is missing the starting document tag.

Issue Links

This issue depends upon:
DOXIA-184 Docbook issues Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Arne Limburg added a comment -

This test demonstrates the problem

Show
Arne Limburg added a comment - This test demonstrates the problem
Hide
Permalink
Arne Limburg added a comment -

I don't know if there is a more elegant way to do it, but the applied patch fixes the problem

Show
Arne Limburg added a comment - I don't know if there is a more elegant way to do it, but the applied patch fixes the problem
Hide
Permalink
Lukas Theussl added a comment -

This is a general problem of the docbook parser, see DOXIA-184, it should be fixed there.

Show
Lukas Theussl added a comment - This is a general problem of the docbook parser, see DOXIA-184, it should be fixed there.
Hide
Permalink
Lukas Theussl added a comment -

Fixed in r781693

Note that your docbook sources are not valid. Doxia requires valid simplified docbook input, ie there should be an <article> root element. Your files should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.1//EN" "http://www.oasis-open.org/docbook/xml/simple/1.1/sdocbook.dtd">

<article>

<section id="section1">
  <title>Section 1</title>
  <para>This is the first section.</para>
</section>

</article>
Show
Lukas Theussl added a comment - Fixed in r781693 Note that your docbook sources are not valid. Doxia requires valid simplified docbook input, ie there should be an <article> root element. Your files should look like this: 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.1//EN" "http://www.oasis-open.org/docbook/xml/simple/1.1/sdocbook.dtd">

<article>

<section id="section1">
  <title>Section 1</title>
  <para>This is the first section.</para>
</section>

</article>
Hide
Permalink
Arne Limburg added a comment -

Hi Lukas,

thank you for fixing this so fast. But there is still a bug in this piece of code (see the attached test).
I think the call to handleIdAnchor( parser, sink ) in handleStartTag in DocbookParser must go somewhere else in that method.

Thank you anyway, for me it now works since my articles need no id-attribute.

Show
Arne Limburg added a comment - Hi Lukas, thank you for fixing this so fast. But there is still a bug in this piece of code (see the attached test). I think the call to handleIdAnchor( parser, sink ) in handleStartTag in DocbookParser must go somewhere else in that method. Thank you anyway, for me it now works since my articles need no id-attribute.
Hide
Permalink
Lukas Theussl added a comment -

Thanks for testing and the feedback!

So a fix would be to check for the special case of article and emit the anchor after the document start.

However, I have some doubts:

  • I checked that an id attribute is legal for article in simplified docbook, but I don't quite see the use case, what is it for?
  • we have removed automatic anchor generation from the apt and xdoc parsers (see eg DOXIA-152), I think the docbook should do the same. If the id attribute of an element is preserved, then one can link to that, you don't need an anchor. However, I don't use docbook myself so I'm not too sure if this isn't going to break something I am not aware of. Especially in a point release we should try not to change any expected behavior, but in principle I would vote for removing the anchor insertion.
Show
Lukas Theussl added a comment - Thanks for testing and the feedback! So a fix would be to check for the special case of article and emit the anchor after the document start. However, I have some doubts:
  • I checked that an id attribute is legal for article in simplified docbook, but I don't quite see the use case, what is it for?
  • we have removed automatic anchor generation from the apt and xdoc parsers (see eg DOXIA-152), I think the docbook should do the same. If the id attribute of an element is preserved, then one can link to that, you don't need an anchor. However, I don't use docbook myself so I'm not too sure if this isn't going to break something I am not aware of. Especially in a point release we should try not to change any expected behavior, but in principle I would vote for removing the anchor insertion.
Hide
Permalink
Lukas Theussl added a comment -

I have simply removed the anchor generation from the article tag for now, this fixes the build failure. The id is forwarded directly into the sink's head, eg for xdoc it goes into the <document> tag. I have opened DOXIA-334 for the general anchor generation issue.

Show
Lukas Theussl added a comment - I have simply removed the anchor generation from the article tag for now, this fixes the build failure. The id is forwarded directly into the sink's head, eg for xdoc it goes into the <document> tag. I have opened DOXIA-334 for the general anchor generation issue.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.