_fnHtmlDecode converts '\r' to 'n'

	"_fnHtmlDecode": function ( sData )
	{
		if ( sData.indexOf('&') == -1 )
		{
			return sData;
		}
		
		var 
			aData = this._fnChunkData( sData, 2048 ),
			n = document.createElement('div'),
			i, iLen, iIndex,
			sReturn = "", sInner;
		
		/* nodeValue has a limit in browsers - so we chunk the data into smaller segments to build
		 * up the string. Note that the 'trick' here is to remember than we might have split over
		 * an HTML entity, so we backtrack a little to make sure this doesn't happen
		 */
		for ( i=0, iLen=aData.length ; i<iLen ; i++ )
		{
			/* Magic number 8 is because no entity is longer then strlen 8 in ISO 8859-1 */
			iIndex = aData[i].lastIndexOf( '&' );
			if ( iIndex != -1 && aData[i].length >= 8 && iIndex > aData[i].length - 8 )
			{
				sInner = aData[i].substr( iIndex );
				aData[i] = aData[i].substr( 0, iIndex );
			}
			
			n.innerHTML = aData[i];
			sReturn += n.childNodes[0].nodeValue;
		}
		
		return sReturn;
	}

This function in TableTools.js converts the character '\r' (CR) to '\n' (LF) by setting aData as the innerHTML of a a DOM node. This is a problem when you want to export column values with multiple lines of text to PDF, since the layout gets messed up, because ZeroClipboardPdf.as treats '\n' as the beginning of a new row. Therefore '\n' are stripped in the method _fnGetDataTablesData, but by calling _fnHtmlDecode afterwards they reappear, if the column data contained at least on HTML entity.


To reproduce this you'll have to export a table to PDF where at least one column has multiline text (seperated with "\r\n") and also has at least one HTML entity in it (e.g. """). Since i'm not sure if the problem is browser specific here is my test setting:

DataTables: 1.9.4
TableTools: 2.1.3
Browser: Google Chrome 26.0.1410.65
OS: Mac OS X 10.7.5