_fnHtmlDecode converts '\r' to 'n'

mattreek

[code]
"_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= 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;
}
[/code]

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

allan

No - not browser specific - this is a limitation in the bridge format I used between JS and AS. I should really have used JSON in retrospect...

I've just created this issue in GitHub for me to get around to doing this: https://github.com/DataTables/TableTools/issues/27

Thanks for flagging it up.

Allan

mattreek

I see. The same holds for tabs, which are used as column delimiter in ZeroClipboardPdf.as.