Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RI mapper in the NamespacePrefixMapperUtils#getPrefixMapperRelationshipsPart #333

Closed
andreysubbotin opened this issue Nov 30, 2018 · 1 comment
Closed

RI mapper in the NamespacePrefixMapperUtils#getPrefixMapperRelationshipsPart #333

andreysubbotin opened this issue Nov 30, 2018 · 1 comment

Comments

@andreysubbotin
Copy link

andreysubbotin commented Nov 30, 2018 •
edited
Loading

If system uses Java 9/10, then NamespacePrefixMapperUtils#getPrefixMapperRelationshipsPart returns tryUsingRI(m) mapper.
I think it necessary to use tryRIforRelationshipsPart.

With tryUsingRI(m) mapper relationships generates with namespace. LibreOffice unable to open docx with namespaces in the relationships.
XML relationships sample:

<rel:Relationships xmlns:rel="http://schemas.openxmlformats.org/package/2006/relationships"><rel:Relationship Target="styles.xml" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles" Id="rId1"></rel:Relationship>

With docx4j 3.3.6 relationships are generated without namespace:

<Relationships xmlns:rel="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Target="styles.xml" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles" Id="rId1"></rel:Relationship>
@andreysubbotin andreysubbotin mentioned this issue Nov 30, 2018
Closed
@plutext
Copy link
Owner

plutext commented Nov 30, 2018

Thanks for this. You are correct to suggest tryRIforRelationshipsPart :-)
Fix will be in 6.1.0

campbellr added a commit to campbellr/docx4j that referenced this issue Feb 6, 2020
@campbellr
Fix typo in NamespacePrefixMapperUtils.tryRIforRelationshipsPart
1b67a8f 
This caused the first call to getPrefixMapperRelationshipsPart
to always return `null`. All subsequent calls would correctly return the
correct (cached) version.

The end result is essentially a reoccurence of plutext#333, where Relationship
tags are incorrectly prefixed with `rel:`, which breaks LibreOffice.
campbellr added a commit to campbellr/docx4j that referenced this issue Feb 6, 2020
@campbellr
Fix typo in NamespacePrefixMapperUtils.tryRIforRelationshipsPart
6e63004 
This caused the first call to getPrefixMapperRelationshipsPart
to always return `null`. All subsequent calls would correctly return the
correct (cached) version.

The end result is essentially a reoccurence of plutext#333, where Relationship
tags are incorrectly prefixed with `rel:`, which breaks LibreOffice.
campbellr added a commit to campbellr/docx4j that referenced this issue Feb 6, 2020
@campbellr
Fix typo in NamespacePrefixMapperUtils.tryRIforRelationshipsPart
8e27513 
This caused the first call to getPrefixMapperRelationshipsPart
to always return `null`. All subsequent calls would correctly return the
correct (cached) version.

The end result is similar to plutext#333, where Relationship
tags are incorrectly prefixed with `rel:`, which breaks LibreOffice.

Except that it only occurs the first time a docx is saved.
@campbellr campbellr mentioned this issue Feb 6, 2020
Merged
TheDanDLion pushed a commit to LegalSifter/docx4j that referenced this issue Aug 22, 2023
@campbellr @TheDanDLion
Fix typo in NamespacePrefixMapperUtils.tryRIforRelationshipsPart
b5235c3 
This caused the first call to getPrefixMapperRelationshipsPart
to always return `null`. All subsequent calls would correctly return the
correct (cached) version.

The end result is similar to plutext#333, where Relationship
tags are incorrectly prefixed with `rel:`, which breaks LibreOffice.

Except that it only occurs the first time a docx is saved.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@plutext @andreysubbotin