Ticket #7103 (assigned defect)

Opened 3 years ago

Last modified 2 years ago

Print UTF-8 encoded wiki pages

Reported by: anonymous Assigned to: airadier (accepted)
Priority: normal Component: TracWikiPrintPlugin
Severity: normal Keywords:
Cc: solid1999@inbox.ru Trac Release: 0.12

Description

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

Attachments

html.png (23.0 kB) - added by solid1999@inbox.ru on 08/02/10 11:51:55.
prinf as html
pdf.png (69.3 kB) - added by solid1999@inbox.ru on 08/02/10 11:52:29.
print as pdf
wikiprint.css (3.5 kB) - added by snegovick on 02/07/11 20:25:35.
css

Change History

05/11/10 19:59:25 changed by airadier

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

Thanks.

05/16/10 22:09:47 changed by onur@yalazi.org

I've the same problem.

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

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

05/16/10 22:23:58 changed by anonymous

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

05/17/10 14:51:31 changed 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

05/20/10 19:23:46 changed by airadier

  • status changed from new to assigned.

06/14/10 23:16:25 changed by anonymous

any news, eh?

(follow-up: ↓ 8 ) 06/15/10 09:03:47 changed by 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.

08/02/10 11:51:55 changed by solid1999@inbox.ru

  • attachment html.png added.

prinf as html

08/02/10 11:52:29 changed by solid1999@inbox.ru

  • attachment pdf.png added.

print as pdf

(in reply to: ↑ 7 ) 08/02/10 12:02:18 changed 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

08/02/10 12:11:04 changed by solid1999@inbox.ru

  • cc set to solid1999@inbox.ru.

(follow-up: ↓ 11 ) 08/02/10 12:24:10 changed by 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.

(in reply to: ↑ 10 ) 08/25/10 15:48:43 changed 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 : )

11/16/10 23:31:21 changed by boleslaw.tokarski@gmail.com

  • release changed from 0.11 to 0.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!

01/10/11 07:16:31 changed 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

02/06/11 01:15:16 changed by boleslaw.tokarski@gmail.com

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

02/07/11 20:25:35 changed by snegovick

  • attachment wikiprint.css added.

css

02/07/11 20:27:12 changed by snegovick

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

04/09/11 05:59:30 changed 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

09/23/11 14:45:52 changed by airadier

See #8470 for another possible fix.

10/10/11 22:12:17 changed 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.

10/15/11 15:46:52 changed by boleslaw.tokarski@gmail.com

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.


Add/Change #7103 (Print UTF-8 encoded wiki pages)




Change Properties
Action