I'm using .NET NodeServices under aspnetcore 2.1 and loading an image from the filesystem, resizing it and applying a simple SVG overlay containing text.
I was finding that some images ended up with squares instead of the font (Arial):

In addition I'm seeing this in the Node.js output. The only font I use is Arial.
fail: Microsoft.AspNetCore.NodeServices[0]
(sharp:17224): Pango-WARNING *: couldn't load font "Arial Not-Rotated 18", falling back to "Sans Not-Rotated 18", expect ugly output.
fail: Microsoft.AspNetCore.NodeServices[0]
(sharp:17224): Pango-WARNING *: couldn't load font "Sans Not-Rotated 18", falling back to "Sans Not-Rotated 18", expect ugly output.
fail: Microsoft.AspNetCore.NodeServices[0]
(sharp:17224): Pango-WARNING *: All font fallbacks failed!!!!
fail: Microsoft.AspNetCore.NodeServices[0]
(sharp:17224): Pango-WARNING *: All font fallbacks failed!!!!
fail: Microsoft.AspNetCore.NodeServices[0]
(sharp:17224): Pango-WARNING **: All font fallbacks failed!!!!
fail: Microsoft.AspNetCore.NodeServices[0]
_win32_scaled_font_set_world_transform: The operation completed successfully.
fail: Microsoft.AspNetCore.NodeServices[0]
_win32_scaled_font_set_world_transform: The handle is invalid.
This only occurs when I simultaneously try to process several images at the same time (eg. when I open my website) so it appears to be some kind of threading issue with Sharp / Pango.
To further experiment, the following code overlays the time onto an image, creates a new buffer and does it again - 50 times.
for (var i = 0; i < 50; i++)
{
const watermarkText = new Date().getTime() % 10000;
const watermark = new Buffer(`<svg width="200" height="500">
<text x="90" y="${i*20}" width="400" height="50" font-size="18" fill="#000000" font-family="Arial" text-anchor="middle">${watermarkText}</text>
</svg>`);
// apply the overlay
compressedImage = compressedImage.overlayWith(watermark, { overlayCutout: true });
// create to buffer so we can do it again
var newImage = await compressedImage.toBuffer({ resolveWithObject: true });
compressedImage = sharp(newImage.data);
}
If I run this only once in my browser I always get a nice clean list like this :

You can see from the timestamps it takes about 2 seconds to process all the overlayWith and toBuffer calls.
If I run this only TWICE from two different browser windows I immediately get this every time :


You can see the overlapping timestamps, and that's when the problem begins.
I'm new to Node.js so maybe there's a simple 'thread safe' option I need to enable, but right now I'm somewhat stuck. This is similar to #1162 but I wanted to start a new issue with a clearer explanation.
Hello, my best guess would be that you've run into https://bugs.freedesktop.org/show_bug.cgi?id=73012
The suggested one-line cairo change to use thread-local storage seems sensible. Perhaps you could submit a patch with this to the upstream cairo library?
If this is still open after nearly 5 years I'm not sure I'm qualified enough to fix it! I need some kind of immediate fix :-( I expect I'd spend all day playing around and not get anywhere.
Wondering if there is an alternative way to create a text layer - or maybe I can use a different SVG conversion library?
I'm actually only using this to overlay debugging information over my image so this is only for during testing. I'm finding it very useful to overlay the compressed filesize onto my image so I can see in place how large everything is - but it's not worth too much more time to delve into c code.

@lovell I've concluded there's no good way on Windows to convert SVG text into an image, so I've switched to using Sharp + Jimp for the text overlay. This doesn't seem to suffer from any thread safety issues. In any case the quality for non black/white text is awful as you can see above. I'll try to post a response back to some of the Stackoverflow questions about Sharp text when I've cleaned up my code.
It's been one of those situations where something I thought would take 2 minutes has taken the best part of 2 days. I'm quite astonished the rabbit hole that image processing with Node.JS has taken me down. Any of the other alternative libraries I've looked at (to convert an SVG > PNG) all seem to use Cairo and/or Pango anyway or require Python and expect me to be able to compile it too. All to just add text to an image! Jimp seems like it will be fine for this purpose for me, and it will only be during debugging.
Still new to Sharp, but your very helpful response I've seen to people's questions are much appreciated and have helped me get up to speed quickly. Thanks :-)
https://gitlab.gnome.org/GNOME/librsvg/issues/96 is a report against librsvg of the same problem.
@lovell Just hitting this one right now :(
Any idea when/if this will be fixed? Any workaround you could think of javascript side?
Oh and hi! :P
Submitting a patch to cairo with the thread-local fix would be a good place to start. The upstream bug reports suggest this problem affects Windows only, so avoiding that platform might provide a quick workaround for now.
I ended up delivering the svg directly rather than rasterizing it. All browsers we support do support svg as image src but for someone who would have transformations to apply...
Always nice to talk to you! Take care :)
@simeyla were you able to solve this using await at all?
it won't help if you have multiple node processes running.
Also had a question for you if you were able to use any alternative fonts, and what formats ( woff, ttf etc) you might think are supported.
I am seeing this issue on windows - Pango is rendering multiple concurrent text overlays.
This problem is now being tracked at https://gitlab.freedesktop.org/cairo/cairo/issues/190
Great, thanks!
This was migrated here instead: https://gitlab.freedesktop.org/cairo/cairo/-/issues/190 (the extra dash invokes a different UI)
The one-line fix suggested 6 years ago in https://bugs.freedesktop.org/show_bug.cgi?id=73012#c2 still seems like a good solution to this problem.
There is a merge request in the queue to fix this, and it does use TLS.
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/38
And this Pango MR actually fixes the issue:
It seems that the above PR has been released in Pango v1.45.1. I have updated Pango to v1.45.3 within the libvips Windows binaries used by sharp.
MR https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/38 is not necessary to resolve this issue, since the MXE-binaries uses the FontConfig backend on Windows (to avoid having to link against gdi32.dll and msimg32.dll).
I'll do some tests with the v8.10.0-beta2 (pre-release) binaries to check if this issue has been resolved.
v0.26.0 now available with prebuilt Windows binaries containing the upstream fix.
Most helpful comment
v0.26.0 now available with prebuilt Windows binaries containing the upstream fix.