Hi, I think I found a bug in the DATAMATRIX implementation, though it seems to take a rather long string of data, and it's also very sensitive to what exactly is in the data.
This is with what I think is the latest version, 6.2.13, pulled from github just yesterday.
I know this string is capable of being encoded in datamatrix, though, as I've done it successfully with other DM creators.
I used this code, e.g.:
$pdf->write2DBarcode("@06@12S0002@PA9D8000000000@1P70431188AB@31P04311880AB@12V12345678@10VABC-DEFGHIJ@2PAB@20P@6D20170505@14D20180121@30P@ZN@K0042035913@16K293679",
'DATAMATRIX', 16, 16, 25, 25, array(), 'N');
which produces this encoded output when scanned:
@06@12S0002@PA9D8000000000@1P70431188AB@31P04311880AB@12V12345678@10VABC-DEFGHIJ@2PAB@20SXSKCG~o82~s~+097~q66~P@ZN/CCSKCOW'GLCGX/K'OY<4XE&?IP+0U#.!!63R.A7~
attached is a JPEG of the incorrect produced barcode.
In this example, weirdly, if I just remove the '-' character in the middle (ABC-DEFGHIJ), tcpdf creates a proper DM barcode. In other tests, I had to also remove a '#' character, but they both should work in DM barcodes, of course.
Also, in case this helps with your troubleshooting, this product does produce a correct barcode with the same string:
http://www.zint.org.uk/Manual.aspx?type=p&page=4
To update this ticket, I also found a similar (it was not, though, identical) bug in Zint, and reported that bug and it was fixed within a few days. I thought you might want to review the changes there that the dev added to fix the ticket, as it may help you with any related problems in TCPDF code.
https://sourceforge.net/p/zint/tickets/60/#4bf6