<?php  if (!defined('BASEPATH')) exit('No direct script access allowed');

and end with:

/* End of file MyFile.php */
/* Location: ./path/to/file/MyFile.php */

The line at the start of the file is a security measure to stop files being executed outside the framework, whilst the end is just informative but useful anyhow.

I like to do the same thing with all the files I create for my applications but found the typing tedious and because I use the VS.php in Visual Studio, I decided to write a couple of snippets to do it for me.

If you are not familiar with snippets in Visual Studio or how to get the following xml to work as a snippet, you can read all about then on msdn. Anyhow, without further ado, here they are:

filestart.snippet:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>filestart</Title>
      <Author>Dan Sargeant</Author>
      <Description>CodeIgniter File start to stop direct script access</Description>
      <HelpUrl></HelpUrl>
      <SnippetTypes>
          <SnippetType>Expansion</SnippetType>
	      <SnippetType>SurroundsWith</SnippetType>
	  </SnippetTypes>
      <Shortcut>filestart</Shortcut>
    </Header>
    <Snippet>
      <Code Language="PHP" Kind="" Delimiter="$"><![CDATA[<?php  if (!defined('BASEPATH')) exit('No direct script access allowed');
]]></Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

fileend.snippet:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>fileend</Title>
      <Author>Dan Sargeant</Author>
      <Description>CodeIgniter file ending</Description>
      <Shortcut>fileend</Shortcut>
      <SnippetTypes>
          <SnippetType>Expansion</SnippetType>
	      <SnippetType>SurroundsWith</SnippetType>
	  </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>filename</ID>
          <ToolTip>Filename</ToolTip>
          <Default>myfile.php</Default>
        </Literal>
        <Literal>
          <ID>directory</ID>
          <ToolTip>Directory</ToolTip>
          <Default>models</Default>
		  </Literal>
      </Declarations>
      <Code Language="PHP"><![CDATA[
/* End of file $filename$*/
/* Location: ./application/$directory$/$filename$*/]]></Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

I stepped through the code and discovered that I was using the set_value() function to retrieve the value posted from the form. This is a no-go I’m afraid. set_value is supposed to be used to set the values of inputs and textareas in forms within the view itself and as such runs the htmlspecialchars function across the form post value before returning it. There is a function specifically designed for what I wanted: $this->input-post(fieldname). Lesson learned.

This spurred me on to take some time to see what all the fuss about IIS7 and php was really about. I was pleasantly surprised. Since Vista SP1, it is possible to configure IIS to run php using FastCGI. I won’t go into the detail here, there are plenty of examples on how to configure php in this way. Needless to say, it was not too difficult and I had a test phpinfo(); page displaying in no time. What’s particularly great is that Microsoft has been doing some great work getting php to run as quickly and efficiently as it can on IIS. If you are happy running php version 5.3, over at Php for Windows, you can pick up a version that has been compiled in Visual Studio 2008 which means faster and more stable than before.

The next step in my investigation was to see what could be done with the new url rewrite module for IIS. Another easy thing to install. What’s more, it has the ability to import .htaccess files. I use these extensively when using Apache and I already had one for the WordPress site I was working on. Importing rules is a pleasure because of the neat interface that shows you which rules it can convert and which it cannot. Editing the original .htaccess directives on-screen allows you to fix those rules it is having trouble with. In my case it was just the RewriteBase, which I could happily remove without worrying about it.

One click of the ‘apply’ button and I was up add running. The site was responsive and low and behold, no issues with the friendly urls. Too easy!

I have been working with text files that contain multi-byte characters and had previously ensured that my database and tables were setup for UTF-8 and that everything in codeigniter was correctly configured. Yet still I was getting invalid character errors on the database insert.

As the text files were of varying formats, including excel’s unicode csv format, I had already ensured that the reading of the text file also included conversion to UTF-8. Thanks to the script on Practical Web Ltd, I was attempting to detect the format of the files and converting them to UTF-8 on the fly. Yet still I was getting invalid character errors on the database insert.

I even ran through my code line by line and checked for any string manipulation I was doing using non-safe string functions. Yet still I was getting invalid character errors on the database insert.

If I had any decent amount of hair left, I would certainly have pulled it all out by the time I figured out what was wrong. I only discovered the answer by accident when I decided to remove the string manipulation altogether. As soon as I did that, it worked a treat. Had I discovered a bug in the multibyte string functions? No.

I had not checked the default encoding of mbstring.

So please, make sure it is on your check list of things to do when dealing with multi-byte strings. Set up the default correctly or religiously use the encoding parameter in the multi-byte string functions.

Even better, you could use the great checklist on nicknettleton.com (see below), which seems to cover everything.

I totally deserved the dunce hat.

Edit: Looks like the link on nicknettleton.com is no longer available (thanks @Les). A little digging around led me to the same checklist on php UTF-8 on another site.

The particular comment in question, from mike, made me realise that there was a bit of a flaw in my neat idea – page breaks. Because I was first drawing the text, the automatic page breaks played havoc with the positioning when it came to drawing the borders. If the text was so long that it wrapped across enough lines to cause a page break, when I tried to reposition to draw the borders I was in completely the wrong place and it all went a little Pete Tong.

Still, not deterred by this little setback, I re-looked at the problem and have come up with a different approach that solves this problem and adds the ability to do a few more things.

When I relooked at the documentation, I discovered the useful little function: getNumLines(). This actually allows us to determine how many lines a string of text will take up, given a particular width. In effect, it allows us to do what I was using MultiCell to return, without actually drawing anything. This lets us to determined the maximum cell height with one line of code:

$linecount = max($pdf->getNumLines($row['cell1data'], 80),$pdf->getNumLines($row['cell2data'], 80),$pdf->getNumLines($row['cell3data'], 80));

Now that we know the cell height before we have drawn anything, we can use MultiCell() to draw the text and the borders at the same time.

This was not the end, however. My particular implementation was a grid of data that had borders between the column and not between the rows. All very pretty until that automatic page break happened and gave us a grid of data without a border at the bottom. To add insult to injury, the new page ended up with a grid of data with no border at the top!

To solve this, I needed to know if the row was going to be the first of the page, so I could draw the bottom border on the previous row and give the new row a top border. With the use of the page dimensions I could work this out:

$dimensions = $pdf->getPageDimensions();
$hasBorder = false; //flag for fringe case
 
foreach($data as $row) {
	$rowcount = 0;
 
	//work out the number of lines required
	$rowcount = max($pdf->getNumLines($row['cell1data'], 80),$pdf->getNumLines($row['cell2data'], 80),$pdf->getNumLines($row['cell3data'], 80));
 
	$startY = $pdf->GetY();
 
	if (($startY + $rowcount * 6) + $dimensions['bm'] > ($dimensions['hk'])) {
		//this row will cause a page break, draw the bottom border on previous row and give this a top border
		//we could force a page break and rewrite grid headings here
		if ($hasborder) {
			$hasborder = false;
		} else {
			$pdf->Cell(240,0,'','T'); //draw bottom border on previous row
			$pdf->Ln();
		}
		$borders = 'LTR';
	} elseif ((ceil($startY) + $rowcount * 6) + $dimensions['bm'] == floor($dimensions['hk'])) {
		//fringe case where this cell will just reach the page break
		//draw the cell with a bottom border as we cannot draw it otherwise
		$borders = 'LRB';	
		$hasborder = true; //stops the attempt to draw the bottom border on the next row
	} else {
		//normal cell
		$borders = 'LR';
	}
 
	//now draw it
	$pdf->MultiCell(80,$rowcount * 6,$row['cell1data'],$borders,'L',0,0);
	$pdf->MultiCell(80,$rowcount * 6,$row['cell2data'],$borders,'L',0,0);
	$pdf->MultiCell(80,$rowcount * 6,$row['cell3data'],$borders,'L',0,0);
 
	$pdf->Ln();
}
 
$pdf->Cell(240,0,'','T');  //last bottom border

Note that there is a fringe case that I came across. This was when the row would not cause a page break as it was exactly the height of the remaining space. Any attempt to draw the bottom border with a separate call would cause a page break. I solved this by ensuring in that particular case, the cell was drawn with the bottom border already.

What gives this method more power (apart from actually working) is that we know when there is going to be a new page and we could choose to force a new page and if we wanted. We could then re-plot the grid headings before creating the row. That way we can have the grid headings on every page.

I am determined to get a water-tight solution to this problem and I think this gets us closer. If you do find any problems with it, let me know and I will see if we can solve them. Thanks for your feedback.

Update: Bretton Eveleigh has written a class that encapsulates this and other helper methods into a format that makes creating tables with Tcpdf much easier. See the comments below for the link. Thanks Bretton.

During my use of the excellent tcpdf library for creating pdf documents with php, I came across an interesting problem when creating a pdf featuring a grid of data. Although I could have use an html grid to present the data, I was trying to avoid the use of html and keep to the Cell(), MultiCell(), Text() etc. methods to render the document.

The content of some of the cells in this particular grid were quite long and so some wrapping of text would (and needed to) occur. The MultiCell method handles this and will wrap the text, expanding accordingly. Now I was trying to make a grid row, so needed all of the cells to be the same height – and there lay the problem – I did not know how high to make the other cells. It was a chicken and egg situation: I needed to know the height of the cell before drawing them but did not know how high they needed to be until after I had drawn them.

I studied the documentation hard but realised that the answer was not to try and generate the cells, borders and all, in one pass. I could achieve what I needed by drawing each row twice – once for the content and once for the borders.

The MultiCell function kindly returns the height that the cell was drawn, so by remembering the maximum value it was when drawing a row of cells, I could then go back and draw the borders to that maximum height:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

foreach($data as $row) {
	$maxnocells = 0;
	$cellcount = 0;
	//write text first
	$startX = $pdf->GetX();
	$startY = $pdf->GetY();
	//draw cells and record maximum cellcount
	//cell height is 6 and width is 80
	$cellcount = $pdf->MultiCell(80,6,$row['cell1data'],0,'L',0,0);
	if ($cellcount > $maxnocells ) {$maxnocells = $cellcount;}
	$cellcount = $pdf->MultiCell(80,6,$row['cell2data'],0,'L',0,0);
	if ($cellcount > $maxnocells ) {$maxnocells = $cellcount;}
	$cellcount = $pdf->MultiCell(80,6,$row['cell3data'],0,'L',0,0);
	if ($cellcount > $maxnocells ) {$maxnocells = $cellcount;}
	$pdf->SetXY($startX,$startY);
 
	//now do borders and fill
	//cell height is 6 times the max number of cells
	$pdf->MultiCell(80,$maxnocells * 6,'','LR','L',0,0);
	$pdf->MultiCell(80,$maxnocells * 6,'','LR','L',0,0);
	$pdf->MultiCell(80,$maxnocells * 6,'','LR','L',0,0);
 
	$pdf->Ln();
}

Note that the last parameter I set in MultiCell is set to 0 which means that no new line occurs once a cell is drawn. This means that the cells will appear side-by-side and also means that I need to manually create the new line when I finish drawing the row.

<?=$this->validation->myfield_error?>

It seemed much neater with the new validation class:

<?=form_error('myfield');?>

What I found however, was there was no simple way to style a particular field if it it had an error. I wanted a similar method to displaying the error message but which would output the error css class name, if there was an error with the field.
After poking around the new validation code, I discovered that creating such a function would require the extension of two of the base files – the helper form_helper.php would be the place to put the function that I could call from the view and the library form_validation.php would be the place where I could put a function that checks whether a particular field is valid or not.
CodeIgniter provides a way to extend these files easily by placing a file of the same name with the prefix ‘MY_’ inside the appropriate folder in the application directory. So, to create the functionality I wanted, I created a MY_form_helper.php and put the following code into it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
if ( ! function_exists('error_class'))
{
	function error_class($field = '')
	{
		if (FALSE === ($OBJ =& _get_validation_object()))
		{
			return '';
		}
 
		return $OBJ->errorclass($field);
	}
}
?>

Then I created a MY_Form_Validation.php file and placed the following in it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');
 
class MY_Form_validation extends CI_Form_validation {
 
	function errorclass($field = '') {
		if ( !isset($this->_field_data[$field]['error']) OR $this->_field_data[$field]['error'] == '')
		{
			return '';
		} else {
			return ' invalid';
		}
	}
}
?>

With these two changes, I was then able to set the classes of my field as follows:

<input type="text" name="myfield"  value="<?=set_value('myfield');?>" class="<?=error_class('myfield');?>" />

This kept the method in line with the set_value and the form_error functions and set the class to ‘invalid’ when an error occurred.

There always seems to be a trade-off between flexibility and ease of use with these libraries and tcpdf seems to lean more towards the flexibility side of things. I prefer this, as there would be nothing worse that committing oneself to a particular library, only to find that it is not possible to generate a particulr report further down the track. On top of this, the library is available in PHP4 and PHP5 versions and is open source, should one need to tweak it any way.

Installation is pretty straight forward for and there are suitable instructions telling you how. In my case, however, I am using the CodeIgniter framework and needed to take some additional steps in order to use it. If anyone else is also using CodeIgniter, here is how I do it:

1. Unpack the tcpdf installation package into your  system/plugins folder. This will give you a tcpdf directory in the plugins directory.
2. Create a tcpdf_pi.php file inside the plugins directory. Place the following code in it:

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
require_once('tcpdf/config/lang/eng.php');
require_once('tcpdf/tcpdf.php');
 
// Extend the TCPDF class to create custom Header and Footer
class OnemoretakePDF extends TCPDF {
}
 
function tcpdf(){
    return new OnemoretakePDF (PDF_PAGE_ORIENTATION, PDF_UNIT, PDF_PAGE_FORMAT, true);
}
 
?>

Here, we basically instantiate tcpdf and pass in a few of the default values. You may be wondering why I have extended the TCPDF class and have not just instantiated it directly. Well, I shall come to that later.

To use this in CodeIgniter, you load the plugin and then create an instance of  it as follows:

1
2

$this->load->plugin( 'tcpdf' );
$pdf = tcpdf();

The next step really, is to visit the documentation for tcpdf. It is not the easiest to follow set of documentation there is, as it has been generated directly from the code, although there are several examples that you can pull apart to learn more. The premise here is to create a new pdf page and plot what you want on that page. This can be done directly with commands like Text() and Line() which use coordinates directly or you can also use Cell() and MultiCell() which allow you to draw using a cell system like a table and utilise borders and alignment appropriately. For those who just cannot get their heads around plotting on a page, there are commands to plot HTML, although support for styles is limited, so don’t expect to recreate a fancy webpage layout by throwing the html at it. I found that with a little bit of lateral thinking, most jobs can be done without the HTML methods anyhow.

What took me a little time to get used to, is that the coordinate system is not in pixels but by default, in millimetres. This actually makes a lot of sense, as we are creating for print here, not screen. This makes it very awkward if you are working off a design done in photoshop or similar and want to get the dimensions just right. However, a trick I soon learned was to print that image directly to a pdf and then you can use the measurement tools in your pdf reader (Foxit reader has such a tool) to measure the correct distance in millimetres.

The API for tcpdf is extensive and with it, one can achieve most tasks. One thing to note, however is that to create a standard header and footer for your document, you need to override the default header and footer methods in the main tcpdf class. This is why, in the code above, I extended the tcpdf class. It will give us the opportunity to override these methods as follows:

1
2
3
4
5
6
7
8
9
10
11

class OnemoretakePDF extends TCPDF {
    //Page header
    public function Header() {
        //header plotting code here
    }
 
    // Page footer
    public function Footer() {
      //footer plotting code here
    }
}

My biggest gripe about this library is that the documentation does not give enough detail. Coupled with that, the forum is a SourceForge forum, which frankly I find very difficult to find anything in. It would be great if there was a way to get more detail, perhaps a wiki would benefit the project a great deal – I am sure there is a lot of detailed knowledge out there about the ins and outs of the library, its just that there is no way to tap into it.

You can’t complain too much however, this project provides a very powerful pdf creation library. I have had experience with Microsoft.Net libraries of a similar nature and you can end up paying quite a lot for them. Not to mention they tend be way more restricted as to what is possible.