I'm working on an application that's entirely utf8 based and uses a wide range of non-

How does your HTML code start out? mine starts out like: <div class="snippet-clip

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

No worries <a class="user-mention notranslate" data-hovercard-type="user" data-hoverca

utf8 handling issue about pdfkit HOT 8 CLOSED

pdfkit commented on July 27, 2024

utf8 handling issue

from pdfkit.

Comments (8)

dburry commented on July 27, 2024

How does your HTML code start out? mine starts out like:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
        <meta http-equiv="Content-type" content="text/html; charset=utf-8" />

and it works fine for me with Chinese in it... Also using 1.8.7 (non-EE) If you were missing the content-type...charset=utf-8 meta tag, I'd imagine it behaving like you describe (since this is how Safari behaves without it too).

from pdfkit.

jystewart commented on July 27, 2024

Hmmm... thanks. Adding the meta tag seems to have resolved the problem. I'd not checked for that as the HTTP headers were already returning "text/html; charset=utf-8", but maybe the way pdfkit passes the data through doesn't preserve that? Seems worth a mention in the docs?

from pdfkit.

dburry commented on July 27, 2024

The underlying implementation is the wkhtmltopdf command line tool. For those who are generating or loading it internally, instead of pulling it from a remote source, there are no HTTP headers to confuse anyone on this point anyway. It could be possible I suppose to pass wkhtmltopdf remote HTTP headers when it's being pulled from an external HTTP source...

from pdfkit.

jystewart commented on July 27, 2024

Right, I understand that now, though it is initially confusing that when I made the request using the command line tool directly it handled the utf8 content just fine (which turns out to be because my command line usage was causing wkhtmltopdf to work over http, whereas pdfkit hands it a string)

That's all fine, and makes sense. At this point I'm simply suggesting that it would be sensible to add a note about this to the docs as for those of us primarily used to working with http and browsers it's not immediately apparent that the http headers have no effect here.

from pdfkit.

jessamynsmith commented on July 27, 2024

In case this helps anyone else, I was having an issue, even with the doctype and html. What helped was changing my code to this:

import codecs
import pdfkit

input_filename = 'input.html'
output_filename = 'output.pdf'

with codecs.open(input_filename, "r", "utf-8") as f:
    html_text = f.read()
    pdfkit.from_string(html_text, output_filename)

from pdfkit.

sigmavirus24 commented on July 27, 2024

@jessamynsmith this is the Ruby pdfkit project :)

from pdfkit.

jessamynsmith commented on July 27, 2024

Oops. Well, the doctype and html stuff still helped me. :)

from pdfkit.

sigmavirus24 commented on July 27, 2024

No worries @jessamynsmith :)

from pdfkit.

utf8 handling issue about pdfkit HOT 8 CLOSED

Comments (8)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent