Unable to read docx containing pictures linking to internal bookmarks: KeyError: "There is no item named 'word/#MyBookmark' in the archive"

[aorsten]

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:

1. Adding a picture to the Word file
2. Right-click => Link
3. 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).

[scanny]

I'm inclined to think the quick fix (if you're patching your fork) is to add code to _SerializedRelationship.is_external to catch this case and report the relationship as external. docx.opc.oxml.CT_Relationship.target_mode is another possibility, adding something like:

if self.target_ref and self.target_ref.startswith("#"):
    return RTM.EXTERNAL

If you want to study the spec, perhaps there is some mention there or clarification of the criteria for internal/external and a more robust long-term behavior could be proposed.

I suppose an alternative is to add code that distinguishes "internal" hyperlinks from internal "parts" and only loads internal part references. But that sounds like a bigger deal that would invoke a broader scope. If I was going to do that I would rework the whole docx.opc.pkgreader module which would benefit from a broad refactoring (but isn't going to get one from me anytime soon :)

Now that I'm thinking about it, maybe just a try-except-continue around the part loading bit would be a better alternative, since that would also address the NULL target issue. Maybe that could just wrap that blob = phys_reader.blob_for(partname) L114 in your stacktrace and have continue there if it catches a KeyError, which essentially skips trying to load that part.

[SebG-js]

#1350 not yet merged

[SebG-js]

Thank you @scanny your fix : it has solved my issue.

I am waiting for a new version.
When the fix will be available ?

[TommasoPetrolito]

I also faced a similar issue and I tried the change of the existing PR and it works. Please, it would be very useful if the proposed PR could get merged.

[TommasoPetrolito]

Possible temporary fixes, in your requirements.txt instead of python-docx==1.1.2 or similar, use instead:

OPTION A:
python-docx @ git+https://github.com/al-rahul/python-docx.git@4ebb3ac

Thank you al-rahul

OPTION B:
python-docx @ git+https://github.com/TommasoPetrolito/python-docx.git@66fa597

This last one is a merge into the current master branch as per the latest version available (including solved conflicts)

[SebG-js]

Yes, it's interesting @TommasoPetrolito
But our chief technician refuses to use a software in production with an unusual version, for security or maintenance reasons.

Maybe @scanny can unblock this situation as regards this very old bug (5 yrs).