Unicode Unsupported Features
The following areas are exceptions to the rule that Unicode is supported everywhere by CopiaFacts version 8:
In general, the board manufacturers' application program interfaces (APIs) do not support Unicode pathnames. In most cases CopiaFacts will copy the file to a temporary folder with an ASCII pathname before transmission, but this is currently only supported for Diva, TE-Systems, Brooktrout and Faxmodem boards, and for BladeWare. For other boards you should therefore arrange for folders from which files are faxed or to which faxes are received to be named without using non-ASCII characters in the pathname.
CopiaFacts Standard Folders
For pathnames within the COPIA share:
•Only ASCII pathnames are supported within the CALLBACK and MAIL folders.
•Non-ASCII infobox names are supported, but not recommended because of issues with the range parameters on the $script_locn command.
All folders defined for temporary files must only have ASCII pathnames, because CopiaFacts may copy a file there to avoid a Unicode pathname restriction.
Fax Configuration Files
Board manufacturers' files (for example BTCALL.CFG) only support ASCII encoding.
Fax Cover Sheet Files
ASCII cover sheet files (where supported directly by the fax board) are limited to ASCII encoding and therefore CopiaFacts does not support Unicode in these files or their pathnames. Use CopiaFacts Graphical Cover sheets if you need to personalize faxes with Unicode text.
Fax Header Text Line
Most fax boards support only ASCII in fax header (and footer) lines. Use the $apply_gct command to add non-ASCII text in fax header lines.
Algorithm files for the CopiaFacts voice phrase-speaking feature must currently be ASCII files only.
The files NEXTFS, NEXTMCF and NEXTCALLNO will always have ASCII content and must be in system default encoding.
Incoming e-mail address/domain
The CopiaFacts E-Mail Gateway currently supports only ASCII e-mail addresses for use in sender and recipient filenames. If your application does not require a template file named with the sender or recipient address, mail can be received when sent to or from a non-ASCII e-mail address. To save non-ASCII text from an incoming e-mail in FS file variables, you should set FS file encoding to UTF-8 or Unicode to avoid loss of data, unless all the incoming text is known to be supported in the system default encoding.
Syntax elements in Unicode command files, such as space, at-sign, double-quote, comma, pipe-symbol, semi-colon, etc. must be written as the standard ASCII characters, not using non-ASCII Unicode graphemes with similar appearance. These ASCII characters do not form part of any UTF-8 multi-byte sequence.
The special FFMERGE font contains only ASCII characters. FFMERGE action line text does not therefore support Unicode.
GCT files do not support UTF-16 encoding, only UTF-8 (or system default font). The same applies to the GCT content embedded in a GTT file.
Staged Local Copy
The Copia print drivers do not yet support a Unicode (non-ASCII) folder name for the output folder.
The DBF format does not support recording the encoding of data fields and all files are therefore assumed to be in system default encoding. The output from JOBDDATA will be converted to system default encoding, which may result in loss of data if the file contains Unicode data in variables.
CopiaFacts Trace Files
If you wish to be able to view Unicode text in trace files, only UTF-8 encoding is allowed, not UTF-16. This helps to keep trace files to a manageable size.
|We strongly recommend setting UTF-8 encoding for trace files, for performance reasons. And in some cases, text written to the trace file assumes that the trace file encoding is set to UTF-8 and will not display correctly if it includes non-ASCII characters.|