JCAMP-DX implementation

Supports many more types of JCAMP-DX files. Previously it could only open the test file 1DSpectrum.jcamp (from an old version of MestReNova), all other test files - including those exported by newer MestReNova versions - failed. Now it can open all files from nmr_datafiles (see also nmr_datafiles!7 (merged)) as well as the IUPAC files. Fixes #343 (closed)

Note regarding the commits: the first few fixed small issues, but as test spectra kept failing with further issues I rewrote the entire thing. I kept the small commits for now, but would advice to look at the overall changes. Major changes are listed below

Most notable changes

File extensions

• Handle file extensions case-insensitive

DX readout

• Properly handle comments, multiline values, arbitrary whitespace
• Avoid relying on optional variables
• Handle data decoding the same for FID and spectrum
• Set reference when possible

decoding fixes

• proper handling of Y checkpoint (only discard if ending with DIF on the previous line)
• handle e.g. spaces and other separators (other than in the final line)
• support all data encodings specified in the IUPAC standards

metaData

• Extract metaData

A few things have not been handled:

• MestReNova-exports seem to require the complex conjungate for X++(I..I) data
• Y-scaling seems to be incorrectly set for some exports, but this seems to be on the exporting software's side
• Newer TopSpin versions require the readout of ##$SF to get the reference in JCAMP v5 data files, for older it's the opposite... I picked the newer version while removing a little tear ( ;) ) that I have to use some custom vendor-defined key for this instead of the JCAMP standard.
• I didn't go through the effort of extracting all the possible dFilter options for the different spectrometer software (and their versions) and custom JCAMP keys... Users can use the first order phase correction ;). An issue was filed.

To discuss

• I kept special handling of AFFN. I do however not have test data that needs this as AFFN is a subset of ASDF. The only scenario I can think of involves data with an e or E in a number to indicate a power of 10. I could remove all encoding-key related code (its optional anyway) to simplify the code, leaving the other parsing only as a fallback (for those e/E-numbers)