Print UTF-8 encoded wiki pages

Steps to reproduce? Trac version? System (Windows / Linux / ...)? WSGI / mod_wsgi?

Thanks.

I've the same problem.

Debian Lenny Apache 2.2.9-10+lenny7 trac 0.11.1-2.1

Turkish Characters İ,ı,ö,Ö,ç,Ç,ğ,Ü,ş,Ş are printed as ?

I've corrected this behavior with setting default charset as utf-8 in trac.ini. It was iso-8859-9

I've also changed default charset to utf-8, and HTML pages are printed correctly. PDF articles instead of characters contain black squares.

Linux Trac: 0.11.5 Python: 2.4.3 (#1, Jan 21 2009, 01:11:33) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] setuptools: 0.6c11 SQLite: 3.3.6 pysqlite: 1.1.7 Genshi: 0.5.1 mod_python: 3.2.8 Subversion: 1.6.5 (r38866) jQuery: 1.2.6

any news, eh?

Sorry I'm not able to reproduce this behaviour or my system. Could you enable logging on the trac project, try to generate a PDF and attach the log output here?

Thanks.

prinf as html

print as pdf

Replying to airadier:

Sorry I'm not able to reproduce this behaviour or my system. Could you enable logging on the trac project, try to generate a PDF and attach the log output here? Thanks.

I've also changed default charset to utf-8. This is in russian.
as html - correct

as pdf

Ok, I'll try to reply it when I get some time. It could be a problem with missing fonts when generating PDF, as it worked for me with latin UTF-8 characters. I'll try russian or other languages.

Replying to airadier:

Ok, I'll try to reply it when I get some time. It could be a problem with missing fonts when generating PDF, as it worked for me with latin UTF-8 characters. I'll try russian or other languages.

need Korean too : )

This is weird, though. I have reproduced the error on my system - working HTML and non-working PDF. I have manually supplied the TTF font to both the webserver and shell. I have downloaded the 'printhtml' file and run 'xhtml2pdf printhtml.html' manually. I got a beautiful PDF with all the correct characters. Debian Lenny, Trac 0.12.1, tracwikiprint 1.8.4, pisa 3.0.33

Cheers!

the problem is connected with incorrect fonts. Try supplying css with following code in the beginning:

@font-face {
font-family: LiberationSans;
src: url("/usr/share/fonts/truetype/ttf-liberation/LiberationSans-Regular.ttf");
}

html {
    font-family: LiberationSans; 

Tested on debian unstable, works for Russian

snegovick, could you put your whole CSS file? It seems that just those two lines don't help me.

css

try wikiprint.css (copied from debian unstable host where russian works)

I had the same problem with Japanese fonts (black squares appearing instead of the ideograms) on my Ubuntu server.

This problem seem to have been solved by installing the ttf-sazanami-mincho font

 sudo aptitude install ttf-sazanami-mincho

and by adding the following code to the beginning of the CSS file

@font-face {
        font-family: Sazanami;
        src: url("/usr/share/fonts/truetype/sazanami/sazanami-mincho.ttf");
        }

I haven't yet check it extensively, but it seems that the output is correct.

Thanks for this nice package

See #8470 for another possible fix.

Hello,

I used 1.9.2 with trac 0.12.2-1 from debian wheezy, same error: correct html and no fonts embedded in pdf. The problem was that allow_local was False in wikiprint.py, causing linkloader to treat urls as relative (fonts as well), and append referrer paths to them, making logs like that (10456 was a ssh forwarded port on laptop, and i connected to loopback address):

2011-10-10 23:58:36,060 Trac[wikiprint] DEBUG: WikiPrint.linkLoader ERROR: <urlopen error [Errno 111] Connection refused>
2011-10-10 23:58:36,060 Trac[wikiprint] DEBUG: WikiPrint.linkLoader => Relative path /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-BoldOblique.ttf to https://127.0.0.1:10456/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-BoldOblique.ttf

Setting allow_local to True by default fixed font embedding for me.

I finally found it. I turned on verbose logging and found

DEBUG: No policy allowed anonymous performing WIKIPRINT_FILESYSTEM on None

After granting anonymous user this permission the PDFs were generated brilliantly.