Split text cannot handle Unicode

[lordofscripts]

See for more details:

go-pdf/fpdf#69

The SplitText method is panicking when it encounters Unicode characters.

I am using Arial & Times, both have M Dash. However, as I pointed, SplitText only knows 256 characters, not suitable for Unicode. If not, it could at least assume a reasonable value and also check so that it doesn't panic.

[vantaboard]

@lordofscripts can you expand on this issue? This is a different library than the one you are referencing. Can you provide a sample code that reproduces the error?

[lordofscripts]

For what I could see yours is a fork of that one; therefore, it is likely to suffer from the same, especially because it is one of those rare -yet valid- use cases.

As for expanding on the issue, look at the referred issue where I mention which special characters are found in the "offending" text that causes it to panic.

[vantaboard]

For what I could see yours is a fork of that one; therefore, it is likely to suffer from the same, especially because it is one of those rare -yet valid- use cases.

As for expanding on the issue, look at the referred issue where I mention which special characters are found in the "offending" text that causes it to panic.

Sorry, I meant do you have a snippet of code that reproduces this bug? It would make it easier for me to look into.

[lordofscripts]

See my original post mentioned above of go-pdf/fpdf Issue #69. There I clearly mention at least three characters that, when present in a string, cause FPDF to throw the error.

[vantaboard]

See my original post mentioned above of go-pdf/fpdf Issue #69. There I clearly mention at least three characters that, when present in a string, cause FPDF to throw the error.

If you cannot provide a code snippet, then I cannot help you with your issue. This is not the FPDF library. It is drastically different. I need a reproduction from you.

[lordofscripts]

Well it is simple to reproduce. This is a fork of FPDF, if it was "considerably different" it would have been written from scratch. Anyway, it's your repository, if you are not willing to debug it then who will. As I said you only have to put those special Unicode character in any string and try to feed it to the library.

[vantaboard]

Well it is simple to reproduce. This is a fork of FPDF, if it was "considerably different" it would have been written from scratch. Anyway, it's your repository, if you are not willing to debug it then who will. As I said you only have to put those special Unicode character in any string and try to feed it to the library.

It was written from scratch. You are mistaken on this.

The first commit to this repository was b99beca

commit b99beca
Author: oneplus1000 [email protected]
Date: Thu Feb 14 18:16:06 2013 +0700

which is a full 170 days before Kurt Jung would make the initial commit to go-pdf/fpdf with go-pdf/fpdf@caed6a3

commit caed6a338466079a637af39db2836b5f4b1771a9
Author: Kurt Jung [email protected]
Date: Fri Aug 2 14:59:27 2013 -0400

This is also not my repository. It is developed and maintained by @oneplus1000.

Both libraries were heavily inspired by http://www.fpdf.org/, a PHP library for PDF generation, but are developed and maintained independent of each other.