Skip to content

Quick and Dirty fix of the Nullpointer Exception when calling li tags…#89

Closed
ChristophKronberger wants to merge 2 commits into
plutext:VERSION_11_4_8from
ChristophKronberger:VERSION_11_4_8
Closed

Quick and Dirty fix of the Nullpointer Exception when calling li tags…#89
ChristophKronberger wants to merge 2 commits into
plutext:VERSION_11_4_8from
ChristophKronberger:VERSION_11_4_8

Conversation

@ChristophKronberger

@ChristophKronberger ChristophKronberger commented Jun 29, 2022

Copy link
Copy Markdown

… without ol or ul container.
Since I encountered the same problem as #21 I changed the list helper so that when the .peek() returns null a new standard object is created.

This means that the li tags are not handled, but the null pointer is avoided.

…st witch takes a target Part. This can be used to convert XHTML String with Images into Header or Footer. Also added for that the XHTMLImageHandlerDifferentTarget class.
@ChristophKronberger

Copy link
Copy Markdown
Author

I also added a convert Method in XHTML importer, witch takes a TargetPart to add Images in Header or Footer

@plutext

plutext commented Jul 27, 2026

Copy link
Copy Markdown
Owner

closing, since everything here is handled in 17_0_1

@plutext plutext closed this Jul 27, 2026
plutext added a commit that referenced this pull request Jul 27, 2026
Relationship ids are resolved per part, so XHTML converted for a header or
footer had its images added as relationships of the main document part,
where the r:embed in the header can't resolve them; the image was missing
in Word, and no header1.xml.rels was written at all.

XHTMLImageHandlerDefault.setTargetPart names the part images should belong
to, using BinaryPartAbstractImage.createImagePart(OpcPackage, Part, byte[]).
It defaults to null, meaning the main document part, so existing behaviour
is unchanged; XHTMLImageHandler is untouched, so custom implementations
still compile.

Setting a different target part clears the image part cache: cached parts
are relationships of the part they were created for, so reusing one for
another target would reintroduce the unresolvable r:embed.

Addresses the use case of PR #89, whose implementation stored the target
part but never used it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants