search

sdglhm / dompdf

Automatically exported from code.google.com/p/dompdf
0 stars 0 forks source link

Encryption not working with Unicode #334

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

Run the following PHP code:

<?php

$html = '
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<div style="font-family: DejaVu Sans Condensed, monospace; font-size: 11px;">
Персонализиране хедър
</div>
</body>
</html>
';

include_once('dompdf/dompdf_config.inc.php');
$dompdf = new DOMPDF();
$dompdf->load_html($html);
$dompdf->render();
$dompdf->get_canvas()->get_cpdf()->setEncryption('userpass', 'ownerpass', 
array('print'));
$dompdf->stream('unicode.pdf', array('Attachment' => 1));

?>

What is the expected output? What do you see instead?

Text should read Персонализиране хедър. However, it appears 
as ~20 unreadable characters (can't copy and paste here because of the locked 
permissions).

What version of the product are you using? On what operating system?

I'm running the trunk version on Linux/Ubuntu, PHP 5.3.5.

Please provide any additional information below.

I added the line with setEncryption between the render() and the stream() 
calls, according to this post: 
http://www.dashinteractive.net/dompdf/index.php?v=1702369

If you remove the call to setEncryption, the problem no longer appears (but 
obviously no password protection is enforced either).

Original issue reported on code.google.com by freecorv...@gmail.com on 8 Aug 2011 at 11:38

GoogleCodeExporter commented 9 years ago

Original comment by eclecticgeek on 9 Aug 2011 at 7:44

GoogleCodeExporter commented 9 years ago 
It looks like it was fixed in the code from the trunk.

Original comment by fabien.menager on 15 Jan 2012 at 11:20

GoogleCodeExporter commented 9 years ago 
Hmm, it doesn't seem fixed to me. Here's what I did:

$ svn update

Fetching external item into 'dompdf/lib/php-font-lib'
External at revision 38.

At revision 454.

$ svn info
Path: .
URL: http://dompdf.googlecode.com/svn/trunk
Repository Root: http://dompdf.googlecode.com/svn
Repository UUID: 8e70de24-3a84-11de-b438-597f59cd7555
Revision: 454
Node Kind: directory
Schedule: normal
Last Changed Author: fabien.menager
Last Changed Rev: 454
Last Changed Date: 2012-01-18 00:33:27 +0200 (Wed, 18 Jan 2012)

Then I ran the code in the original post, opened the resulted PDF and entered 
the password. The result came out as in the attached file.

Am I doing something wrong? Is there any other way to do it?

Original comment by freecorv...@gmail.com on 19 Jan 2012 at 4:19

Attachments:

GoogleCodeExporter commented 9 years ago 
I am seeing a difference in rendering. Unprotected the document renders as 
expected but when protected I am actually getting the missing glyph box (links 
below). So not even as good as freecorvette. The problem seems to only affect 
renders that utilize embedded fonts. Rendering using the core fonts does not 
appear to exhibit the problem.

unprotected: 
http://eclecticgeek.com/dompdf/debug.php?identifier=7d4c64c9af19cc50e636c0395985
9371

protected: 
http://eclecticgeek.com/dompdf/debug.php?identifier=12e8179385557a999d1ede70b093
99e9
user password: userpass
owner password: ownerpass

FYI, I added an option to password protect a rendered document to the debug 
tester.

Original comment by eclecticgeek on 19 Jan 2012 at 6:52

GoogleCodeExporter commented 9 years ago

Original comment by eclecticgeek on 24 May 2013 at 3:00