Unicode not working and very bad preformance.

[GoogleCodeExporter]

Hello I have not been able to get Unicode working and am having very bad 
performance when converting.

Steps needed to reproduce:
1. Download dompdf_0-6-0_beta3.zip
2. Use attached 'dompdf_config.custom.inc.php'.
3. Run attached 'test_dompdf.php'. (the script just pull wikipedia pages to 
test unicode)

$php --version
PHP 5.3.6-13ubuntu3.6 with Suhosin-Patch (cli) (built: Feb 11 2012 03:26:01) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

Original issue reported on code.google.com by Fabian.B...@googlemail.com on 27 Mar 2012 at 9:17

Attachments:

• test_dompdf.php
• dompdf_config.custom.inc.php

[GoogleCodeExporter]

Performance
You're loading numerous remote objects (HTML document, stylesheets, images), so 
rendering speed will be affected by your connection speed and server 
responsiveness. There is also the issue of document complexity, which can 
significantly affect rendering speed and resource usage. These Wikipedia pages 
may be a bit much for DOMPDF at the moment

Unicode
These Wikipedia pages appear to use a variety of generic fonts in their styling 
(Verdana, Arial). Unless you have a Unicode-friendly version of the specified 
font loaded into DOMPDF you are not going to get any kind of Unicode support. 
Some of the document even appear to rely generic font families (e.g. 
"sans-serif") and DOMPDF does not currently support Unicode at all for text 
using this type of styling.

To prepare your installation for Unicode support please read over the following 
how-to:
http://code.google.com/p/dompdf/wiki/CPDFUnicode

Original comment by eclecticgeek on 28 Mar 2012 at 3:12

• Changed state: Invalid

[GoogleCodeExporter]

Performance
I am talking about a timespan of hours here, not just it feels like its taking 
long ...

Unicode
The fonts shouldn’t matter as it falls back to the default font, but even 
then it doesn’t render correctly. This is not the fault of the font as I used 
it in other cases and the glyphs are not missing there.

In any case I found other software that suits my needs 'wkhtmltopdf' that’s 
fast enough and renders properly with this test.

Original comment by Fabian.B...@googlemail.com on 28 Mar 2012 at 9:41

[GoogleCodeExporter]

It helps to quantify an issue. Requiring hours to render these documents is 
definitely not something we would expect. Are all the documents successfully 
rendered, or is there a hang-up at some point?

As for Unicode support, dompdf does not currently support glyphs outside the 
Windows ANSI character set when using the generic font families (serif, 
sans-serif, etc.). So even though these documents include this as a fallback 
some of the characters would render as "?" since they are unsupported.

Original comment by eclecticgeek on 2 Apr 2012 at 3:16

[GoogleCodeExporter]

The documents do eventually render successfully aside from the missing glyphs. 
With the 'test_dompdf.php' script in the attachment should have a decent test 
case to reproduce the described problems.
However since I require full Unicode support, I have since moved on to using 
'wkhtmltopdf' which does what I need and wish you guys good luck.

Original comment by Fabian.B...@googlemail.com on 2 Apr 2012 at 3:33

[GoogleCodeExporter]

Original comment by eclecticgeek on 30 May 2013 at 5:16

• Added labels: Restrict-AddIssueComment-Commit