react-pdf: Multiple `toBlob` executed at the same time throws TypeError: Cannot read property 'hasGlyphForCodePoint' of null

I’m getting this error with two separate PDFDownloadLink components, so it doesn’t seem to be restricted to PDFViewer. Both by PDFDownloadLink components are rendering different documents with different data. The only shared data is the fonts. EDIT: actually, they also share some styled components using @react-pdf/styled-components, however when not using custom fonts there are no errors.

I’m using v1.5.6

Not sure how it’s related or is it helpful, but I also have similar behavior (an error as @klis87 mentioned).

TypeError: Cannot read property 'hasGlyphForCodePoint' of null
    at react-pdf.browser.es.js:3777
    at Array.reduce (<anonymous>)
    at buildSubsetForFont (react-pdf.browser.es.js:3776)
    at react-pdf.browser.es.js:3787
    at Array.map (<anonymous>)
    at ignoreChars (react-pdf.browser.es.js:3786)
    at getFragments (react-pdf.browser.es.js:3900)
    at getAttributedString (react-pdf.browser.es.js:3906)
    at Text.layoutText (react-pdf.browser.es.js:3985)
    at Text.measureText (react-pdf.browser.es.js:4012)

I have 3 instances of Components using main REPL code for Quixote https://react-pdf.org/repl

• Download: <QuixoteDownloadLink />
• Viewer: <QuixotePdfViewer />
• Blob: <QuixoteBlobProvider />

My code is simple aggregation and split.

When only Download, or only Viewer or only Blob rendered, all is OK. not errors. When Viewer renedered together with EITEHR Download or Blob, then I have that TypeError in console.

Most probably, @mmichelli is right, that we can’t use Viewer and other instances together.

I also tried both approaches of registering font: old:

Font.register(
    'https://fonts.gstatic.com/s/oswald/v13/Y_TKV6o8WovbUd3m_X9aAA.ttf',
    { family: 'Oswald' },
);

and new:

Font.register({
    family: 'Oswald',
    src: 'https://fonts.gstatic.com/s/oswald/v13/Y_TKV6o8WovbUd3m_X9aAA.ttf'
});

And sure thing, when I comment code related to Font.register I have no TypeError when I render all 3 components (Viewer, Download, Blob).

Note: I created separated issue for the outdated REPL code: #586

@diegomura could you plz confirm, that it was designed so, and if so, plz reflect it in README or doc page and close this issue? Is it an issue at all, or just wrong usage of @react-pdf/renderer API?

PS. I use MacOS v10.14.4, Node v11.14.0, React v16.8.6, Webpack v4.30, Babel v7.4.3, @react-pdf/renderer v1.5.4.

I have the same problem. I have ParentComponent, that map ChildrenComponents, in which I have <PDFDownloadLink>, that generates PDF for each child. The solution I found is next:

import React, { useEffect, useState } from 'react';
import { pdf } from '@react-pdf/renderer';
import PdfDocument from './PdfDocument'; // our PDF Document which would be downloaded

function Parent() {
  // data, which we get eg from server
  const childrenArray = [
    {
      id: 1,
      name: 'name-1',
      description: 'description-1',
    },
    {
      id: 2,
      name: 'name-2',
      description: 'description-2',
    },
    {
      id: 3,
      name: 'name-3',
      description: 'description-3',
    },
  ];

  const [children, setChildrenWithBlob] = useState(childrenArray);

  // here is all magic
  // !important: generate docs one by one
  async function createPDF() {
    const childrenWithBlob = [];
    let i = 0;

    while (i < childrenArray.length) {
      // eslint-disable-next-line no-await-in-loop
      await pdf(<PdfDocument data={childrenArray[i]} />)
        .toBlob()
        // eslint-disable-next-line no-loop-func
        .then(blobProp => {
          childrenWithBlob.push({
            ...childrenArray[i],
            url: URL.createObjectURL(blobProp),
            blob: blobProp,
          });
        });

      i += 1;
    }

    setChildrenWithBlob(childrenWithBlob);
  }

  // we generate pdf after componentDidMount
  useEffect(() => {
    createPDF();
  }, []);

  // get this code from @react-pdf/renderer
  const downloadOnIE = blobProp => () => {
    if (window.navigator.msSaveBlob) {
      window.navigator.msSaveBlob(blobProp, 'fileName.pdf');
    }
  };

  // need this instead of using <PDFDownloadLink>
  // 'cause have 2 triggers in each child component to download the same PDFDoc.
  // <PDFDownloadLink> didn't work for me
  const createTriggerToDownload = (child, trigger) => {
    const { blob, url } = child;

    return (
      <a href={url} download="fileName.pdf" onClick={() => downloadOnIE(blob)}>
        {trigger}
      </a>
    );
  };

  return (
    <>
      {children.map(child => (
        <div key={child.id}>
          {createTriggerToDownload(
            child,
            <button type="button">Download PDF</button>
          )}
          <div>{child.name}</div>
          <div>{child.description}</div>
          {createTriggerToDownload(
            child,
            <button type="button">Download</button>
          )}
        </div>
      ))}
    </>
  );
}

Hope this will help 😃

UPD: @diegomura thank u very much for this project ❤️

This is not a solution. It’s a workaround i’ve used that in my hook. Since it did not fit my architecture to render the pdf’s one by one i made a solution that will just retry if document creation fails. Works surprisingly well actually. Hope it can help someone out:

import React, { useEffect, useState } from 'react';
import { pdf } from '@react-pdf/renderer';
import TemplateLoader from 'templates/TemplateLoader';

interface OnPDF {
  loading: boolean;
  documentURL?: string;
}

function usePDF(resume: CV.Base): OnPDF {
  const [loading, setLoading] = useState(true);
  const [documentURL, setDocumentURL] = useState<string | undefined>();

  useEffect(() => {
    const generateBlob = async () => {
      let blob;
      let retryAttempts = 0;

      setLoading(true);

      do {
        // To circumvent race condition in @react-pdf when rendering
        // multiple PDF's with custom fonts simultaneously.
        try {
          blob = await pdf(<TemplateLoader resume={resume} />).toBlob();
        } catch (error) {
          // Render failed, let's try again but first some rest.
          await new Promise((resolve) => setTimeout(resolve, 500));
          retryAttempts++;
        }
      } while (!blob || retryAttempts > 3);

      setDocumentURL(window.URL.createObjectURL(blob));
      setLoading(false);
    };

    if (resume) {
      generateBlob();
    } else {
      setLoading(false);
      setDocumentURL(undefined);
    }
  }, [resume]);

  return { loading, documentURL };
}

export default usePDF;

Try to execute your function / loop with async-await promise.

Keep in mind that the bug will still present if you loop with forEach (parallel execution). Use a simple for … of to read/execute the files in sequence, and so avoiding any congestion while generating pdf files.

The key here is await first createPDF promise to be resolved, then u can execute next calls in parallel in any number desired, for instance like:

const createPDF = pdfContent => {
  const instance = pdf();
  instance.updateContainer(<MyDocument>{pdfContent}</MyDocument>);
  return instance.toBlob();
};

const = [firstContent, ...remainingContents] = pdfContentList;
const firstBlob = await createPDF(firstContent);
const remainingBlobs = await Promise.all(
  remainingContents.map(pdfContent =>
    createPDF(pdfContent),
  ),
);
const allBlobs = [firstBlob, ...remainingBlobs]

This is workaround of course, but for me it mitigated this issue.

@diegomura see the problem at https://codesandbox.io/s/jjjpp84v7y

I confirm that this only happens with custom font, so probably this is some kind of registration font race condition

So, I spent a lot of time today getting this module working with Redux and I wanted to make a few notes of my journey… not sure this is the best place… but maybe this could be some update to the doco? Also… this started out as a solution for the multiple distinct PDFs this thread discusses, but turned into something else, so sorry for the dump, but hope it helps someone.

Pretty much boils down to this innocent looking code:

<PDFDownloadLink 
  key={Math.random()} 
  document={   
    <Provider store={window.store}>
      <DocDefault />
    </Provider>} 
  ...

Notice DocDefault component is passed without any props because I assumed I could reference Redux state in the DocDefault component … but the problem is, when the referenced Redux state changes it tries to re-render the DocDefault component, which fails horribly (often causes a browser debugger crash), which I now clearly see is because it is inside the PDFDownloadLink component!

Once I finally figured out the issue was the re-render triggered by Redux, I was able to fix it.

So, essentially when integrating with a Redux project I would do one of these three things: 1) include the whole PDFDownloadLink component in the Document definition, or 2) pass the Redux variables as props, or maybe 3) reference the Redux store directly with getState(), anyway, I ended up doing 2) and removing all Redux mapStateToProps variables from DocDefault:

<PDFDownloadLink
  key={Math.random()}
  document={
    <Provider store={window.store}>
      <DocDefault printSize={printSize} printOrientation={printOrientation} data={data} />
    </Provider>  }
   ...

So I got this working with a setTimeout hack. (After trying a bunch of other things like moving the Font registration code around)

Firstly, the layout I have is a Sidebar component with some print options like page size, orientation, etc; a Topbar component with some action buttons including the download link; and lastly the main PDFViewer component.

Hack was to delay load the Topbar component containing the download link, after loading the PDFViewer. No doubt some sort of callback from React render of the PDFViewer component would be much more robust.

Code extract here cut down for clarity.

import React from 'react'
...

const styles = theme => ({ root: {} })

class Topbar extends React.Component {
  state = { load: false }

  componentDidMount () {
    window.setTimeout(this.setStartLoading.bind(this), 2000)
  }

  setStartLoading () { this.setState({ load: true }) }

  render () {
    const { load } = this.state
    if (!load) { return null }
    return (<DownloadLink doc={<Provider store={window.store}><MyPDFDocument/></Provider> } /> 
  }
}

Topbar.propTypes = { ... }
function mapStateToProps (state, ownProps) { return { ... } }
const mapDispatchToProps = dispatch => { return { ... } }

export default withRoot(withStyles(styles)(connect(mapStateToProps, mapDispatchToProps)(Topbar)))

@diegomura yeah, I tried it also with alpha.17, sry for consusion, I could prepare the example in this version in the 1st place. But Problem still occurs, tr to reload your example and click Get multiple blob, I just got error Unhandled Rejection (TypeError) Cannot read property 'hasGlyphForCodePoint' of null too.

Anyone stumbling on this who is using PDFDownloadLink, I ended up using this solution to generate the PDFs on user click and it ended up working!

@theobat use my sandbox as a base, because it really has it reproduced already - https://codesandbox.io/s/jjjpp84v7y but for older version, you could upgrade too see whether newest version is still affected by this issue.

For now I am still living with workaround I mentioned above