The document below contains a picture with a hyperlink to an internal bookmark.
PictureBookmarks.docx (The very last picture links to the very first Heading1)
I get this error message when reading the file using python-docx: KeyError: "There is no item named 'word/#MyBookmark' in the archive"
Stack trace
# Command
self.document = Document(document)
# Trace (from pytest)
..\..\..\..\..\python-docx\docx\api.py:32: in Document
document_part = Package.open(docx).main_document_part
..\..\..\..\..\python-docx\docx\opc\package.py:117: in open
pkg_reader = PackageReader.from_file(pkg_file)
..\..\..\..\..\python-docx\docx\opc\pkgreader.py:37: in from_file
phys_reader, pkg_srels, content_types
..\..\..\..\..\python-docx\docx\opc\pkgreader.py:74: in _load_serialized_parts
for partname, blob, reltype, srels in part_walker:
..\..\..\..\..\python-docx\docx\opc\pkgreader.py:119: in _walk_phys_parts
for partname, blob, reltype, srels in next_walker:
..\..\..\..\..\python-docx\docx\opc\pkgreader.py:114: in _walk_phys_parts
blob = phys_reader.blob_for(partname)
..\..\..\..\..\python-docx\docx\opc\phys_pkg.py:109: in blob_for
return self._zipf.read(pack_uri.membername)
C:\...\lib\zipfile.py:1337: in read
with self.open(name, "r", pwd) as fp:
C:\...\lib\zipfile.py:1375: in open
zinfo = self.getinfo(name)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <zipfile.ZipFile filename='C:\\...\\PictureBookmarks.docx' mode='r'>, name = 'word/#MyBookmark'
def getinfo(self, name):
"""Return the instance of ZipInfo given 'name'."""
info = self.NameToInfo.get(name)
if info is None:
raise KeyError(
> 'There is no item named %r in the archive' % name)
E KeyError: "There is no item named 'word/#MyBookmark' in the archive"
How to recreate
This is achieved by:
- Adding a picture to the Word file
- Right-click => Link
- Add link to any internal bookmark.
Then the hyperlink ends up like this, notice the a:hlinkClick relationship ID:
<w:drawing>
<wp:inline distT="0" distB="0" distL="0" distR="0" wp14:anchorId="2A30E332" wp14:editId="3F2B5F70">
(...)
<a:graphic xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main">
<a:graphicData uri="http://schemas.openxmlformats.org/drawingml/2006/picture">
<pic:pic xmlns:pic="http://schemas.openxmlformats.org/drawingml/2006/picture">
<pic:nvPicPr>
<pic:cNvPr id="28" name="Picture 28" descr="(...)">
<a:hlinkClick r:id="rId21"/>
</pic:cNvPr>
<pic:cNvPicPr/>
</pic:nvPicPr>
<pic:blipFill>
(...)
</pic:blipFill>
(...)
</pic:pic>
</a:graphicData>
</a:graphic>
</wp:inline>
</w:drawing>
Now, in word/_rels/document.xml.rels, we get:
<Relationship Id="rId21" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="#MyBookmark"/>
This item bugs python-docx for me. I'll admit I'm using a 2.5-year-old version of the package, since I needed to modify stuff for my own usecase, so I am not sure whether this has been fixed after that. I was looking for whether this had been solved somehow, and it seems it is very much related to this issue.
Investigation
I see in the pkgreader that the target_mode can be used to identify external targets, and that external targets receive special treatment to avoid such zipfile issues. External targets are recognized in the relationship file for e.g. hyperlinks to web sites, and add a Target attribute to the <Relationship> object.
From what I gather, RT.HYPERLINK elements that have a Target starting with # should be treated specially - like some sort of internal bookmark relationship (or similar).
The document below contains a picture with a hyperlink to an internal bookmark.
PictureBookmarks.docx (The very last picture links to the very first Heading1)
I get this error message when reading the file using python-docx: KeyError: "There is no item named 'word/#MyBookmark' in the archive"
Stack trace
How to recreate
This is achieved by:
Then the hyperlink ends up like this, notice the a:hlinkClick relationship ID:
Now, in word/_rels/document.xml.rels, we get:
This item bugs python-docx for me. I'll admit I'm using a 2.5-year-old version of the package, since I needed to modify stuff for my own usecase, so I am not sure whether this has been fixed after that. I was looking for whether this had been solved somehow, and it seems it is very much related to this issue.
Investigation
I see in the pkgreader that the target_mode can be used to identify external targets, and that external targets receive special treatment to avoid such zipfile issues. External targets are recognized in the relationship file for e.g. hyperlinks to web sites, and add a Target attribute to the <Relationship> object.
From what I gather, RT.HYPERLINK elements that have a Target starting with # should be treated specially - like some sort of internal bookmark relationship (or similar).