[PHP] Re: generate onfly PDF
I have had outstanding success with wkhtmltopdf: https://code.google.com/p/wkhtmltopdf/ It's a self-contained standalone program that you can call from PHP. It uses a full-bodied HTML interpreter based on Webkit. Highly recommended, I've been using it for years. It's open source and free. I should say, I've used the Linux version. It looks like there's a Windows version, but I have no experience with that, if that's what you need. Tim Rafnews wrote: Hi, Is there a solution to generate onfly PDF from HTML page, and from data user typed in form (let's say like a template) without using PECL ? i read that is hosting does not allow such extension, we can not generate PDF, so i would rather get a solution without such library. Moreover i'm searching a solution free and that i can supply with my web components. I created a component that should be able to generate PDF files quite often as service for user. thx Al. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Strange foreach reference issue
Hello,
This sure looks like a bug, but maybe there's some subtlety going on
that I don't understand, so I would appreciate some insight. After much
debugging, I tracked down a bug in my code to this test program. My PHP
version is 5.3.3, running under Fedora Linux.
'Title #1',
),
array(
'Title' => 'Title #2',
),
array(
'Title' => 'Title #3',
) );
print " Rows at start: " . print_r($row_list, true);
foreach ($row_list as $idx => &$row) {
print "Title A $idx: {$row['Title']}\n";
}
print " Rows are now: " . print_r($row_list, true);
foreach ($row_list as $idx => $row) {
print "Title B $idx: {$row['Title']}\n";
}
?>
When you run the program, it gives the following output:
--
Rows at start: Array
(
[0] => Array
(
[Title] => Title #1
)
[1] => Array
(
[Title] => Title #2
)
[2] => Array
(
[Title] => Title #3
)
)
Title A 0: Title #1
Title A 1: Title #2
Title A 2: Title #3
Rows are now: Array
(
[0] => Array
(
[Title] => Title #1
)
[1] => Array
(
[Title] => Title #2
)
[2] => Array
(
[Title] => Title #3
)
)
Title B 0: Title #1
Title B 1: Title #2
Title B 2: Title #2
--
Note that the second foreach repeats the second row, even though the
index is correct and the print_r shows things as correct.
Now, if you change the name of the reference variable from '$row' to
'$rowx' (for example), things will work. So clearly there's some issue
with $row being previously used as a reference that's "contaminating"
the subsequent use of $row in the foreach. If there's some logic to
this, it's escaping me.
Any insight on this would be appreciated.
Regards,
Tim Behrendsen
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Strange foreach reference issue
On 1/7/2012 4:18 PM, Matijn Woudt wrote:
On Sun, Jan 8, 2012 at 12:29 AM, Tim Behrendsen wrote:
Hello,
This sure looks like a bug, but maybe there's some subtlety going on that I
don't understand, so I would appreciate some insight. After much debugging,
I tracked down a bug in my code to this test program. My PHP version is
5.3.3, running under Fedora Linux.
'Title #1',
),
array(
'Title' => 'Title #2',
),
array(
'Title' => 'Title #3',
) );
print " Rows at start: " . print_r($row_list, true);
foreach ($row_list as $idx => &$row) {
Why is there an '&' before $row here? That seems like the problem to me..
Matijn
When you use an ampersand on the variable, that creates a reference to
the array elements, allowing you to potentially change the array
elements themselves (which I'm not doing here).
http://www.php.net/manual/en/control-structures.foreach.php
I do notice in the manual that it says, "Reference of a $value and the
last array element remain even after the foreach loop. It is recommended
to destroy it by unset()." But that doesn't really explain why it
contaminates the next foreach loop in such an odd way. You would think
that the $row in the second loop would be assigned a non-reference value.
Tim
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Strange foreach reference issue
On 1/7/2012 4:44 PM, Stephen wrote: On 12-01-07 07:30 PM, Tim Behrendsen wrote: When you use an ampersand on the variable, that creates a reference to the array elements, allowing you to potentially change the array elements themselves (which I'm not doing here). http://www.php.net/manual/en/control-structures.foreach.php I do notice in the manual that it says, "Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset()." But that doesn't really explain why it contaminates the next foreach loop in such an odd way. You would think that the $row in the second loop would be assigned a non-reference value. Tim Tim, You are using the &$variable in an unintended (by PHP designers), and I suggest undefined manner. So the outcome cannot, but definition be explained. Was this intended, and what were you trying to accomplish? Stephen In the real code, I just happen to use the same variable name first as a reference, and then as a normal non-reference, and was getting the mysterious duplicate rows. I think I'm using everything in a completely reasonable way; the second foreach is reassigning the loop variable. Nothing that comes before using that variable ought to cause undefined behavior. The warning in the manual is about using the loop variable as a reference after exiting the loop, but I'm not doing that. I'm reassigning it, exactly as if I just decided to do a straight assignment of "$row" Ah ha, wait a minute, that's the key. OK, this is making more sense. The first loop is leaving a reference to the final element. But then the second foreach is doing a straight assignment to the $row variable, but $row is a reference to the final element. So the foreach is assigning its iterated value to the final element of the array, instead of a normal variable. OK, I understand the logic now. The world now makes sense. The moral is always unset the iterator variable when doing foreach with a reference, like the manual says. :) Thanks for everyone's help. Tim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Strange foreach reference issue
On 1/9/2012 10:35 AM, David Harkness wrote: On Sat, Jan 7, 2012 at 5:01 PM, Tim Behrendsen <mailto:t...@behrendsen.com>> wrote: The first loop is leaving a reference to the final element. But then the second foreach is doing a straight assignment to the $row variable, but $row is a reference to the final element. So the foreach is assigning its iterated value to the final element of the array, instead of a normal variable. Exactly, and the fact that it shows "1, 2, 2" in the second loop adds more confusion, but it makes sense. In the second loop, it assigns the indexed row value into the third row and displays it. Thus it displays row 1, row 2, and then ... row 3, but row 3 is the one that keeps getting overwritten. And in the third iteration, it overwrites the third row with the third row which currently holds what was in row 2. The moral is always unset the iterator variable when doing foreach with a reference, like the manual says. :) While you can certainly follow the above advice, in my view it's dangerous to have these two loops a) reuse the same variable name for a different purpose and b) exist in the same scope. More and more I find myself dropping the subtle tricks I've learned over the years in favor of writing code that is as easy to understand as possible. Code gets read and modified a lot more than it gets written, and all those tricks just trip up more junior teammates--and often even myself. :) David Agreed, in fact, I decided to create a new style naming convention where "_ref" is always suffixed to variable names that are references, along with doing the unset, just in case. This goes to show that references can be a recipe for subtle bugs to creep in, so best to isolate them as much as possible to their own convention. If the convention is followed, it should eliminate the possibility of this bug, even if the unset is left out. Tim
