php-general Digest 12 Aug 2008 01:07:36 -0000 Issue 5619
Topics (messages 277962 through 277991):
Re: newsletter code
277962 by: Richard Heyes
277964 by: Per Jessen
277965 by: Per Jessen
277966 by: Richard Heyes
277967 by: Carlos Medina
277969 by: Per Jessen
277972 by: Robert Cummings
277977 by: Manuel Lemos
277979 by: Mike Roberts
277980 by: Per Jessen
277981 by: tedd
Re: tidy
277963 by: Eric Butera
Re: More SOAP questions. Also, SOAP bug? Or just me? (long)
277968 by: Christoph Boget
Re: PUT vs. POST (was: php File upload)
277970 by: Boyd, Todd M.
277971 by: Boyd, Todd M.
277973 by: Per Jessen
277975 by: tedd
277976 by: Per Jessen
277984 by: Boyd, Todd M.
277985 by: tedd
277986 by: mike
277987 by: tedd
277988 by: tedd
277990 by: mike
How to get text of Alert message
277974 by: Ajay Kushwaha
Re: PUT vs. POST
277978 by: Asher Snyder
277982 by: Micah Gersten
277983 by: Per Jessen
277989 by: tedd
Timing problem, putting PNG into PDF
277991 by: Brian Dunning
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
> ...
You may want to consider using a 3rd party service, eg Jango Mail.
Probably have a better success rate in getting your messages into your
users Inboxes.
--
Richard Heyes
http://www.phpguru.org
--- End Message ---
--- Begin Message ---
Richard Heyes wrote:
>> ...
>
> You may want to consider using a 3rd party service, eg Jango Mail.
> Probably have a better success rate in getting your messages into your
> users Inboxes.
>
I wouldn't bet on it Richard - filtering out an email sent by an honest
user from an honest and properly configured mailserver is very, very
difficult.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
Angelo Zanetti wrote:
> Client wants a "subscribe to newsletter" dialog on website, typically
> just an email address.
>
> Then in his admin section he wants to send out HTML newsletters/plain
> text depending on the user's email client.
Sounds almost like mailman. Appropriately customized of course.
> Now how would I go about creating the newsletter in the backend? Using
> a WSIWIG editor?
Leave the creation of the email/newsletter to your customer.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
> I wouldn't bet on it Richard - filtering out an email sent by an honest
> user from an honest and properly configured mailserver is very, very
> difficult.
Using a dedicated service is still going to be a better bet than
rolling your own. Probably cheaper too.
--
Richard Heyes
http://www.phpguru.org
--- End Message ---
--- Begin Message ---
Angelo Zanetti schrieb:
Hi All,
I have a question related to newsletter subscriptions to websites as well as
sending out of the newsletters.
Here is the scenario:
Client wants a "subscribe to newsletter" dialog on website, typically just
an email address.
Then in his admin section he wants to send out HTML newsletters/plain text
depending on the user's email client.
Now how would I go about creating the newsletter in the backend? Using a
WSIWIG editor? Or is there some code that you guys use as there are also
things to consider such as:
-bulk mailing, instead of sending many mails at once. Rather send out some
scheduled emails
-Plain text vs HTML email
Etc...
What do you guys use if you are building a custom web app?
I have seen Webinsta before it works well but it's a separate system.
Let me know,
Thanks
Kind regards
Angelo
Web: http://www.elemental.co.za
Hi Angelo,
look little bit around. This Issue is not Easy as Richard says. But
maybe with http://www.jtr.de/scripting/php/newsletter/index.html JAX
Mailing list manager ( Only Germay as i can see ) or PHPlist, or LetterIt.
Regards
Carlos
--- End Message ---
--- Begin Message ---
Angelo Zanetti wrote:
> Then in his admin section he wants to send out HTML newsletters/plain
> text depending on the user's email client.
Personally, I would just let the user pick a format, and then always
send the newsletter in HTML and text.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Mon, 2008-08-11 at 17:08 +0200, Per Jessen wrote:
> Angelo Zanetti wrote:
>
> > Then in his admin section he wants to send out HTML newsletters/plain
> > text depending on the user's email client.
>
> Personally, I would just let the user pick a format, and then always
> send the newsletter in HTML and text.
Yep, if they have to register anyways. And at the bottom of the
newsletter where you have the unsubscrib linke (you DO have one
right? ;) you could also put a link to change their preferences.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Hello,
on 08/11/2008 09:26 AM Angelo Zanetti said the following:
Hi All,
I have a question related to newsletter subscriptions to websites as well as
sending out of the newsletters.
Here is the scenario:
Client wants a "subscribe to newsletter" dialog on website, typically just
an email address.
Then in his admin section he wants to send out HTML newsletters/plain text
depending on the user's email client.
Now how would I go about creating the newsletter in the backend? Using a
WSIWIG editor? Or is there some code that you guys use as there are also
things to consider such as:
-bulk mailing, instead of sending many mails at once. Rather send out some
scheduled emails
-Plain text vs HTML email
Etc...
What do you guys use if you are building a custom web app?
I just use this MIME message class. It solves the problem of sending
HTML or plain text messages using multipart/alternative containers. You
define a text and HTML version and the class sends both within the
message in such way that if the mail client supports HTML the user will
see that version, otherwise it will only see the text version. Take a
look at the test_simple_html_mail_message.php script.
http://www.phpclasses.org/mimemessage
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
Ladies and Gentlemen,
Please pardon the interruption, but I tried the prescribed method of
'opting out' of these messages, but they still arrive.
I am a recruiter, and I joined to understand a little something about
some of the jobs that I was working on around 10 months ago. Unless
somebody wants job related advice ( which I doubt), I would hazard a
guess that I have nothing to contribute to your conversations. Can
anybody help me get 'de-listed'? Any help would be appreciated. Thanks
and best of luck to everybody here.
Michael Roberts
Senior Recruitment Strategist
Corporate Staffing Services
150 Monument Road, Suite 510
Bala Cynwyd, PA 19004
P 610-771-1084
F 610-771-0390
E [EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Richard Heyes
Sent: Monday, August 11, 2008 10:40 AM
To: Per Jessen
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] newsletter code
> I wouldn't bet on it Richard - filtering out an email sent by an
honest
> user from an honest and properly configured mailserver is very, very
> difficult.
Using a dedicated service is still going to be a better bet than
rolling your own. Probably cheaper too.
--
Richard Heyes
http://www.phpguru.org
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Mike Roberts wrote:
> Ladies and Gentlemen,
> Please pardon the interruption, but I tried the prescribed method of
> 'opting out' of these messages, but they still arrive.
There's no opting out, but there is an unsubscribe:
To unsubscribe, visit: http://www.php.net/unsub.php
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
At 2:42 PM -0400 8/11/08, Mike Roberts wrote:
--snip--
Can
anybody help me get 'de-listed'? Any help would be appreciated. Thanks
and best of luck to everybody here.
Michael Roberts
Senior Recruitment Strategist
-snip-
To unsubscribe, visit: http://www.php.net/unsub.php
Are you saying that following the directions provided in the above
link doesn't work?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On Fri, Aug 8, 2008 at 3:46 PM, Selwyn Polit <[EMAIL PROTECTED]> wrote:
> How do I install php-tidy extension on a hosted linux? I don't have access
> to yum or apt-get. When I try pecl install tidy this fails
>
> ..
> checking for TIDY support... yes, shared
> configure: error: Cannot find libtidy
> ERROR: `/var/tmp/pear/download/tidy-1.2/configure --with-tidy' failed
>
> I am using php5 on westhost.
> thanks
>
> Selwyn
>
>
> --
> Selwyn Polit
> Computer Consulting, programming, web sites
> 512-696-0410
> www.AustinProgressiveCalendar.com
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
It's a compile time option. The Pecl version is for php4.
--- End Message ---
--- Begin Message ---
> different question asked below. So I then add in:
>
> echo 'Types: <pre>' . print_r( $oClient->__getTypes(), TRUE ) . '</pre>';
>
> and it turns out that the "data-array" definition in the WSDL is
> getting translated as the following structure:
>
> [XX] => struct data-array {
> any;
> }
>
> Umm, huh? What's going on there? Why is the SoapClient the part of
> the namespace included in the definition for the type in the WSDL
> (<xs:any maxOccurs="unbounded"/>) and turning the "any" into an
> attribute of the structure? So in order to get the "data-array" node
> in the SOAP message body, I have to change the parameters definition
> to:
>
> $aParameters = array( 'authentication' => array( 'username' => 'user',
>
> 'password' => 'pass' ),
> 'stringvar1' => 'here',
> 'stringvar2' => 'there',
> 'data-array' => array( 'any' =>
> '<sub-data>Bob</sub-data>' ));
>
> That seems exceptionally silly to me. Is this a bug in the
> SoapClient's translation of the WSDL? A problem with the WSDL? Or a
> problem with my (albeit simplistic) code and is something I can and
> should get around using proper attributes? If it's the latter, how
> can I define attributes for the various nodes?
It seems like this is having an additional affect of not allowing the
'classmap' functionality to work properly. When I do:
$oClient->__getLastResponse()
I see the full SOAP message XML and it appears to be properly formed.
So (unless I am profoundly misunderstanding how classmap works) it
should be when I try to do:
$oResponse = $oClient->ServerOperation( $aParameters );
the $oResponse object should be instantiated with it's attributes
populated with the proper values, corresponding with the various
nodes/values that appear in the XML SOAP response. The problem is, it
isn't. I've tried creating __get() and __set() methods in the class
to see if they are being called and/or what is getting passed in (if
anything) and I'm not seeing any of my debug outout. Additionally, if
I run
var_export( $oResponse );
I am seeing:
MyResponseClass::__set_state(array(
'any' => '',
))
That doesn't seem right. Further, if I try to access the "any"
property of the object, there is no value (as illustrated above).
It's as if nothing was done with the XML SOAP response w/r/t defining
the classmap option.
So what's going on? Am I doing something wrong? Am I totally
misunderstanding something here?
thnx,
Christoph
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Per Jessen [mailto:[EMAIL PROTECTED]
> Sent: Saturday, August 09, 2008 9:09 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [PHP] Re: PUT vs. POST (was: php File upload)
>
> Boyd, Todd M. wrote:
>
> > I had to use Java for the simple fact that PHP by itself cannot
> access
> > the local file system in a way that allows for the partial loading of
> > files.
>
> Given that PHP doesn't run on the client, there is no way for anything
> written in PHP to access anything on the client.
Gee.. I get the feeling that you didn't read what I wrote in that post.
"PHP can't access client stuff."
"No, PHP _CAN'T_ access client stuff!"
"Um... kay?"
Todd Boyd
Web Programmer
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: mike [mailto:[EMAIL PROTECTED]
> Sent: Saturday, August 09, 2008 2:47 PM
> To: Richard Heyes
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP] Re: PUT vs. POST (was: php File upload)
>
>
>
> On Aug 9, 2008, at 7:50 AM, "Richard Heyes" <[EMAIL PROTECTED]>
> wrote:
>
> >> Given that PHP doesn't run on the client, there is no way for
> >> anything
> >> written in PHP to access anything on the client.
> >
> > Wouldn't it be fun though if it could? :-)
> >
> > --
> > Richard Heyes
> > http://www.phpguru.org
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> Years ago someone made an activex component to run php on the client.
> Apparently it went nowhere.
Willing to bet it had been completely squashed due to ActiveX
vulnerabilities and that Firefox actively refuses ADO.
Todd Boyd
Web Programmer
--- End Message ---
--- Begin Message ---
Boyd, Todd M. wrote:
>>> I had to use Java for the simple fact that PHP by itself cannot
>>> access the local file system in a way that allows for the partial
>>> loading of files.
>>
>> Given that PHP doesn't run on the client, there is no way for
>> anything written in PHP to access anything on the client.
>
> Gee.. I get the feeling that you didn't read what I wrote in that
> post.
>
> "PHP can't access client stuff."
>
> "No, PHP _CAN'T_ access client stuff!"
>
> "Um... kay?"
Todd, I just wanted to stress that there is NO way for PHP to access
anything on the client. The way you wrote it, you sort of implied that
there might be other ways:
"PHP by itself cannot access the local file system in a way that
allows ..."
That's all.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
At 6:33 PM +0200 8/11/08, Per Jessen wrote:
Boyd, Todd M. wrote:
I had to use Java for the simple fact that PHP by itself cannot
access the local file system in a way that allows for the partial
loading of files.
Given that PHP doesn't run on the client, there is no way for
>> anything written in PHP to access anything on the client.
-snip-
Todd, I just wanted to stress that there is NO way for PHP to access
anything on the client. The way you wrote it, you sort of implied that
there might be other ways:
"PHP by itself cannot access the local file system in a way that
allows ..."
That's all.
The above is saying two different things.
1). "PHP by itself cannot access the local file system" <-- true.
2) "... there is NO way for PHP to access anything on the client."
<-- not true.
Javascript can access some stuff on the client <-- true.
Javascript and php can communicate <-- also true.
Therefore, anything that javascript can access can be provided to
php, thus proving [2] wrong.
Now, if I'm wrong, please show me something that javascript can get
that can't be provided to php.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
tedd wrote:
>>Todd, I just wanted to stress that there is NO way for PHP to access
>>anything on the client. The way you wrote it, you sort of implied
>>that there might be other ways:
>>
>>"PHP by itself cannot access the local file system in a way that
>>allows ..."
>>
>>That's all.
>
> The above is saying two different things.
>
> 1). "PHP by itself cannot access the local file system" <-- true.
>
> 2) "... there is NO way for PHP to access anything on the client."
> <-- not true.
Statement 2 _is_ 100% true. Sorry, end of discussion for my part.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Per Jessen [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 11, 2008 1:17 PM
> To: [EMAIL PROTECTED]
> Subject: RE: RE: [PHP] Re: PUT vs. POST (was: php File upload)
>
> tedd wrote:
>
> >>Todd, I just wanted to stress that there is NO way for PHP to access
> >>anything on the client. The way you wrote it, you sort of implied
> >>that there might be other ways:
> >>
> >>"PHP by itself cannot access the local file system in a way that
> >>allows ..."
> >>
> >>That's all.
> >
> > The above is saying two different things.
> >
> > 1). "PHP by itself cannot access the local file system" <-- true.
> >
> > 2) "... there is NO way for PHP to access anything on the client."
> > <-- not true.
>
> Statement 2 _is_ 100% true. Sorry, end of discussion for my part.
I think there is a difference in definition going on here. An object in the
local filesystem (though not the original copy of it, but a facsimile rendered
through Javascript) can be accessed from PHP, though not in its original form,
but wrapped in an AJAX request--or hidden INPUT tag, etc. (in the form of
encoded text)--and then manipulated.
That's what I *MEANT* to say. :P
Todd Boyd
Web Programmer
--- End Message ---
--- Begin Message ---
At 8:17 PM +0200 8/11/08, Per Jessen wrote:
tedd wrote:
> 2) "... there is NO way for PHP to access anything on the client."
<-- not true.
Statement 2 _is_ 100% true. Sorry, end of discussion for my part.
/Per Jessen, Zürich
Per Jessen:
I am sure you are smarter than this -- you're
probably not understanding what I am saying.
I write code daily that communicates between
javascript and php. As such, data that is on the
client-side can passed to the server-side
effortlessly -- javascript does that very well
and if you don't want to entertain a refresh, you
can even use ajax.
PHP can even write javascript to do this and sit
waiting for a reply back -- it's simply a matter
of timing.
Here's an example of php and javascript playing well together:
http://webbytedd.com/b/timed-php/
Are you saying that this is not possible? I think
not -- I think one of us is not understanding
what the other is saying -- which is it?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On 8/11/08, tedd <[EMAIL PROTECTED]> wrote:
> Per Jessen:
>
> I am sure you are smarter than this -- you're probably not understanding
> what I am saying.
No, Per is correct.
PHP itself cannot access anything on the client. It is a server-parsed
language. The client never executes PHP, period.
Javascript, other applets, etc. can *inform* or push information to
PHP about the client or files on the client, but PHP itself has no
idea what is going on other than $_SERVER, $_COOKIE vars and whatnot
identifying the browser. That's all it gets without something else
"helping" it, and that is still not -PHP- itself.
--- End Message ---
--- Begin Message ---
At 2:07 PM -0500 8/11/08, Boyd, Todd M. wrote:
I think there is a difference in definition going on here.
-snip-
Todd:
I think you are right -- there must be some type of disconnect going
on here because it's obvious that php can receive data from
javascript.
It's also obvious that javascript works client-side.
Therefore, php can receive data from client-side -- to claim
otherwise is nonsense.
Per Jessen must be talking about something else.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 12:19 PM -0700 8/11/08, mike wrote:
On 8/11/08, tedd <[EMAIL PROTECTED]> wrote:
Per Jessen:
I am sure you are smarter than this -- you're probably not understanding
what I am saying.
No, Per is correct.
PHP itself cannot access anything on the client. It is a server-parsed
language. The client never executes PHP, period.
Javascript, other applets, etc. can *inform* or push information to
PHP about the client or files on the client, but PHP itself has no
idea what is going on other than $_SERVER, $_COOKIE vars and whatnot
identifying the browser. That's all it gets without something else
"helping" it, and that is still not -PHP- itself.
Arrrggg!!!
Read!!!!!
I said:
1). "PHP by itself cannot access the local file system" <-- true.
Now, do you agree with that?! Isn't that the SAME as what you said above?!
Now, why not read the rest of what I wrote?
Sometimes it's hard to get an idea across because some people refuse
to read, but love to comment about the obvious.
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On 8/11/08, tedd <[EMAIL PROTECTED]> wrote:
> Now, do you agree with that?! Isn't that the SAME as what you said above?!
>
> Now, why not read the rest of what I wrote?
>
> Sometimes it's hard to get an idea across because some people refuse to
> read, but love to comment about the obvious.
Or this conversation has become a hassle to pay attention to and I'm
not going to waste time since gmail has compressed all the common text
on each conversation trying to flip through it.
Originally this was a decent idea for discussion since this interests
me, but the thread has been hijacked into a semantics discussion now.
So I decided I've seen enough of this back and forth and posted
something.
I therefore request we stop this discussion or put it into another
thread about PHP vs. clientside crap, and let POST vs. PUT resume
discussion if that's even still alive.
--- End Message ---
--- Begin Message ---
I am using Selenium IDE tool.
facing the problem to get the text of alert message.
Any help ...........Please reply as soon as possible..
Thanks,
--
View this message in context:
http://www.nabble.com/How-to-get-text-of-Alert-message-tp18929888p18929888.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
Todd, I just wanted to stress that there is NO way for PHP to access
anything on the client. The way you wrote it, you sort of implied
that there might be other ways:
"PHP by itself cannot access the local file system in a way that
allows ..."
That's all.
The above is saying two different things.
1). "PHP by itself cannot access the local file system" <-- true.
2) "... there is NO way for PHP to access anything on the client."
<-- not true.
Statement 2 _is_ 100% true. Sorry, end of discussion for my part.
Technically statement 2 is not true, a PHP framework/platform such as
NOLOH (http://www.noloh.com), allows you to access all client properties
seamlessly and transparently from PHP, with something like NOLOH you
don't have to worry about the client at all.
-Asher
--- End Message ---
--- Begin Message ---
Per Jessen wrote:
> tedd wrote:
>
>
>>> Todd, I just wanted to stress that there is NO way for PHP to access
>>> anything on the client. The way you wrote it, you sort of implied
>>> that there might be other ways:
>>>
>>> "PHP by itself cannot access the local file system in a way that
>>> allows ..."
>>>
>>> That's all.
>>>
>> The above is saying two different things.
>>
>> 1). "PHP by itself cannot access the local file system" <-- true.
>>
>> 2) "... there is NO way for PHP to access anything on the client."
>> <-- not true.
>>
>
> Statement 2 _is_ 100% true. Sorry, end of discussion for my part.
>
>
> /Per Jessen, Zürich
>
>
No, if you said:
.. there is NO way for PHP to access anything *directly* on the client.
That's more true.
Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com
--- End Message ---
--- Begin Message ---
Asher Snyder wrote:
>>>
>>> 1). "PHP by itself cannot access the local file system" <-- true.
>>>
>>> 2) "... there is NO way for PHP to access anything on the client."
>>> <-- not true.
>>>
>>
>> Statement 2 _is_ 100% true. Sorry, end of discussion for my part.
>>
> Technically statement 2 is not true, a PHP framework/platform such as
> NOLOH (http://www.noloh.com), allows you to access all client
> properties seamlessly and transparently from PHP,
Seeing as PHP is SO incredibly powerful on the client side, surely we
should have had an option to disable PHP in the browser long ago?
I know I would want one. I'll have to mention it to the Mozilla
people - I'm sure they'll appreciate a good, uh .. hysterical laugh.
And _that_ was my absolutely final posting on this topic.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
At 9:07 PM +0200 8/11/08, Per Jessen wrote:
Asher Snyder wrote:
1). "PHP by itself cannot access the local file system" <-- true.
2) "... there is NO way for PHP to access anything on the client."
<-- not true.
Statement 2 _is_ 100% true. Sorry, end of discussion for my part.
Technically statement 2 is not true, a PHP framework/platform such as
NOLOH (http://www.noloh.com), allows you to access all client
properties seamlessly and transparently from PHP,
Seeing as PHP is SO incredibly powerful on the client side, surely we
should have had an option to disable PHP in the browser long ago?
I know I would want one. I'll have to mention it to the Mozilla
people - I'm sure they'll appreciate a good, uh .. hysterical laugh.
And _that_ was my absolutely final posting on this topic.
/Per Jessen, Zürich
You obviously don't understand.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
I'm using GD to crop & save an uploaded image, and then embedding it
into a PDF made with FPDI. It works great when the image is small or
low-res. When the uploaded file is bigger, more than a couple hundred
K or so, it fails. I think that the image is not done writing yet by
the time I try to do the $pdf->Image. Any suggestions? Some way to
force it to hang out and pause until the image is done writing?
--- End Message ---
