James
|
Best Answer
The limitations of the above formats (CSV, TSV, or SSV) cannot be overridden, but here is information on the ‘stacked’ format of the encoding for IDAutomation 2D barcode fonts, using DataMatrix as an example:
Data: 123456789012
Encoded Text:
AIHPBMGLGPHJDK<EOL>
AHFNDIIOKHAGLK<EOL>
ANHADOBOFFEJJK<EOL>
DLLDDLLDDDDDLL<EOL>
Where <EOL> is the hidden end of line character(s) that are OS-dependent:
• Windows: CRLF (sometimes CR)
• Mac: CR
• Linux or Unix: LF
Barcode Produced:
Note:
• The stacked format above must be present in the presentation side of the merge, when the font is applied to the encoding, or the result will be an unscannable barcode.
Suggestions*:
1. Where supported, we generally recommend using an alternate format, such as XML, JSON, or a similar format that can hold the stacked barcode encoding, yet allow for iterating through a collection/dataset. This is up to the software being used in the merge and not up to the font encoder or the barcode font.
2. Similar to point #1, if the software performing the merge can replace the EOL characters, perform the merge, then restore the replacement character back to the EOL character, the CSV, TSV, or SSV file formats may be able to be used.
3. A workaround available to Microsoft Office mail merges is to use the XLS or XLSM formats, merge using a provided data provider (managed by the Office data drivers), and merge the dataset into Word. This provides a way to retain the stacked format. See Microsoft Office documentation for more details on DDE and ADO drivers.
* While these issues are outside our control (and therefore not in the scope of support we provide), they are mentioned here to help clients understand the mentioned file format limitations.
 Posted 6.9 year(s) ago
|
Email this question link to friends 
My Profile 
