CoreCommunity ExtensionsIncubatorDistributionsTYPO3 4.5 ProjectsTYPO3 4.7 ProjectsTYPO3 6.0 ProjectsTYPO3 6.1 ProjectsTYPO3 6.2 Projects (+)

Bug #6171

Character set problems in header and footer text

Added by Steffen Müller over 3 years ago. Updated over 2 years ago.

Status:Needs Feedback Start date:2010-01-22
Priority:Should have Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Votes: 0

Description

Moved from #6156:

Finally, I had problems with adding special characters to the pdf header or footer. It's a character encoding problem, but I am not sure where exactly it goes wrong. I could only solve it by translating to ISO-8859. I added html_entity_decode so that you can use things like © in Typoscript and they will appear properly in the pdf. Site and database are all set to UTF-8. Could it be an issue of the wkhtmltopdf script, or could it be that the server uses ISO-8859 in the exec command?

I can confirm. The same happens to me when using german "Umlaute".

I tried to reproduce from a shell using UTF-8: still broken characters. So it seems to be an upstream problem of the wkhtmltopdf script.

6171.diff (1020 Bytes) Steffen Müller, 2010-01-22 16:57


Related issues

follows WebKit PDF - Feature #5834: wkhtmltopdf 0.9 Resolved 2009-12-22

History

Updated by Steffen Müller over 3 years ago

If we decide to provide a workaround, we should use proper checks and transformation from class t3lib_cs instead of PHP html_entity_decode().

Updated by Steffen Müller over 3 years ago

Appended patch adds a charset conversion workaround.

Please also test in non-UTF-8 environments. I don't have one.

Updated by Steffen Müller over 3 years ago

  • Status changed from New to Needs Feedback

Updated by Steffen Müller over 3 years ago

The issue has been fixed in upstream 0.9.0: http://code.google.com/p/wkhtmltopdf/wiki/ChangeLog

I propose to upgrade to 0.9.0 instead of using the workaround.

Updated by Reinhard Führicht over 3 years ago

Problem is, that version 0.9.0 fails to load the additional style sheet in --user-style-sheet.
I think this is a huge bug and therefore wanted to wati until 0.9.1 to make an update.

Updated by Reinhard Führicht over 3 years ago

On second thought, maybe we should upgrade to version 0.9.1.
The --print-media-type setting can be used as a workaround for the non-working --user-style-sheet in most cases.
What do you think? Would this solve this issue?

Updated by Steffen Müller about 3 years ago

I would not update to 0.9.x as long as the --user-style-sheet bug is fixed. Even if --print-media-type would be a workaround, upgrading will break existing installations. I don't like that.

As soon as upstream fixes that, I'd upgrade to 0.9.x and close this issue. Until then I'd leave this bug as it is. The patch can be used as a workaround.

The only question is what we should do if upstream will not fix that one until stable release.

Also available in: Atom PDF