pdf.js: Error when loading PDF that uses system fonts

This one bug renders the whole library useless.

That’s not really true since the vast majority of PDF files simply embed their fonts (or a subset), in which case there is no problem at all. In fact, that’s highly recommended everywhere, also in the PDF specification, since it ensures that PDF files render consistently across viewers and platforms. By not embedding (a subset of the) fonts you simply cannot assume that the file will look correctly in all viewers, so that’s taking a risk.

the lack of commitment for a fix is frustrating

You have to realize that this is not a trivial issue, and in the meantime work has been done to investigate how we can resolve this. There is a pull request just above (#12726) that aims to provide an implementation for this. While not completely done yet, there is effort being put into this.

If you think this issue deserves more attention, use the thumbs up emoji on the original comment so it shows up higher in the priority list (see https://github.com/mozilla/pdf.js/issues?q=is%3Aissue+sort%3Areactions-%2B1-desc+is%3Aclosed for issues that have been solved that also had a high number of thumbs up), but please keep comments constructive at all times.

For anyone else getting an error during fetchStandardFontData when using pdfjs-dist in node / not web:

Warning: fetchStandardFontData: failed to fetch file "FoxitSans.pfb" with "UnknownErrorException: The standard font "baseUrl" parameter must be specified, ensure that the "standardFontDataUrl" API parameter is provided.".

pdfjs-dist has a folder standard_ fonts but for some reason, it doesn’t default to loading the fonts from there when used with node.

You have to set the standardFontDataUrl during getDocument:

  const loadingTask = getDocument({
    data: buffer, // or src 
    standardFontDataUrl: join(__dirname, '../../../../node_modules/pdfjs-dist/standard_fonts/'),
  });

You can use a relative path, too, but note that it must be relative to the script entry directory. I wrap getDocument for use in node, so I don’t have to set standardFontDataUrl all the time.

Any update on this?, Its from 2014 and still not solved

with pdfjs-dist": "^2.2.2 set disableFontFace: false fixed this issue on me.

pdfjs.getDocument( { url: pdfUrl, disableFontFace: false, }

I see this is closed, but what’s the solution? I recently updated my pdfjs-dist dependency and a file that used to work just fine now gives me following:

Warning: fetchStandardFontData: failed to fetch file "FoxitSans.pfb" with "UnknownErrorException: The standard font "baseUrl" parameter must be specified, ensure that the "standardFontDataUrl" API parameter is provided.".

6 years ago @AllSeeingEye was having a problem and today this library has 594 unresolved issues. Nobody gives a f*** about this bug or what ? A bug that is for me a no-go, will need to look for other libs like pdf-lib maybe.

In my opinion, whenever pdf.js fails to load text in a particular font, it should load the same text using a substitute font it could show (e.g., the default fonts set by the user in the font preferences), rather than stop rendering the page and throw an error. This was the behavior in Firefox 61 and earlier when the option “Allow pages to choose their own fonts, instead of your selections above” is disabled. In my opinion, showing text in a substitute font is better than showing nothing at all.

@sirisian do you know when will be the update for npm pdfjs-dist? and if there is a workaround for npm? Thanks

At least open the possibility to .catch(…) this error instead of just stopping everything until you can find a better solution. Unfortunately this problem breaks functionality in our live environment which is… bad.

I was able to disable the warning with: getDocument({ url: pdfPath, useSystemFonts: true });

But now I’m thinking maybe I should embed the font directly so that it will be consistent on all machines.

Any updates on this fix release for npm pdfjs-dist ?

There is some code in #12711 that falls back to disableFontFace: false behaviour when a font can’t be loaded to at least render the text. It seems to work in the scenarios I needed it for, but probably still needs more work. You may want to apply this as a patch in your applications if you find it works in your scenarios.

hi team, I tried all the possible things, nothing can make solve the bug. have any updates ?

I’m having the exact same issue. Trying to run it in a lambda on Node12, which runs amazonlinux2 - meaning no fonts installed by default. It would be REALLY nice if we could embed the standard 14 fonts into pdfjs by default, or expose an API for loading them rather than relying on them being installed in the base system. Thus far my efforts to install the fonts to the system have been… less than successful.

At this point I’m thinking I might pre-process every PDF with another library, like pdf-lib, explicitly to embed the 14 standard fonts, THEN pass it to this library for rendering. A bit excessive and annoying, but if it resolves the problem…

After tinkering for literal hours with amazonlinux2 to install fonts, I CAN get the non-included fonts to render by setting disableFontFace to false explicitly, but then the embedded fonts from the PDF fail with the same symbol seen in @Hatgor 's comment.

I’m working on a project where IE 11 is a requirement and the security settings (managed by the IT team) do not allow custom fonts to be downloaded. This results in a PDF rendering this is mostly blank when rendering, only showing a few headlines and italic characters.

setting disableFontFace: true causes the inverse in IE 11 (and all other browsers actually). Most fonts then render but it introduces a litany errors such that look like this:

Warning: getPathGenerator - ignoring character: "Error: Requesting object that isn't resolved yet Times_path_i.".

The errors all indicate different characters in the Times_path_* portion of the message. The document loads most content but headlines, italics, and other variations are visually missing (although the empty text can be selected due to the transparent text layer on top)

So, I’m stuck between having full font rendering in all browsers except this managed version of IE 11 (due to the administrator enforced security setting regarding fonts) or semi-broken font rendering everywhere due to trying to implement a fix for IE 11.

Any suggestions?

@Snipeye Did you find a fix for this https://github.com/mozilla/pdf.js/issues/4244#issuecomment-636934578 ? A lot of people are running into this bug and a lot of issues are being closed stating that they are a duplicate of this issue . If someone has a fix please do post it here.

This one bug renders the whole library useless. We can’t depend on a library that cannot open PDFs while every major browser and app can. There is no workaround, and the lack of commitment for a fix is frustrating.

OK, so far no dice in pre-processing PDFs to embed fonts. Is there, perhaps, a way to inject a font that’s not embedded in the PDF? I can host the necessary .ttf(s) somewhere else, but I’m not seeing anything in the API to load an arbitrary font.

Good day everyone!

Faced some similar issues while trying to solve the text layer render issue with disableFontFace params.

On disableFontFace: false some documents looks like this:

While on disableFontFace: true the previous document render well, there is an issue with a different document:

All these cells were not empty. Some docs render well in one way, some - in other way. How should I act?

any news on that ?

any news on that ?

Hi @timvandermeij when are we likely to see this fix in pdfjs-dist ?

@diego-lipinski-de-castro FYI, that #9809 merge fixed this if you pass in ignoreErrors: true into the getDocument function. If you use the npm pdfjs-dist it’s not updated yet. I just built from source and PDFs that used to complain about fonts now process correctly with canvas output. Everything seems fine.

Is there any workaround available? Or some sort of error catching mechanism suggested by @xwcg ?