Take odrcore 6.10.1 - #613
Merged
Merged
Conversation
One fix, and it is ours: a linked image in a docx or xlsx is now named relative to the document, the way the odf engines always named theirs. The ooxml side resolved the relationship into an absolute container path and the html layer emitted it verbatim, so `src="/word/media/image1.jpeg"` resolved against the server root rather than against `/file/odr/`, and every picture in a Word or Excel document 404ed into the core's broken-image placeholder. Nothing here has to move with it. The app already asks for linked images rather than embedded ones - `embedImages = false` - which is the shape the fix is for, and `relativeResourcePaths` is not the lever it looks like: it governs only the *shipped* resources, core's own css and js, never a document's own. No file type, extension or mime type changes either, so `SupportedDocumentTypes` derives the same two sets and `SupportedFormatsTest` still holds. Drafted ahead of the release: 6.10.1 is not on maven central yet, so the one unresolved dependency in the tree is this one and CI cannot go green until the core's release run publishes the AAR. Everything else resolves. Not yet checked on a device for the same reason. `image-anchor.docx` and `file-sample_100kB.docx` from the core's corpus are the two that showed it, and both should come back with their pictures rather than the placeholder. Closes #551
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One fix, and it is ours: a linked image in a docx or xlsx is now named relative
to the document, the way the odf engines always named theirs. The ooxml side
resolved the relationship into an absolute container path and the html layer
emitted it verbatim, so
src="/word/media/image1.jpeg"resolved against theserver root rather than against
/file/odr/, and every picture in a Word orExcel document 404ed into the core's broken-image placeholder.
Nothing here has to move with it. The app already asks for linked images rather
than embedded ones -
embedImages = false- which is the shape the fix is for,and
relativeResourcePathsis not the lever it looks like: it governs only theshipped resources, core's own css and js, never a document's own. No file
type, extension or mime type changes either, so
SupportedDocumentTypesderivesthe same two sets and
SupportedFormatsTeststill holds.Drafted ahead of the release: 6.10.1 is not on maven central yet, so the one
unresolved dependency in the tree is this one and CI cannot go green until the
core's release run publishes the AAR. Everything else resolves.
Not yet checked on a device for the same reason.
image-anchor.docxandfile-sample_100kB.docxfrom the core's corpus are the two that showed it, andboth should come back with their pictures rather than the placeholder.
Closes #551
🤖 Generated with Claude Code