Modify

Opened 15 years ago

Last modified 5 years ago

#7103 new defect

Print UTF-8 encoded wiki pages

Reported by: anonymous Owned by:
Priority: normal Component: TracWikiPrintPlugin
Severity: normal Keywords:
Cc: solid1999@… Trac Release: 0.12

Description

as I print page containing utf-8 characters all I get is '????' strings.

Attachments (4)

html.png (23.0 KB) - added by solid1999@… 14 years ago.
prinf as html
pdf.png (69.3 KB) - added by solid1999@… 14 years ago.
print as pdf
wikiprint.css (3.5 KB) - added by snegovick 14 years ago.
css
wikiprint.patch (1.5 KB) - added by Sevka 11 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 15 years ago by Álvaro Iradier

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

Thanks.

comment:2 Changed 15 years ago by onur@…

I've the same problem.

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

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

comment:3 Changed 15 years ago by anonymous

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

comment:4 Changed 15 years ago by anonymous

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

comment:5 Changed 15 years ago by Álvaro Iradier

Status: newassigned

comment:6 Changed 14 years ago by anonymous

any news, eh?

comment:7 Changed 14 years ago by Álvaro Iradier

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.

Changed 14 years ago by solid1999@…

Attachment: html.png added

prinf as html

Changed 14 years ago by solid1999@…

Attachment: pdf.png added

print as pdf

comment:8 in reply to:  7 Changed 14 years ago by anonymous

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
prinf as html
as pdf
print as pdf

comment:9 Changed 14 years ago by solid1999@…

Cc: solid1999@… added; anonymous removed

comment:10 Changed 14 years ago by Álvaro Iradier

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.

comment:11 in reply to:  10 Changed 14 years ago by anonymous

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 : )

comment:12 Changed 14 years ago by boleslaw.tokarski@…

Trac Release: 0.110.12

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!

comment:13 Changed 14 years ago by snegovick

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

comment:14 Changed 14 years ago by boleslaw.tokarski@…

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

Changed 14 years ago by snegovick

Attachment: wikiprint.css added

css

comment:15 Changed 14 years ago by snegovick

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

comment:16 Changed 14 years ago by anonymous

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

comment:17 Changed 13 years ago by Álvaro Iradier

See #8470 for another possible fix.

comment:18 Changed 13 years ago by anonymous

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.

comment:19 Changed 13 years ago by boleslaw.tokarski@…

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.

Changed 11 years ago by Sevka

Attachment: wikiprint.patch added

comment:20 Changed 11 years ago by Sevka

I have the same problem with russian text. I think there are some bug in the plugin (or in the PISA). In some reason custom CSS doesn't work with PDF. So I made a patch which helps me: wikiprint.patch In wikiprint.py I don't attach CSS by pisa parameter default_css, but include it direct in html.

And part of my custom CSS file with the Liberation font:

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

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

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

@font-face {
font-family: LiberationSans;
src: url("/usr/share/fonts/truetype/ttf-liberation/LiberationSans-BoldItalic.ttf");
font-weight: bold;
font-style: italic;
}

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

@font-face {
font-family: LiberationMono;
src: url("/usr/share/fonts/truetype/ttf-liberation/LiberationMono-Bold.ttf");
font-weight: bold;
}

@font-face {
font-family: LiberationMono;
src: url("/usr/share/fonts/truetype/ttf-liberation/LiberationMono-Italic.ttf");
font-style: italic;
}

@font-face {
font-family: LiberationMono;
src: url("/usr/share/fonts/truetype/ttf-liberation/LiberationMono-BoldItalic.ttf");
font-weight: bold;
font-style: italic;
}


html {
    font-family: LiberationSans; 
    font-size: 10px; 
    font-weight: normal;
    color: #000000; 
    background-color: transparent;
    margin: 0; 
    padding: 0;
    line-height: 150%;
    border: 1px none;
    display: inline;
    width: auto;
    height: auto;
    white-space: normal;
}

pre,
code,
kbd,
samp,
tt {
    font-family: LiberationMono; 
}
Last edited 11 years ago by Sevka (previous) (diff)

comment:21 Changed 5 years ago by Ryan J Ollos

Owner: Álvaro Iradier deleted
Status: assignednew

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.