translateFont failed: "FormatError: unexpected EOF in bcmap"

[severinkl]

Check this first The project is a wrapper around Mozilla's PDF viewer, so maybe your bug is caused by the base library. Please check this first by answering these three questions:

• Does the bug also happen on https://mozilla.github.io/pdf.js/web/viewer.html? (If so, please open the issue at Mozilla's bugtracker). <-- NO
• Does the bug also happen on https://pdfviewer.net/simple? <-- YES
• Can you write a reproducer based on this template project? https://github.com/stephanrauh/ngx-extended-pdf-viewer-issues/tree/main/template <-- YES

Describe the bug When the given demo PDF is opened, no font is loaded.

Displayed console messages:

• Warning: loadFont - translateFont failed: "FormatError: unexpected EOF in bcmap".
• Warning: Error during font loading: unexpected EOF in bcmap

Version info 15.0.0-alpha.2.

Desktop (please complete the following information):

• Chrome but most probably all Browsers

To Reproduce Can you provide a reproducer? That's a small and simple but complete project demonstrating the bug. It's always a good idea to start from a fresh, new project. There's a template project at https://github.com/stephanrauh/ngx-extended-pdf-viewer-issues/tree/main/template. A side effect is that writing a reproducer often helps you to find bugs of your code. This spares me the embarrassement of pointing our you bugs. More important, it saves me a lot of time. ngx-extended-pdf-viewer has become so popular that answering issues costs a lot of my spare time, so I appreciate your help.

Reproducer: https://github.com/severinkl/ngx-extended-pdf-viewer-issues/blob/main/issue1485/

If you really can't provide me a reproducer, please tell me how to reproduce the behavior:

1. Go to https://pdfviewer.net/extended-pdf-viewer/simple
2. Click on Open File
3. Upload Demo Error
4. No font displayed

Demo PDF file Many errors happen with specific PDF files only. So please add a PDF file (after checking the copyright of the PDF file first!)

AE220531002_INV.pdf

Screenshots

Thank you! No, thank you!

[stephanrauh]

Thanks a lot for providing such a detailed error description and even a reproducer! I was able to start debugging within minutes. Awesome!

[stephanrauh]

Is this a new bug? I went back to ngx-extended-pdf-viewer, so I suspect it's an old bug, but I don't understand it. Maybe it's got something to do with your PDF document? I wonder if the PDF refers to a font called assets/cmaps/GBK-EUC-H.bcmap instead of simply loading GBK-EUC-H.bcmap. But I'm not sure if that's possible, so it's just a wild guess.

What I've found is that the fonts are loaded from the wrong path. There's a double assets folder. If you application sends an error page, the PDF viewer tries to interpret it as a font and fails. If it doesn't send an error message, you see the 404 error message.

Here's a quick workaround. Definitely not a solution, but it'll help you until I figure out what the real problem is:

export class ExamplePdfViewerComponent {

  constructor(private pdfService: NgxExtendedPdfViewerService) {
    // TODO the PDF viewer should work without the next line - it's merely a workaround:
    pdfDefaultOptions.cMapUrl= () => `/assets/cmaps/`;

  }
}

[severinkl]

Is this a new bug?

I first encountered it with version 14.5.0, than updated and it still appeared. Might very well be there for some while already.

I also recall that we investigated a similar bug in regards to the cmaps path in 2020, not sure if in any way related though: https://stackoverflow.com/questions/64009399/ngx-extended-pdf-viewer-not-displaying-text-wrong-cmaps-path

Here's a quick workaround

Thanks, the workaround works in the reproducer!

And thanks again for your fast response!

[stephanrauh]

Well, I'm happy if you're happy. :) It's hard to explain, but the plethora of happy responses of formerly desperate developers, well, it's simply rewarding!

I've looked up your StackOverflow question. It's interesting I suggested an almost identical workaround two years ago. It's an indicator that determining the correct path for cmaps is a hard problem.

And of course, that's a drawback of my strategy of always adopting the latest changes of pdf.js as early as possible: their quality is very high, but my fork of pdf.js has diverged a lot, so I have to merge their latest changes into my codebase. And every once in a while, there's an undetected merge conflict or a faulty merge conflict resolution. Sometime that's really annoying. On the plus side, it allows me to offer you new features of pdf.js early.

[stephanrauh]

To dos left:

• [x] find out where the duplicate assets folder comes from
• [x] do something about it (if that's possible at all)

[stephanrauh]

I've managed to reproduce the issue with multiple PDF files. If using the bleeding-edge branch, the duplicate assets/assets folder of the URL become bleeding-edge/bleeding-edge. So it's definitely something I should fix.

[stephanrauh]

@bonbonmark This bugticket remembles the issue you've reported in #1104. In fact, your test document doesn't render with the current version. I went all the way back to version 11.0.1 where I've fixed support for Chinese fonts - but even so, it seems to be broken. Did it ever work in your project?

[stephanrauh]

Found it! The cMapUrl path is relative to the pdf.worker-*.js file. The latter is already in the assets folder.

[stephanrauh]

The bugfix ships with version 15.0.0.

[severinkl]

Thanks a lot!