Split text cannot handle Unicode
lordofscripts opened this issue · 7 comments
See for more details:
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.
@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?
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.
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.
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.
See my original post mentioned above of
go-pdf/fpdfIssue #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.
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.
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 oneplus1000@gmail.com
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 kurt.w.jung@code.google.com
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.