mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-06 00:59:39 +03:00
PDF Export: permalink Image not exported #3437
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @main-sonn on GitHub (Jan 9, 2023).
Describe the Bug
An image is uploaded as attachment and inserted/linked on a page (e.g. https://bookstack.example/attachments/20200)
The image is displayed correctly on the page, but in the exported pdf it says "Image not found or type unknown".
Steps to Reproduce
Expected Behaviour
all images should be exported to the pdf: permalink images https://bookstack.example/attachments/20200 and https://bookstack.example/uploads/images/gallery/2022-12/example-image-eua3djve.png
Screenshots or Additional Context
No response
Browser Details
No response
Exact BookStack Version
v22.11
PHP Version
No response
Hosting Environment
Ubuntu 22.04
@ssddanbrown commented on GitHub (Jan 10, 2023):
Hi @me-sp,
Images with PDFs are specifically handled to embed the data for creation.
We don't target attachment link-based images for this at all since it's generally not expected that attachments are used for in-content images, and I'm skeptical in thinking it'd be worthwhile to expand the system to support attachment images.
Can I ask why you are using attachments as in-content images rather than normal uploaded content images?
@main-sonn commented on GitHub (Jan 11, 2023):
Hi @ssddanbrown,
we have imported html files from our old wiki with the bookstack api. Many images are used multiple times per page.
First we tried to integrate the images inline into the HTML (before importing them via bookstack api). Unfortunately, the same images were then uploaded to Boostack several times, so we uploaded the images as an attachment and linked them.
@ssddanbrown commented on GitHub (Jan 26, 2023):
Okay, thanks for the info. I don't see it really being worth us implementing specific functionality to suit what is a workaround for another limitation, our focus should instead be on adding proper image APIs so the initial limitation does not exist. Therefore I'm going to close this off.
Just an idea, although it's not ideal at all, you could push the unique images inline then fetch back out the page to get the image URLs to re-use. Of course, us adding proper image APIs would be the actual alternative.