I am trying to connect to my printer which is on another machine through this code
$handle = printer_open("\\\\xxx.xxx.xxx.xxx\\Canon MF4320-4350");
if($handle)
echo "connected";
else
echo "not connected";
and getting the error
Fatal error: Call to undefined function printer_open() in C:\wamp\www\print\index.php on line 3
I have installed the php_printer.dll but it is not showing it under phpinfo(). Using PHP version 5.3.0
how can i connect to the printer and make my printer_open() method work??
If you are using PHP 5.3/ 5.4/ 5.5 in WAMP, here is how you setup printer.
Go to this link:http://windows.php.net/downloads/pecl/snaps/printer/0.1.0-dev/
Download the zip for your version. First try with ts. If it does not work, try nts.
Unzip and copy the php_printer.dll file. Paste here: C:\wamp\bin\php(phpyourversion)\ext . Note: (phpyourversion) will be like php5.5.12 depending on your version.
Find the loaded php.ini file. Use phpinfo or Wamp menu to find it. Look online for more help.
Paste this at the end of the file: extension=php_printer.dll
Restart server.
Create a file with the following code and test it:
<?php
$printer_name = "Your Printer Name exactly as it is";
$handle = printer_open($printer_name);
printer_start_doc($handle, "My Document");
printer_start_page($handle);
$font = printer_create_font("Arial", 100, 100, 400, false, false, false, 0);
printer_select_font($handle, $font);
printer_draw_text($handle, 'This sentence should be printed.', 100, 400);
printer_delete_font($font);
printer_end_page($handle);
printer_end_doc($handle);
printer_close($handle);
If the above does not work, try with nts version of the php_printer.dll file as mentioned in step two. remember to restart server after deleting the previous file, pasting the new file.
I have a similar problem. This is what I have figured out so far.
Make sure that you have a php_printer.dll matching your php compile version in your extension folder ( php/ext/ ). Use this link for downloading the file.
add the following in your php.ini file:
printer.default_printer=PHP_INI_ALL
extension=php_printer.dll
The errors have disappeared but the file is still not printing.
Related
I am not entirely sure that this is coding problem, so I'll describe my Windows environment, just in case: system is windows 10 Pro x64 build 1809, I have XAMPP windows x64 7.2.18-0-VC15 installed. On XAMPP I have PHP Version 7.2.18.
Following PHP code executes OK when I try it on Linux (took it from Stackoverflow)
:
function unzip_db($filename) {
$zip = new ZipArchive;
$res = $zip->open($filename);
if($res === TRUE) {
$zip->extractTo('./');
$zip->close();
echo 'File is now uncompressed...';
} else {
echo "Can't open ".$filename;
echo $res;
}
}
When I try to run it under Windows this code always fails on the test if($res === TRUE) I am now not sure what to do: I check the output of phpinfo(); is says about ZIP: Zip enabled, Zip version: 1.15.4, Libzip version: 1.4.0, that could mean that I PHP have ZIP support and I am doing something wrong. I have also located and downloaded php_zip.dll (from https://pecl.php.net/package/zip/1.15.4/windows) and added line extension=php_zip.dllto php.ini file, but nothing has changed.
I ran out of ideas and I still don't know do I have a coding or environment config trouble, or what...
Any suggestions?
We can close this question. I have found that after I've zipped the test files and uploaded that to Linux, I downloaded them back to Windows box. It is that files creating the issue with PHP. It is kind of strange that I can still open them with 7zip, but I cant open them with Windows's built in unzipper.
Even when I upload that files back to Linux, I can still unzip them with PHP. Seems there is difference between Linux and Windows implementation of ZIPlibraries, but that is not the reason for the problems.
So I have to troubleshoot what happens when up/downloading the files - but that is out of scope of this question.
Thanks for your contribution. It helped to set me straight, so I was able to determine wherein lays the trouble.
I have a small issue with mPDF (version 5.7.1).
This code should generate PDF with image file:
$mpdf = new mPDF();
$html = '<img src="https://www.google.pl/images/srpr/logo11w.png"/>';
$mpdf->WriteHTML($html);
$mpdf->debug = true;
$output = $mpdf->Output();
exit();
Well there is no image but an [x] instead.
I've googled enough to get to the conclusion that it has to be done this way but I also tried realpath to the file. Still nothing.
The only thing I haven't tried is <img src="logo11w.png"> and copying the image into the folder because I don't know into which folder I should copy file logo11w.png.
Any suggestions?
I had the same problem with PNG images being displayed as [X] when to generate PDFs with mPDF.
I added: $mpdf->showImageErrors = true;
After: $mpdf = new Mpdf();
and got the error message:
GD library required for PNG image (alpha channel)#
So after running apt-get install php5-gd generating a PDF with a PNG worked like a charm!
Including images is kinda tricky in mPDF. I had some issues as well. I found more kind of problems.
At first you should turn on debug variable:
$mpdf = new mPDF();
$mpdf->showImageErrors = true;
Usualy people don't have installed GD module for PHP. On linux machine, execute:
sudo apt-get install php5-gd
sudo service apache2 restart
On Windows servers, php_gd2.dll is included in a standard PHP installation, but is not enabled by default. To enable it, uncomment the extension=php_gd2.dll line in your php.ini file (remove the # from the beginning of that line) and restart the PHP extension. [1]
If you get this error you probably see [x] image:
mPDF error: IMAGE Error (http://www.domain.com/directory/image.jpg): Could
not find image file
Check the url if your image exists and if the image is accessible. If yes then you can try to change absolute URL to relative. You can try both versions:
<img src="directory/image.jpg">
<img src="./directory/image.jpg">
Actually I also had a problem with PNG formats. Converted PNG image to JPG worked fine.
Linking in mPDF templates should be same like for whole your framework/system.
I have encountered the same problem after migrating the script.
The problem was, that the tmp directory inside the mpdf folder was not writable. I hope it helps someone.
For me, it is working as of now. Hope this will help someone.
Solution : Try relative path of image instead of URL. Image must be hosted on the same server.
Ex: /var/www/mysite/image/xyz.jpg
In my project i fix problem and solution is:
Set src absolute path on the server example:
src="/var/www/myproject/images/logo.png" if image is on the same server.
If image is from external server src is absolute path example:
src="https://www.google.bg/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png".
Hope this will help someone.
Just experienced this issue today with an old website.
If you have mPDF <= 6.0 and you are now experiencing this issue when it was previously working. The reason is that there is an SSL error (expired certificate, invalid certificate, etc). The solution is the fix the SSL certificate installation; however, if you want a quick fix you can edit the mpdf.php file to ignore SSL errors during CURL requests. Simply add:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
Inside the functions:
file_get_contents_by_curl
and
_get_file
Ok. After the last comment on question (14:30). Here the exact same code that IS working with mPDF 5.4. And it saves it's output on scripts directory as test.pdf. Firewall issues?
Edited
I have the following directories / files:
images
wallpaper01.jpg
wallpaper02.jpg
index.php (source code)
So these image files are relatively starting from the script directory as it looks like.
require_once __DIR__ . DIRECTORY_SEPARATOR . 'MPDF/mpdf.php';
try {
$mpdf = new mPDF();
$mpdf->WriteHTML('<img src="images/wallpaper01.jpg" alt="" width="480">');
$mpdf->WriteHTML('<img src="images/wallpaper02.jpg" alt="" width="480">');
$mpdf->Output(__DIR__ . DIRECTORY_SEPARATOR . 'test.pdf', 'F');
} catch(Exception $e) {
echo $e;
}
Fully working example (download)
It's enough
The solve is :
$mpdf->curlAllowUnsafeSslRequests = true;
It's all
In my case, the problem was just the usage of transparents PNG using the 6.0 version. This bug was fixed on the mpdf 6.1 version.
I successfully solved the problem downloading the 6.1 version from here and overriding the mpdf files on my project.
You can try this:
$mpdf->imageVars['myvariable'] = file_get_contents('alpha.png');
or
$html = '<img src="var:myvariable"/>';
$mpdf->WriteHTML($html);
after there, you should do:
$mpdf->Image('var:myvariable', 0, 0);
read more about this in documentation:
mPDF Load Image
I am using Code Ignitor and mpdf. After installing php-gd5 library, I had to re-install the php with configure command --with-gd to resolve the issue
I encountered a similar problem using MPDF 8.1.x where I could not use URL paths for my images.
Eventually I determined it was caused because the "curlUserAgent" setting was using a very old user agent.
The setting was found here:
/mpdf/src/Config/ConfigVariables.php
The curlUserAgent was set to:
'curlUserAgent' => 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1',
But I updated this to:
'curlUserAgent' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0',
and the images successfully loaded from URL source.
change to
remove the second line before initializing $html
its undefined at that time.
new code will be as
$mpdf = new mPDF();
$html= "<img src='https://www.google.pl/images/srpr/logo11w.png' alt=''>";
$mpdf->WriteHTML($html);
$mpdf->debug = true;
$output = $mpdf->Output();
exit();
Another reason might be you're running your application in Docker (or another container) and you're using a domain that can't be resolved.
Adding an alias in my docker-compose file resolved the issue for me.
networks:
app-network:
aliases:
- your.local.domain
To find out if this is the reason, log into the running container and attempt to request the file via curl/wget/etc.
.htaccess with password also can blocks access
An exception can be added:
AuthType Basic
AuthUserFile "/home/domain.pl/public_html/.htpasswd"
require valid-user
AuthName "set password"
Order allow,deny
# payu
Allow from 185.68.14.10
Allow from 185.68.14.11
Allow from 185.68.14.12
Allow from 185.68.14.26
Allow from 185.68.14.27
Allow from 185.68.14.28
# serwer localhost
Allow from 185.185.185.185
satisfy any
Had the same issue today. Problem was that the file was in another folder on the same server of the file calling the "save pdf" function.
copy("holdpath.bmp","samepath.bmp");
$writer->save("someotherpath.pdf");
unlink("samepath.bmp");
I am attempting to install the OCR software Tesseract onto my WAMP server so that I can then automate the OCR process for some images. When I search for how to install software onto a WAMP server, all I get back is how to install a WAMP server so that route turned up no answers. I have successfully installed Tesseract on my computer and know that the files I am using work properly, my issue is that I am unable to run Tesseract from a PHP script. I used the Windows installer that is provided and installed it to my www directory in WAMP. I then attempted to use the PHP exec() to perform some OCR and got no output. This is my simple script:
<?php
$path = getenv('PATH');
putenv("PATH=$path:/usr/local/bin");
$src = 'a.jpg';
$srcImg = imagecreatefromjpeg($src);
$img = imagecreatetruecolor($newClanWidth, $newHeight);
imagecopyresampled($img, $srcImg, 0, 0, $positions["aPlayer"], $positions[0], $newClanWidth, $newHeight, $clanWidth, $height);
imagejpeg($img, 'temp.jpg', 100);
echo '<pre>';
exec('tesseract temp.jpg out');
//echo file_get_contents('out.txt');
echo '</pre>';
imagedestroy($img);
?>
The image is being saved correctly. I can change the positions in the imagecopyresampled() and the image is changed accordingly. I suspect my problem is with the installation since everywhere I look everyone says to use exec() just like I would from a command line. I have also tried specifying the command like Tesseract-OCR/tesseract.exe temp.jpg out. The Tesseract-OCR folder is in the same directory as my PHP script. I admit to being new to this, so please bear with me if there is something simple I've overlooked. Thanks in advance.
what do you mean by "successfully installed Tesseract" ?
how did you verify that?
can you run tesseract.exe -v and get proper in command line (or however you call CMD on windows these days)?
if this works, than make sure that you get the same results by doing this via php:
make sure that you have errors turned on: error_reporting(-1) and check if you are getting any errors.
than try if you actually can execute tesseract via php by:
$return = shell_exec('tesseract.exe -v'); // in your example you miss .exe it would be without extension on linux
var_dump($return);
(shell_exec returns the all output, compare to exec what returns just the last line)
if that works, than try setting absolute path while extracting:
imagejpeg($img, 'c:/temp.jpg', 100);
$return = exec('tesseract.exe temp.jpg c:/out');
var_dump($report); // in case it gives you some errors
$content = file_get_contents('c:/out.txt');
if ($content === false) die('something is still wrong');
// otherwise process $content
if nothing helps, than share your results/errors.
last hint: try to install linux
I'm using TCPDF with Drupal's print module to generate PDF of articles, & ending up with following error message when I click the link to generate PDF:
TCPDF ERROR: [Image] Unable to get image: http://localhost/pathToDrupal/themes/bartik/logo.png
The Image exists in the location specified.
I tried applying:
allow_url_fopen = On;
allow_url_include = On;
in php.ini but that could not resolve the problem.
Please care to help :(
Apparently the "fopen"-wrappers are not used by TCPDF.
If you supply the URL of an image, TCPDF tries to download it with cURL into the "cache"-directory where your TCPDF-installation is stored (you have to check what the K_PATH_CACHE-constant contains to be sure).
So I guess you have to have write permissions in this directory that the magic works. Also you need cURL enabled.
We had problems with the way connections were handled in our linux "example.com" server. So this lead us to try on the server:
curl -v http://www.example.com/image.jpg
Whenever TCPDF tried to download an image with curl, the image was not found, nevertheless, we could view the image by just opening it directly in the browser (e.g. http://www.example.com/image.jpg).
We solved the problem by setting the example.com VirtualHost to accept 127.0.0.1 connections and adding the line "127.0.0.1 example.com" to /etc/hosts.
Just use the image path as "images/your_image.png" instead of "http://yourdomain.com/images/your_image.png" in the PDF html.
I've found that TCPDF would throw the Unable to get Image: error when the src was an absolute link. Just changing to a relative link would successfully create the PDF.
I had this problem on a staging server where the docroot of the site was protected by an .htaccess file (to prevent search engine indexing and other confusions)
tcpdf uses curl to fetch the image and it gives this error if it cannot access the file.
To solve it, I added a rule to .htaccess to allow requests from the webserver
Allow from 123.45.6.7.8
Try to add path by current working dir.
$img = getcwd().'/web/bundles/_bundlename_/img/logo.png';
$pdf->Image($base_url.'/'.$node->field_loc_images[0]['filepath'] ,30, 40, 75, 113, 'JPG', '', '', true, 300, '');
In your font unicode problems you need to put this syntax code:
// set font
$fontname = $pdf->addTTFfont('../your path here/sampletruetype.ttf', 'TrueTypeUnicode', '', 32);
$pdf->SetFont($fontname, '', <font size value here>);
put it before you add the page...
In drupal be sure to include the tcpdf library in your function and not at the top of your module file or you will get this error.
try this also
foreach($node->field_loc_images as $key=> $s)
{
$pdf->Image($base_url.'/'.$s['filepath'], $x, $y, $w, $h, 'JPG', '', '', false, 300, '', false, false, 0, $fitbox, false, false);
}
To expand on the error. It also seems to fail with base64 embedded images. This is a big problem for me right now.
After I upgraded PHP 5.5 to 5.6, I lost hours because of an image error,
I found the solution here from #caligari (a comment on the accepted answer) and it fixed the problem for me:
install CURL like this:
apt-get install php5-curl && /etc/init.d/apache2 restart.
In my case I tried to
curl -v http://www.example.com/image.jpg
and the "curl: (60) server certificate verification failed." was shown. So it was simply a certificate issue.
I am using GD to make thumbnails as required on my php site, but whenever I run the function:
include('resize-class.php');
function getThumbnail($album,$name){
if ($name != ""){
$file = dirname(__FILE__).'/pics/'.$album.'/'.$name.'.jpg';
$thumb = substr($file,0,-4).'-thumb.jpg';
if (!file_exists($thumb)){
$newThumb = new resize($file);
$newThumb -> resizeImage(100,100,"crop");
$newThumb -> saveImage($thumb);
}
$thumbi = pathinfo($thumb);
$thumb = '<img src="pics/'.$album.'/'.$thumbi['basename'].'" />';
}else{
$thumb = "";
}
return $thumb;
}
Where resize-class.php is the snippet used in this tutorial:
http://net.tutsplus.com/tutorials/php/image-resizing-made-easy-with-php/
Cherokee error log gets the following error:
[25/12/2010 00:16:30.759] (error) handler_fcgi.c:83 - Parsing error: unknown version
And an empty jpeg is created and the rest of the script completes (so the user sees a broken image icon instead of the desired thumbnail). The script worked fine on my windows machine using Abyss web server but when I ran it on Debian using cherokee and php-cgi it didn't work. And I made sure that extension=gd.so is set in php.ini in /etc/php5/cgi/ and /etc/php5/cli/.
phpinfo() shows that the GD module is loaded, but otherwise I don't know why it isn't working. You can view the phpinfo() here
A quick Google search on the error message suggested that a similar error was caused by a Cherokee update and a restart fixed it. Perhaps restarting the whole machine would work? Otherwise there isn't anything invalid with the code and you have a very new version of PHP - and since the rest of hte script completes, definitely a configuration issue somewhere.