Error when loading PDF that uses system fonts

[AllSeeingEye]

Test file: https://dl.dropboxusercontent.com/u/16283445/PORTRAIT.pdf

File was produced by Muhimbi PDF converter.

Main text (that uses embedded Tahoma font) renders ok; it is the trial message on top of the file that causes the error. After some debugging, I've found that this message references system Helvetica font, and somehow glyphs for it are missing at the time of error.

Error log:

Error: Requesting object that isn't resolved yet Helvetica_path_T pdf.js:205
    at error (http://[skipped]/pdfjs/pdf.js:207:15)
    at Object.PDFObjects_get [as get] (http://[skipped]/pdfjs/pdf.js:4640:9)
    at Object.FontFace.getPathGenerator (http://[skipped]/pdfjs/pdf.js:7675:23)
    at Object.CanvasGraphics.paintChar (http://[skipped]/pdfjs/pdf.js:6105:26)
    at Object.CanvasGraphics_showText [as showText] (http://[skipped]/pdfjs/pdf.js:6291:18)
    at Object.CanvasGraphics_nextLineShowText [as nextLineShowText] (http://[skipped]/pdfjs/pdf.js:6381:12)
    at Object.CanvasGraphics_executeOperatorList [as executeOperatorList] (http://[skipped]/pdfjs/pdf.js:5600:22)
    at Object.InternalRenderTask__next [as _next] (http://[skipped]/pdfjs/pdf.js:4807:39)
    at Object.pdfViewcContinueCallback [as continueCallback] (http://[skipped]/pdfjs/viewer.js:4261:9)

[Snuffleupagus]

This fails because the font isn't loaded when we attempt to fetch it in font_loader.js#L313.
The issue appears to be that it's never actually loaded at all, given evaluator.js#L284, since font.data is undefined in this case. The reason for this is that the font in question doesn't have an embedded font file, which means that in fonts.js we return before defining font.data. See fonts.js#L2256 and fonts.js#L2303.
The reason that this isn't a bigger problem in practice for us, is that it only seems to affect PDFs (like this issue) where the font resource is contained inside e.g. an XObject dictionary.

I unfortunately don't know how we could address this issue, since building font.data without a font file seems difficult in the current code. Perhaps this would get solved "for free" if we embedded the standard fonts in PDF.js?

P.S. I also noticed that fixing this issue would address one (or two) of the files listed in http://bthorben.github.io/pdfRepo/#crashed.

[mrsnow-git]

Can there be a solution like one of these:

1 - option to allow use some default font or some font what already been used for exact file
2 - option to allow skip rendering of this item
this can help to continue work with pdf file if some font are absent, and output only as warning, not as breaking error.

What do you think?

[yurydelendik]

We prefer the first option, however we don't embed any fonts yet and rely on system to contain those for some functions. We can certainly ignore, once we find how to properly stub it (For these font, we can generate empty letters outlines when requested)

[xwcg]

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.

[ruspaull]

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

[miketaylr]

A dupe was filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1463728

[imdreamrunner]

Hello everyone,
I got the same error.
May I know if there is any temporary work-around for this issue before the formal fix?

[diego-lipinski-de-castro]

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

[sirisian]

@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.

[imdreamrunner]

@sirisian thanks for your update. Looking forward to the release

[miguelTapiaRomero]

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

[kvvsatyasunil]

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

[fvilers]

Hi, I also encounter this error. Is there a way to substitute font that aren't present on the system with a default one?

[arelra]

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

[sayo96]

@Snipeye Did you find a fix for this #4244 (comment) ? 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.

[dsherret]

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.

[timvandermeij]

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.

[electrovir]

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.".

[Narretz]

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.

[nickmanning214]

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.

[electrovir]

Coming back to this:
Both solutions from @Narretz and @nickmanning214 are working equally great for me!

[snowfluke]

Can we at least specify what the fallback font should be in case system font is used?

[geneshairzan]

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.

THIS IS what iam looking for in past week