requiring sharp breaks ghostscript4js

This was a wild ride to figure out. We’re using ghostscript4js to extract JPEGs from multi-page PDFs. This worked for most files until we had a file where the text of a single PDF would be complete garbage inside the JPEG. For legal reasons I am not able to share the specific PDF, but here’s the comparison of PDF vs JPEG

JPEG extracted without sharp required:

JPEG extract with sharp required (but not used at all):

This is a minimal test-case to reproduce (if you had the PDF…)

//Uncomment this line to break JPEG extraction.
//require('sharp');

const gs = require('ghostscript4js');

async function pdf() {
  try {
    const command =
      '-psconv -q -r300 -sPAPERSIZE=a4 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dUseTrimBox -sDEVICE=jpeg -dDownScaleFactor=3 -o out-%d.jpg -dJPEGQ=100 -f in.pdf';
    await gs.execute(command);
    console.log('done');
  } catch (err) {
    console.error(err);
  }
}

pdf();

Basically I’m hoping one of the maintainers has an idea as to why simply requiring sharp would break ghostscript? I’m confused af. What exactly does sharp change about the process environment that could cause something like that?

I will spend some time narrowing this down further but I’m hoping one of you knows what’s up.

[lovell]

“As far as I can tell neither libfontconfig nor libfreetype are a dependency of libvips. Why are they downloaded?”

libfreetype is a dependency of libfontconfig, which is a dependency of librsvg, which is a dependency of the pre-compiled libvips provided by sharp.

“I believe the versions that sharp installs are the most recent? If so then sooner or later our PDF will break again if the global version (the apt packages are probably a bit behind) reach that version?”

The pre-compiled binaries of libvips and its dependencies are defined in https://github.com/lovell/sharp-libvips/ and are tagged against the relevant libvips version, e.g. v8.6.1. When using pre-compiled binaries, the list of versions are also made available at runtime via sharp.versions.

It sounds like the underlying problem might be a change in behaviour in libfreetype, either intentional or a regression, between its versions.

[Prinzhorn]

Thank you for the explanation