lucy24
msg:4534969 | 10:55 am on Jan 10, 2013 (gmt 0) |
Option C is to edit your include files-- just the html output, nothing else-- to replace any non-ASCII characters with HTML entities. (And tell the php not to change them back!) I do not like this approach. But it is definitely safe. And it's less complicated than putting in a whole new routine to change the text encoding of the output. I don't know how you would even do that without editing the line that calls the include.
:: thinking ::
Suppose you coded the include files to say "If such-and-such parameter is present, then use it to set the file encoding of the output; otherwise default to UTF-8." The idea is to make the include file do something new without having to change all existing pages to make them pass an additional variable.
Do your include files also read data that's stored as UTF-8? So they would also have to convert any text they work with? You can see where Option C starts looking not too bad ;)
...
Now just watch. Next week your fpdf will come out with a version that does support utf-8.
|
helenp
msg:4534979 | 11:52 am on Jan 10, 2013 (gmt 0) |
Yes I use it on utf-8 files, the only iso file is the one for creating the pdf.
Are you the developer of fpdf lol?
|
swa66
msg:4535022 | 2:58 pm on Jan 10, 2013 (gmt 0) |
I remember reading that fpdf does support UTF-8 ...
[fpdf.org...]
|
helenp
msg:4535068 | 5:11 pm on Jan 10, 2013 (gmt 0) |
I remember reading that fpdf does support UTF-8 ...
[fpdf.org...] |
|
Wow, thanks for that, its a modified version,
I read everywhere except there not to use utf-8 :(
I think lucy can read the future lol, it is supported but before next week.
|
helenp
msg:4535464 | 11:18 am on Jan 12, 2013 (gmt 0) |
Í found this that does suppost utf-8 and is very compex, maybe a bit complex and slow, but I do recomend it:
[tcpdf.org...]
|
|
