The following [example] is a very short code to read the version number of a PDF document using PHP. I needed this recently during a PDF processing app developed in PHP. As Adobe uses different compression methods in various versions, it becomes necessary to be able to identify the version of the PDF under work.

The code opens the file with a fopen and parses a certain line for the major and minor version. The PDF extension for PHP can do something similar with the pdf_get_value function passing in either "major" or "minor" as the second parameter.

Following our tutorials on uploading files and listing files, this tutorial will walk you through deleting files from a directory. This is done using the unlink() function.

Their example is pretty simple (as is the concept) - they show how to check to be sure that the file you want to remove isn't in use/open and then issue the unlink to remove it from the file system.

PHP user streams are amazing - they're powerful, fun, and make things like a templating system with filters and multiple back ends quick and easy.

Here's a little "test script" that shows you how to implement contexts for your streams. What are contexts? They're resources that hold additional information. Built in php streams, such as the ftp streams, already have contexts you can set. But they're also great to use in your own user land streams.

In the test script, she shows how to open a stream to a few different resources (including passing parameters and user information), grabbing the contents of each.

The issue is actually a windows bug. No matter if I give or not the "b" flag to fopen, the write operations are not binary safe. It seems to be a known issue as many projects use the same trick.

The problem comes up when PHP forces the binary mode in SAPI and CLI, making the binary writes to a file non-binary safe no matter what. Pierre is also asking for help from anyone out there with any information/bug reports/references about this issue that would yield something useful.

As one man was quoted "640K of memory should be enough for anybody" no one will need to access more than 2 GB data. What happens if you - just for scientific reasons of course - try to access larger files using your 32bit hardware and your favorite programming language PHP?

They give the example of opening a large 2 gig file with PHP and the resulting error that would pop up. They try a few differnt ways before getting down to more of a non-PHP PHP solution (yes, you read that right). They decided, instead, to create a script to work with the file chunked, using an exec() call to the unix split command to break it up.