Skip to content

Add support for inline images - #1287

Open
Ondama wants to merge 1 commit into
bpampuch:masterfrom
Ondama:inline-images
Open

Add support for inline images#1287
Ondama wants to merge 1 commit into
bpampuch:masterfrom
Ondama:inline-images

Conversation

@Ondama

@Ondama Ondama commented Feb 17, 2018

Copy link
Copy Markdown

This is related to #358

The result is this: fluid-layout.pdf

The source is:

const docDefinition = {
    pageSize: 'A4',
    pageMargins: [24, 25, 24, 23],
    content: [
        {text: ['hello', {image: 'smile'}, {text: 'world', style: 'em'}]}
    ],
    styles: {
        em: {bold: true}
    },
    images
}

@Ondama
Ondama force-pushed the inline-images branch 2 times, most recently from f7ca60f to 5eba4ce Compare February 23, 2018 23:00
@danielpassos

Copy link
Copy Markdown

Any update on it?

@zahrafali

Copy link
Copy Markdown

Will this allow inline svg as well?

@th3impal3r

Copy link
Copy Markdown

bump this would be great!

@miroslavvojtus

Copy link
Copy Markdown

Hi.
We would need this feature. It is pretty basic feature in document editing.

Why is this PR waiting more than 2 years?
Is this lib maintained at all?

@thecodrr

thecodrr commented Jul 9, 2021

Copy link
Copy Markdown

@liborm85 ping

@Qiric

Qiric commented Nov 15, 2021

Copy link
Copy Markdown

Can't wait for this!

@Qiric

Qiric commented Nov 16, 2021

Copy link
Copy Markdown

@Ondama You don't happen to have your past solution ported over to a more recent version of pdfmake do you?

@laukacka

Copy link
Copy Markdown

@liborm85 please check it out :)

@DavMem

DavMem commented Aug 28, 2024

Copy link
Copy Markdown

thank you so much.
this still works as of today

@robbytx

robbytx commented Mar 5, 2026

Copy link
Copy Markdown

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.

BlackDragonBE added a commit to BlackDragonBE/md2pdf that referenced this pull request Jul 30, 2026
`![alt](x)` 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>
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.

10 participants