Pdfmake: Invalid offset/length when creating typed array - pdfmake.js (24651,9) on Edge Windows 10

Created on 11 May 2016  Â·  30Comments  Â·  Source: bpampuch/pdfmake

After constructing my array to create a pdf all is ok on others browsers but on edge I got this error,
pdfMake.createPdf(dd).download('planning.pdf');
image

Most helpful comment

Hello Thanks for the hints - we faced the same problem and tracked it down to the Buffer-Methods used by pdfkit / pdfmake. The problem seems to be that Firefox and IE Edge are using the following constructor method for slicing / "subarraying" TypedArrays: new Uint8Array(buffer, offset, length). This constructor is not support by the current buffer implementation in pdfmake / pdfkit which seems to rely on a rather old node.js buffer implementation. The reason is, that the buffer implementation overwrites the constructor of the TypedArrays:

``````
/*
* Augment a Uint8Array *instance
(not the Uint8Array class!) with Buffer methods
*/
Buffer._augment = function _augment (arr) {
arr.constructor = Buffer <-- here it is overwriting

```The buffer.slice method uses the built-in method .subarray of the TypedArrays and the subarray method does the "subarraying" by calling the constructor with the offset and length parameters, which is not honored by the Buffer-constructor implementation:
``````

 * By augmenting the instances, we can avoid modifying the `Uint8Array`
 * prototype.
 */
function Buffer (arg) { <-- here, not offset and length

```As a result, the subarray is giving back the whole length instead of the length given by the length parameter, this leads to wrong deflate-results during pdf-generation and corrupted pdfs (incl. PNGs with tranparency, here it is the same problem)
The patch would be (it should work, but isn't tested on all browsers, but it works in IE Edge, Firefox 48 and Chrome on Windows 10 64 Bit): (sorry, I cannot give line-Numbers, but it is all in the Buffer-module of pdfmake):

     * By augmenting the instances, we can avoid modifying the `Uint8Array`
     * prototype.
     */
    function Buffer (arg, aOffset, aLength) { // scws patch: use Offest and Length as second and third parameter

pass these parameters to the following function:

          // Unusual.
      return fromObject(this, arg, aOffset, aLength) // scws patch : again, offset and length

then down to the next function:

    function fromObject (that, object, aOffset, aLength) { // scws patch
      if (Buffer.isBuffer(object)) {
      return fromBuffer(that, object)
    }

      if (isArray(object)) {
      return fromArray(that, object)
    }

      if (object == null) {
        throw new TypeError('must start with number, buffer, array or string')
      }

      if (typeof ArrayBuffer !== 'undefined') {
        if (object.buffer instanceof ArrayBuffer) {
          return fromTypedArray(that, object)
        }
        if (object instanceof ArrayBuffer) {
          return fromArrayBuffer(that, object, aOffset, aLength) // scws patch
        }

and, finally, construct the correct buffer:

    function fromArrayBuffer (that, array, aOffset, aLength) { // scws patch
      if (Buffer.TYPED_ARRAY_SUPPORT) {
        // Return an augmented `Uint8Array` instance, for best performance
        array.byteLength
        that = Buffer._augment((aOffset == null ?  new Uint8Array(array) : new Uint8Array(array, aOffset, aLength))) // scws patch: check aOffset for null or undefined and use the old constructor, if aOffset is not set, aLength is optional, so check only for aOffset -> if this is set, aLength can be omitted, the underlying constructor will honor this
      } else {
        // Fallback: Return an object instance of the Buffer class
        that = fromTypedArray(that, new Uint8Array(array))
      }
      return that
    }

I hope, this helps somebody!

All 30 comments

I have found this issue as well when I try to embed an image into the output file.

Chrome and Safari work fine and the image is embedded, Firefox embeds a blank image but that's probably a result of something else on not this library, but IE, not just Edge, from 10 and up, it prevents the export.

I have this issue too, for IE and edge
is there any way to fix this?

Having the same problem. Anyone?

I am having the same problem, cannot embed image into output file in edge...

I've just run into this problem as well.. I dont have Win10/Edge, so I'm doing compatibility testing with browserstack.com. "Invalid offset/length when creating typed array" is showing up for me when creating the pdf in Win10/Edge13 only. When I use Win10/Edge12 (or Chrome/FF/IE10+/Safari), the pdf is generated correctly.

Somehow, neither Edge browser works on the pdfmake playground page - just get a blank pdf doc.

I have issue too, only MS Edge
Chrome/FF is OK.

Same issue here.

Hi, I have the same problem, any solution to fix that? On chrome, firefox, works fine.
Error: "Invalid offset/length when creating typed array"

@bpampuch Same error for me. Does anyone have a way to catch the error in order to show the user a message saying that the feature is 'not supported'? I tried using try/catch when calling pdfMake.createPdf but it does not work.

I think I'm seeing a similar error now with the latest version of Firefox (v48).

RangeError: invalid array length

Note: the error only occurs when I include images in the PDF.

It seems to be the handling for arrays. I commented out the lines 24650 - 24653 as a workaround:

var fnTyped = {
arraySet: function (dest, src, src_offs, len, dest_offs) {
// if (src.subarray && dest.subarray) {
// dest.set(src.subarray(src_offs, src_offs+len), dest_offs);
// return;
// }
// Fallback to ordinary array
...

There is fallback code from the original author which works at least for all browsers I tested so far. There still will be the issue with missing transparencies (#660). I have no further information if it has any other consequences, so use it at your own risk.

Thanks for the workaround/fix @sluo86, it's seems to be working well for us.

Works for me!

Thank you

From: sluo86 [mailto:[email protected]]
Sent: Monday, August 8, 2016 5:43 AM
To: bpampuch/pdfmake [email protected]
Cc: Bradley Bell bradley.[email protected]; Comment [email protected]
Subject: Re: [bpampuch/pdfmake] Invalid offset/length when creating typed array - pdfmake.js (24651,9) on Edge Windows 10 (#577)

It seems to be the handling for arrays. I commented out the lines 24650 - 24653 as a work-around:

var fnTyped = {
arraySet: function (dest, src, src_offs, len, dest_offs) {
// if (src.subarray && dest.subarray) {
// dest.set(src.subarray(src_offs, src_offs+len), dest_offs);
// return;
// }
// Fallback to ordinary array
...

There is a fallback code for that which works at least for all browsers I tested so far. There still will be the issue with missing transparencies. I have no further information if it has any other consequences, so use it at your own risk.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/bpampuch/pdfmake/issues/577#issuecomment-238223949 , or mute the thread https://github.com/notifications/unsubscribe-auth/ARjs0hcf_9wPcPqk1oaAER2aWvw9OCG7ks5qdyRigaJpZM4IcDix . https://github.com/notifications/beacon/ARjs0qxGGc4-0-ZgFusA4QW3HUwMokFCks5qdyRigaJpZM4IcDix.gif


This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Hello Thanks for the hints - we faced the same problem and tracked it down to the Buffer-Methods used by pdfkit / pdfmake. The problem seems to be that Firefox and IE Edge are using the following constructor method for slicing / "subarraying" TypedArrays: new Uint8Array(buffer, offset, length). This constructor is not support by the current buffer implementation in pdfmake / pdfkit which seems to rely on a rather old node.js buffer implementation. The reason is, that the buffer implementation overwrites the constructor of the TypedArrays:

``````
/*
* Augment a Uint8Array *instance
(not the Uint8Array class!) with Buffer methods
*/
Buffer._augment = function _augment (arr) {
arr.constructor = Buffer <-- here it is overwriting

```The buffer.slice method uses the built-in method .subarray of the TypedArrays and the subarray method does the "subarraying" by calling the constructor with the offset and length parameters, which is not honored by the Buffer-constructor implementation:
``````

 * By augmenting the instances, we can avoid modifying the `Uint8Array`
 * prototype.
 */
function Buffer (arg) { <-- here, not offset and length

```As a result, the subarray is giving back the whole length instead of the length given by the length parameter, this leads to wrong deflate-results during pdf-generation and corrupted pdfs (incl. PNGs with tranparency, here it is the same problem)
The patch would be (it should work, but isn't tested on all browsers, but it works in IE Edge, Firefox 48 and Chrome on Windows 10 64 Bit): (sorry, I cannot give line-Numbers, but it is all in the Buffer-module of pdfmake):

     * By augmenting the instances, we can avoid modifying the `Uint8Array`
     * prototype.
     */
    function Buffer (arg, aOffset, aLength) { // scws patch: use Offest and Length as second and third parameter

pass these parameters to the following function:

          // Unusual.
      return fromObject(this, arg, aOffset, aLength) // scws patch : again, offset and length

then down to the next function:

    function fromObject (that, object, aOffset, aLength) { // scws patch
      if (Buffer.isBuffer(object)) {
      return fromBuffer(that, object)
    }

      if (isArray(object)) {
      return fromArray(that, object)
    }

      if (object == null) {
        throw new TypeError('must start with number, buffer, array or string')
      }

      if (typeof ArrayBuffer !== 'undefined') {
        if (object.buffer instanceof ArrayBuffer) {
          return fromTypedArray(that, object)
        }
        if (object instanceof ArrayBuffer) {
          return fromArrayBuffer(that, object, aOffset, aLength) // scws patch
        }

and, finally, construct the correct buffer:

    function fromArrayBuffer (that, array, aOffset, aLength) { // scws patch
      if (Buffer.TYPED_ARRAY_SUPPORT) {
        // Return an augmented `Uint8Array` instance, for best performance
        array.byteLength
        that = Buffer._augment((aOffset == null ?  new Uint8Array(array) : new Uint8Array(array, aOffset, aLength))) // scws patch: check aOffset for null or undefined and use the old constructor, if aOffset is not set, aLength is optional, so check only for aOffset -> if this is set, aLength can be omitted, the underlying constructor will honor this
      } else {
        // Fallback: Return an object instance of the Buffer class
        that = fromTypedArray(that, new Uint8Array(array))
      }
      return that
    }

I hope, this helps somebody!

As you can See above, I forked pdfmake and applied the provided fix.
This is not a real solution since I also only changed the already builded js file. I cannot build my own. See:
https://github.com/bpampuch/pdfmake/issues/598

@FastestRobot @tsiegleauq Legends!

I've run this update in IE Edge, IE11, Chrome, Firefox, Firefox Mobile, Chrome mobile and all seems to be working.

I've minified it here:
https://gist.github.com/hutch120/214780327fd5d726006940143860832b

And I've combined that with vfs_fonts library here if you are delay loading:
https://gist.github.com/hutch120/8ce1a0e95a0bbd4011ed3804352b6a75

Hey guys, I honestly think bpampuch/pdfmake is depracted, but I might be completely wrong.

the current Master does not build anymore and @bpampuch seems to be inactive since May 18 (also see this).

When we started using bpampuch/pdfmake, we did not notice that.
However, the project seems to be further developed unter pdfmake/pdfmake by @miltador who is currently active (last commit to the project in July)

We consider changing to this project (it has the same basis, even to webpage looks the same though) and I try to get a patch upstream for this issue (if this even exist in pdfmake/pdfmake) asap.

@FastestRobot Yes, this is because the Buffer library (via Browserify/npm) used by pdfmake is outdated. Updating the library is enough to fix it -- no need for manual patching. Building with a newly-installed copy of browserify from npm pulls in [email protected].

webpack also seems to pull in 4.9.1.

Unfortunately, I can't seem to build pdfmake master at the moment, as tsiegleauq mentioned.

I noticed this a couple months ago but apparently forgot to open an issue here - sorry! https://bugzilla.mozilla.org/show_bug.cgi?id=1277784

@Elusive138, thanks a lot for this suggestion. I tested it and it worked just as you described.
I consider pdfmake/pdfmake as the new way to go, since the original autor of pdfmake seems inactive.
I made a pull request to pdfmake/pdfmake were browserify is updated to 5.0.0, which solved the problem for me

Hi. Can you make a release with that fix, please?

Hi @tsiegleauq can you please share me that file because I am not too familiar with browserify so it will help me, Or please tell me the steps so that I will do it by my self.
Thanks

@tsiegleauq pdfmake/pdfmake used to solve this issue for me but our last build just failed today as the repository was removed. Anyone has a fork of pdfmake/pdfmake?

@mikaoelitiana you don't have to use pdfmake/pdfmake fork anymore. It is merged back to this one, and development continues here. While there is no ETA for a new release, I recommend you to try out latest master.

@miltador thanks! I will try with latest master then and let you know.

@miltador latest master from this repo doesn't solve the problem yet so I finally had to use fork from @tsiegleauq https://github.com/tsiegleauq/pdfmake.git to make it work.

@mikaoelitiana
sry for responding late. I am quite busy recently.
You are right, the current release will not work. You can use the latest master of bpampuch/pdfmake to have your problem solved - the current release of bpampuch/pdfmake is still (far) older than the depracted and removed pdfmake/pdfmake release or the current release on my own fork. Once bpampuch/pdfmake releases a new version you can switch back to it.

Or just configure your bower.json like the following to get this commit
(this is also what I do for our project OpenSlides)

"dependencies": {
    "pdfmake": "bpampuch/pdfmake#3b44129d599424cd0e306fc5014ba3a129220c64",
},
"overrides": {
    "pdfmake": {
      "main": [
          "build/pdfmake.min.js",
          "build/vfs_fonts.js"
      ]
},

that strange number behind the "#" (3b44129d599424cd0e306fc5014ba3a129220c64) is the extracted from the URL.
Or you can simply stick with my fork of pdfmake/pdfmake
But I will probably remove this in order to fix things in bpampuch/pdfmake later.

@tsiegleauq thanks for these details. For now I will use your fork and on next release of bpampuch/pdfmaker, I can swithc back to in (when this issue is officially closed I guess)

@mikaoelitiana Currently should be all changes from pdfmake/pdfmake transferred to this repo. It should work. Conducted you rebuild?
Due to different testing I make test build https://github.com/bpampuch/pdfmake/commit/214ec161c11fadb8f02c08f2e3bea0576ac4c9fb . Can you try it?

@liborm85 I have tested this build and it works fine for me. Thanks

New version released.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

qgliu picture qgliu  Â·  3Comments

michaelqiji picture michaelqiji  Â·  3Comments

CharlyPoppins picture CharlyPoppins  Â·  3Comments

einfallstoll picture einfallstoll  Â·  3Comments

MathLavallee picture MathLavallee  Â·  3Comments