Add support for inline images - #1287
Conversation
f7ca60f to
5eba4ce
Compare
|
Any update on it? |
|
Will this allow inline svg as well? |
|
bump this would be great! |
|
Hi. Why is this PR waiting more than 2 years? |
|
@liborm85 ping |
|
Can't wait for this! |
|
@Ondama You don't happen to have your past solution ported over to a more recent version of pdfmake do you? |
|
@liborm85 please check it out :) |
|
thank you so much. |
|
This would definitely be nice to have. In particular, the lack of inline image/SVG support prevents the use of color emojis with arbitrary text (using something like Twemoji), see foliojs/pdfkit#1056 (comment). While that might eventually be resolved by foliojs/pdfkit#1690, support for other inline images and icons that aren't official emoji characters would be desirable. |
`` inside a paragraph rendered as nothing at all — not even its alt text. Perversely, a *broken* inline image showed alt text while a working one showed nothing. pdfmake has no in-text-flow non-text node. That same gap is what blocks colour emoji: PDF has no colour-font concept, so the only route is drawing artwork inline (foliojs/pdfkit#575), which pdfmake cannot do. This commit adds the capability; the emoji work builds on it next. The node was never really dropped. copyStyle carries every non-`text` key onto the inline and splitWords('') still yields one word, so an {svg}/{image} item reaches the renderer intact. It failed for two narrow reasons, so the patch is two hunks in the two functions sup/sub already use: - textTools.js measure(): stop overwriting the caller's width with widthOfString('') === 0. Draw size goes to _inlineW/_inlineH; `height` stays the text line height, because Line.getHeight grows from the tallest inline while Line.getAscenderHeight is font-derived, so raising it would add space below the baseline rather than move the text. - printer.js renderLine(): draw inline.svg via SVGtoPDF or inline.image via pdfKitDoc.image, on the baseline, then continue. Upstream is a dead end: bpampuch/pdfmake#1287 is this exact fix, open since 2018; 0.3.x does not add it and would cost per-render font isolation and our page-count hook; the pdfkit colour-emoji PRs stalled in March on a test-font licence. patches/README.md records all of it and the removal condition. The hard part was not the patch. The browser loads build/pdfmake.js while the golden tests load src/printer.js — different copies. A script copying the hunks matched on a trailing code line, truncated the measure() hunk at the end of its `if`, and dropped the `else` that measures every ordinary word. The marker comment was present, all 359 Node tests passed, and the browser could not lay out any text at all. So the guard tests assert the surviving original behaviour rather than the marker, and the new E2E test is the only thing that exercises the bundle. pdfmake is pinned exactly; npm install rewrites that back to a caret when it re-resolves, which the guard also catches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This is related to #358
The result is this: fluid-layout.pdf
The source is: