Downloaded / Resident Fonts

TrueType Fonts

Typically the fonts that are used are TrueType (TTF) fonts, or they are fonts that are already pre-loaded/pre-installed in the printer or the viewer technology. [PDF has many fonts that are intrinsically known by any PDF viewing technology.] When TTFs are used, Merge knows how to peer into them to discover character metrics and it knows how to subset the font so that only the characters that are used need to be defined in the output stream. If you have or can obtain a TTF version of a font, that is the best course of action to follow.

To indicate that you wish to use a certain typeface in your form designs, use the ConfigEditor tool to simply put a checkmark beside the typefaces of interest. ConfigEditor automatically finds the TTF files in your .prt's specified TTFPath.

Resident Fonts

Some (most?) printers have intrinsic knowledge of a certain set of fonts. DocOrigin includes font metrics files for the most popular of these fonts. You can see those in the .../DO/Config folder as .mtx (metrics) files. Even in those cases, the .mtx files most often contain a reference to a .ttf file, which will be used if it can be found on the system (in the nominated TTFPath). On a Windows-based system, often the referenced .ttf file will be found and used. Otherwise, the character metrics defined in the .mtx file will be used. If your printer has a resident font for which no .mtx file is available, you can create your own, since the .mtx files are openly readable text.

To indicate that you have resident fonts in your printer, edit the relevant printer configuration file (.prt) with a text editor and enter in lines such as:

<ResidentFont Typeface="Courier New" Bold="*" Italic="*" ID="4099"/>

You can find examples of that in each shipped Default-xxx.prt file. Add to the list of resident fonts that are known to be in your printer. There are comments in the .prt to help you.

These "resident" font notes also apply to fonts which, through your own procedures, are always permanently downloaded into the printer.

Soft Fonts (PCL only)

If you have non-TTF fonts which you want to download into the output stream, then first, do consider finding a TTF alternative. However, if you must use these non-TTF (bitmap) fonts, then it is possible to do that. You must have a font definition file; typically a .SFP, or .SFL file, though other extensions are used as well. To make Merge aware of these fonts you would edit the relevant printer configuration (.prt) file with a text editor.

After the "<Printer>" tag, you should enter line(s) such as:

<DownloadFont_MICR300>MICR300.SFP</DownloadFont_MICR300> 

where MICR300 is an example of the typeface being downloaded. The "MICR300.SFP" is the example of the file name that houses the soft font definition.

In many cases, the font may have bold, italic, and bold-italic variations. For this non-ttf technology, you will need to specify the soft font file to be used for each variation. E.g. in the style of:

<DownloadFont_typeface>xxxxxxxr.SFP</DownloadFont_typeface>
<DownloadFont_typeface_B>xxxxxxxb.SFP</DownloadFont_typeface_B>
<DownloadFont_typeface_I>xxxxxxxi.SFP</DownloadFont_typeface_I>
<DownloadFont_typeface_BI>xxxxxxbi.SFP</DownloadFont_typeface_BI>

Often there is no direct correlation between the typeface name and the soft font definition file name. Hence the example shows xxxxxx rather than typeface. The important point is the <nothing>, _B, _I, _BI tag suffixes. If your form designers will be clicking on the Bold and or Italic buttons for text rendered in this typeface, you will need those entries.

Those entries tell Merge where to get the soft font bits to copy to the output stream. It does that only if that particular typeface variation is actually used in the document.

You must also tell Merge (and Design) that the given soft font is available to use. You would do that by text editing the relevant .prt file and adding line(s) such as:

<Font MTX="xxxxxx.mtx"/> 

There are lots of <Font... entries present in any .prt so as to guide you as to placement.

You should notice the inference that you also need a font metrics (.mtx) file. As the downloaded font is not a .ttf file, you must supply the font metrics, just as was necessary for resident fonts.

A note about the .mtx files for dynamically downloaded soft fonts... Looking at the shipped arial.mtx file as an example, you will see that it starts with:

<font sTypeface="Arial" sPostscriptName="ArialMT" iBold="0" iItalic="0" iTTCNum="0" TTF="arial.ttf"/>

For dynamically downloaded soft fonts you must not supply the TTF= attribute. Otherwise, it would use that TTF file instead of your downloadable soft font. You also may as well leave off the iTTCNum= attribute. It will be useless.

Do specify the sTypeface= attribute. Also, note that many .mtx files could specify the same typeface name. This would certainly be the case for metrics for the regular, bold, italic, and bold-italic variations of a given typeface. Do not call one ABCBold and another ABCItalic, otherwise, both of those names will show up, confusingly, in the Design typeface dropdown. They should both be ABC and the form designer should select the B or I button(s) as per normal.

Finally, if you wish, you could consolidate several .mtx files into one larger file simply by concatenating multiple <FontMetrics>...</FontMetrics> sections into a single file. To keep it a well-formed XML file you could surround the whole set with <root>...</root>. Your .prt file would then need to reference only that one .mtx file in a <Font MTX="..."/> line rather than the multiple entries that would have been required otherwise.

MTX File Units

Font metrics (.mtx) files are pretty much internal -- rarely being looked at by anyone. However, if you have resident or dynamically downloaded non-TTF fonts, then their contents can be of interest. Naturally, a "metrics" file contains numbers for widths etc. In the DocOrigin world, the internal unit is a millionth of an inch. Of particular importance here is that in a .mtx file the widths given are for a hypothetical 1-point font. Naturally Merge does the applicable scaling. Note also that as these are in real-world length units, they are not affected by the DPI of the printer. Merge works it all out.

In JetForm Central .L4 files the character width (CWidth) entries varied by whatever point size the .L4 file was for, and the units (even though they had decimals) were in 'dots' with a presumed printer resolution of 300 dpi. Converting a .L4 CWidth to DocOrigin .mtx units requires that you divide by the .L4's point size and multiply by (1000000/300).