PNG Generated using Microsoft's Office JavaScript API prints incorrectly cells with wrapped text on 2 lines when only one is visible

Hi @Pavel Otta (CZ)

Based on your description, this looks much more like a rendering bug/limitation in Excel.Range.getImage() than an issue with your linked object.

Range.getImage() does not simply capture the visible Excel viewport. It asks Excel to render the range into a Base64 PNG, and Microsoft already documents a known issue where wrapped text can be rendered differently from what is visibly shown in the worksheet.

That matches your scenario very closely:

• the cell contains two wrapped lines,

the row height only exposes the first line in Excel,

the worksheet view correctly clips the second line,

but Range.getImage() renders both lines into the bitmap.

So I would not try to “fix” the linked object or downstream image handling. The PNG is already incorrect when returned by Excel.

As a workaround, the safest options would be:

temporarily resize the row so the wrapped text is fully visible before calling getImage(), then restore the original height, or

temporarily replace/normalize the wrapped text in the source range before generating the image, then restore the original value/formatting.

Neither workaround is ideal if your requirement is to reproduce exactly what the user sees on screen.

Since the worksheet renders correctly in both Excel for the web and desktop, but Range.getImage() does not, I would report this as an Office.js product bug and include a minimal reproduction showing:

one cell with wrapped text containing two lines,

row height set so only the first line is visible,

Range.getImage() output showing both lines.

There is historical precedent for Range.getImage() rendering inconsistently across Excel clients, and Microsoft has previously classified similar behavior as product bugs rather than application-code issues.

If you can provide the Excel version/build and whether the same PNG is produced in both Desktop and Web, that would make the bug report even stronger.

If this answer was helpful, please consider marking it as helpful or accepting it as the answer.Hi Pavel,

Based on your description, this looks much more like a rendering bug/limitation in Excel.Range.getImage() than an issue with your linked object.

Range.getImage() does not simply capture the visible Excel viewport. It asks Excel to render the range into a Base64 PNG, and Microsoft already documents a known issue where wrapped text can be rendered differently from what is visibly shown in the worksheet.

That matches your scenario very closely:

the cell contains two wrapped lines,

the row height only exposes the first line in Excel,

the worksheet view correctly clips the second line,

but Range.getImage() renders both lines into the bitmap.

So I would not try to “fix” the linked object or downstream image handling. The PNG is already incorrect when returned by Excel.

As a workaround, the safest options would be:

temporarily resize the row so the wrapped text is fully visible before calling getImage(), then restore the original height, or

temporarily replace/normalize the wrapped text in the source range before generating the image, then restore the original value/formatting.

Neither workaround is ideal if your requirement is to reproduce exactly what the user sees on screen.

Since the worksheet renders correctly in both Excel for the web and desktop, but Range.getImage() does not, I would report this as an Office.js product bug and include a minimal reproduction showing:

one cell with wrapped text containing two lines,

row height set so only the first line is visible,

Range.getImage() output showing both lines.

There is historical precedent for Range.getImage() rendering inconsistently across Excel clients, and Microsoft has previously classified similar behavior as product bugs rather than application-code issues.

If you can provide the Excel version/build and whether the same PNG is produced in both Desktop and Web, that would make the bug report even stronger.

If this answer was helpful, please consider marking it as helpful or accepting it as the answer.