JavaScript PDF viewer does not display correctly

Posted by: eric on 30 June 2019, 3:05 pm EST

  • Posted 30 June 2019, 3:05 pm EST

    Hi, We are interested in your JavaScript PDF viewer.
    But it does not display correctly on some PDF files.
    Attached is a sample file for your reference.

    Is there any chance to fix it?
  • Replied 30 June 2019, 8:15 pm EST

    Hello Eric,
    We are sorry for the inconvenience, we are able to replicate the issue and it has been forwarded to the concerned team for further investigation with internal id DOC-1317.

    We will let you know as we get an update on this.

    Manish Gupta
  • Replied 4 July 2019, 8:35 am EST

    Hi Eric,

    There are two specific things that combined in this PDF to cause the problem:

    - The content that is not shown is a rich text annotation (which is a kind of HTML). In the current version of our viewer, we just use the default browser style (including padding) unless it is specified explicitly in the rich text. In this particular PDF, the padding is not specified - but Acrobat uses zero padding in such cases while we used default browser's (which is not zero). This caused the text to scroll out of the window. This issue is fixed in the new version of our viewer (which is included in the sample attached to this message, see below).

    - Additionally, the font specified in the annotation is not embedded in the PDF, so a default font would be used unless a suitable font is found. As far as I could determine, a monospace font is suitable in this case, so in the attached sample I included an open font that produced suitable result. (BTW, even Acrobat Reader and Acrobat Pro show this text differently on my system.)

    Attached is the sample that (a) includes a new version of our viewer (0.7.21, will soon be uploaded to our server/npmjs), and (b) specifies a suitable font for the annotation so that it aligns correctly.

    Hope this helps.
  • Replied 4 July 2019, 3:38 pm EST

    Thanks for your quick reply. I am very impressed for your support.

    Here are two more files that can't display display correctly.

  • Replied 5 July 2019, 12:24 am EST

    Hi again Eric,

    Thanks for your post/new issues (really :) ). The problem with these files is different, it is caused by the fact that some uncommon CMaps are used in those PDFs. We are working on providing a resolution for this, for your reference the issue id is DOC-905. I'll keep you posted on the progress.

    (Just FYI, this is similar to what is demonstrated by our server-side component's sample - but of course, in this case we need a client side solution.)

  • Replied 8 July 2019, 3:09 am EST

    Update: we added support for external CMaps, the new build 0.7.22 should be available soon, and is included in the attached sample. (BTW, the DOC-905 id in my previous message was a typo, the correct one is DOC-1328).

    Let me know whether this helps.
  • Replied 8 July 2019, 3:51 pm EST

    Hi dmitry.yaitskov,

    This problem doesn't seem to have been solved or worse in None of the three PDFS are displayed correctly.

    REQ1409073.pdf has been fixed at 4 July but It's also broken now.

  • Replied 10 July 2019, 1:26 am EST

    Hi again,

    As I mentioned, your PDFs include texts that require external CMaps. In build .22 we added support for those, and added the external cmaps in the resource/bcmaps directory. The files in that directory have .bcmap extension, which is not by default understood by web servers (e.g. IIS). So to ensure that those files are available to the control when it is served by the web server, a small piece of code needs to be added to the app's startup. It is documented in the version.txt file that would be included in a proper release, but unfortunately I did not include it in the sample, sorry. If you look in the CoreApp\Startup.cs file in my zip, you will see this:

    var provider = new FileExtensionContentTypeProvider();
    provider.Mappings[".bcmap"] = "application/octet-stream";
    app.UseStaticFiles(new StaticFileOptions()
    ContentTypeProvider = provider

    This, and the wwwroot\resource directory, are required for the external CMaps to work in build .22.

    But, upon reviewing this case we decided that we will change the cmap files' extension to .bin so that they will be served by default. So basically, most of what I wrote above is moot, later today I will post a new build that should work by default (you will still need to copy the wwwroot\resource directory though). Stay tuned :)

    And BTW, many thanks for your feedback - hopefully it will help us to improve the viewer and make it more user-friendly.

  • Replied 10 July 2019, 4:54 am EST


    Attached is the sample with the new version. Please try it, in my tests all your files show correctly. Let me know.

  • Replied 10 July 2019, 2:13 pm EST

    Hi dmitry.yaitskov,

    Many thanks for your work. You are one of the very few component vendors willing to respond and fix problems with Chinese character display in PDF. Thank you (really).

    It is almost correctly In Only one thing is different with the Adobe Reader. The font type of Chinese characters are incorrect.

  • Replied 11 July 2019, 12:48 am EST

    Hi Eric,

    As was mentioned earlier, the font in question is not embedded in the PDF. Hence it should be made available to the viewer, otherwise the viewer will use a substitute font (as is the case here). (Acrobat has full access to the fonts installed in the OS, hence it shows the correct font if it is installed, but the browser does not.)

    To fix this, you need to find the correct font (shown in the attached image), convert it to .woff (e.g. here, and make it available on your page by adding something like this:

    @font-face { font-family: 'DFKaiShu'; src: url('MicrosoftKaitiFontSimplifiedChinese.woff') format('woff'); }
    div.gc-viewer { font-family: 'DFKaiShu'; }

    Hope this helps. Let me know.

  • Replied 11 July 2019, 8:30 pm EST

    Hi Dmitry,

    It's worked after add font-face and font file.
    @font-face { font-family: 'DFKaiShu'; src:local("DFKai-SB"); }
    div.gc-viewer { font-family: 'DFKaiShu'; }

    It's also worked without add woff font to site. Because the font "DFKai-SB" is default install into Chinese version of windows .

    I have one question for the style " div.gc-viewer { font-family: 'DFKaiShu'; } "
    If there is an another kind of font(named "Microsoft JhengHei") not embedded in the PDF. It will show DFKaiShu to replace "Microsoft JhengHei" in PDF ?

    There is one more PDF have problems.

    1. The THUMBNAILS is Weird on display between page 10 and 11 .

    2. How to let print preview same as page in display ?
    Print preview

    Same page display in viewer
  • Marked as Answer

    Replied 15 July 2019, 4:17 am EST

    Hi Eric,

    Thanks again for providing your feedback. We have fixed the thumbnail and print preview issues you found, the fixed build is attached - just unzip it, and copy the following files/dirs from it:

    • build\gcpdfviewer.js

    • build\gcpdfviewer.worker.js

    • build\resources

    • build\themes

    When printing, you may get empty pages in some cases due to browser print margins. JS code cannot control those, so you may have to adjust (set to none) the margins yourself.

    Re woff fonts - this format has the best browser support, hence the recommendation to use it.

    Re specifying other fonts - you may use the following approach:

    <link rel="preload" href="MicrosoftKaitiFontSimplifiedChinese.woff" as="font" type="font/woff" crossorigin />
    <link rel="preload" href="JhengHei.woff" as="font" type="font/woff" crossorigin />
    @font-face { font-family: 'DFKaiShu'; src: url('MicrosoftKaitiFontSimplifiedChinese.woff') format('woff'); }
    @font-face { font-family: 'AnyOtherFontFace; src: url('MicrosoftKaitiFontSimplifiedChinese.woff') format('woff'); }
    @font-face { font-family: 'JhengHei'; src: url('JhengHei.woff') format('woff'); }

    Hope this helps. Let me know.
  • Replied 19 July 2019, 1:28 am EST

    Hi Dmitry,

    It works. Thank you.

    I want discuss one thing. Is Viewer can do that load pdf file from remote url and lazy load for each page?
  • Replied 19 July 2019, 6:04 am EST

    Hi Eric,

    Glad it works!

    Re lazy load - you need a linearized PDF for this, our viewer does support such files, we have a sample where GcPdf creates a linearized PDF and the viewer shows it:

    Generally speaking, a PDF is not just a sequence of independent pages, they may have links to other resources elsewhere in the PDF file, so lazy loading of pages is only possible for PDFs specifically prepared for that - that's what linearized PDF are for.

    Hope this helps,

    P.S. I will mark my previous message as answer for this thread if you don't mind. But do let me know if you encounter any other issues.
  • Replied 19 July 2019, 2:02 pm EST

    Hi Dmitry,

    Load PDF from remote url like the following? The Viewer will support lazy loading if I convert sample.pdf to linearized PDF.

    function loadPdfViewer(selector) {
    var viewer = new GcPdfViewer(selector);
  • Replied 25 July 2019, 4:52 am EST

    Hi Eric,

    Sorry for the belated reply. Yes, the code you posted should do 'lazy loading' if the PDF is a linearized one.

    Hope this helps.
Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels