Solaris 8 Software Developer Supplement

mp(1) Print Filter Enhancement Overview

The mp(1) print filter is enhanced with the ability to work as an X Print Server client in the 2.5.11 version. This section describes how to customize the behavior of mp(1).

Customization can be divided into

The following information outlines what to do if mp(1) is not printing the correct output. The new enhancements done to the mp version 2.5.11 permit it to work as an X Print Server client.

If a correctly configured X Print Server is running, then mp(1) prints correctly in the target locale without changing any of the configuration files described below. If you do not have a working X Print Server, localize /usr/lib/lp/locale/$LANG/mp/mp.conf as described in the next section. mp.conf file effectively achieves the same functionality as the file available in some locales under /usr/openwin/lib/locale/$LANG/print/. The file can also be customized.

/usr/lib/lp/locale/$LANG/mp/ directory can also contain the file. This file is provided for backward compatibility purposes only, and users are encouraged to use either the direct X Print Server client mode, when giving -P or -D options, or by configuring the mp.conf file. For changing the appearance of the output, customize the existing prolog files.

The following guidelines describe how the choice of a configuration file is made by mp(1)

The following guidelines describe how a PostScript (.ps) or X Print client page (.xpr) formatting file is selected.

Localization of the Configuration File

The idea behind configuration files is to capture the flexibility they provide when adding or changing font entries, or font group entries, as the need arises.

The system default configuration file that is used is /usr/lib/lp/locale/$LANG/mp/mp.conf where $LANG is a locale environment variable in the locale in which printing occurs. Users can have a personal configuration file that can be specified by the '-u <config.file path>' option.

The mp.conf file is used mainly for mapping the intermediate code points in a locale to the presentation forms in the encoding of the font that is used to print that code point.

Note –

A ligature or variant glyph that has been encoded as a character for compatibility is called presentation forms.

Intermediate code points can either be Wide Characters or output of the Portable Layout Services (PLS) layer. Complex Text Layout printing requires that the intermediate code points be PLS output. The default intermediate code generated by mp(1) is PLS output.

Font formats currently supported are Portable Compiled Format (PCF), TrueType, and Type1 format. Both system-resident and printer-resident Type1 fonts are supported.

mp.conf configuration file localization is for configuring mp to print according to the needs of a specific locale. The following describes the format and contents of the mp.conf configuration file for mp(1).

The following list describes different sections in the mp.conf file.

Font Aliasing

This section is used to define alias names for each font used for printing. Each line in this section is of the form

keyword			font alias name		 	font type 		   font path			

The keyword for this section is FontNameAlias.

<font alias name>

The usual convention for aliasing a font name is to specify the encoding/script name of the font followed by a letter that indicates whether the font is Roman, Bold, Italic, or BoldItalic (R, B, I or BI). For example /usr/openwin/lib/X11/fonts/75dpi/courR18.pcf.Z, since it is an iso88591 Roman font, can be given the alias name iso88591R.

<font type>

Specify PCF for .pcf fonts, Type1 for Adobe Type1 fonts, and TrueType for truetype fonts. Only these three kinds of fonts can be configured in this config. file.

<font path>

Give the absolute path name for the font files here. For type1 printer-resident fonts, just specify the font name. See the following example.

FontNameAlias			 prnHelveticaR 			 Type1  			  Helvetica

Font Group Definition

You can combine same-type fonts to form a font group. The format of the font group is as follows.

Note –

For creating a group, only a Roman font entry is required. The Bold, Italic, and BoldItalic fonts are optional. The different types of fonts are used to display the header lines for mail/news articles. If only the Roman font is defined, it is used in place of other fonts.

Mapping From the Intermediate Code Ranges to the Font Group in a Locale

Associating Each Font With the Shared Object That Maps the Intermediate Code Points to the Presentation Forms in the Fonts Encoding

Note –

The Current TrueType Engine employed by mp(1) is capable of dealing only with format 4 and PlatformID 3 cmap. That is, you can only configure Microsoft .ttf files. Additionally, the character map encoding has to be Unicode or Symbol for the TrueType font engine to work correctly. Because most of the .ttf fonts in the Solaris environment are obeying these restrictions, you can map all TrueType fonts in Solaris software within the mp.conf file.

When you create a shared object for mapping a font that corresponds to an X Logical Fonts Description (XLFD) , consider the following. If you are mapping a pcf/type1 font, then create the shared object that maps from the intermediate code range to the encoding specified by XLFD. For example:


The corresponding pcf font is:


This font is encoded in iso8859-8, so shared objects have to map between intermediate code and corresponding iso8859-8 code points.

But if a TrueType font with XLFD:


has the corresponding font:


In this situation, map between the intermediate code and Unicode, because the cmap encoding for the previous TrueType font is in Unicode. In the example of this TrueType font, if a sample intermediate code in the en_US.UTF-8 locale that corresponds to a Hebrew character (produced by the PLS layer) is 0xe50000e9, you need to consider the following. Because the font is Unicode encoded, design the function within the corresponding .so module in such a way that when you are passing 0xe50000e9, the output corresponds to presentation form in Unicode. The example here is 0x000005d9.

The function prototype for the <mapping function> should be:

unsigned int function(unsigned int inter_code_pt)

The following are optional keyword/value pairs that you can use in mp.conf:

PresentationForm        WC/PLSOutput

The default value is PLSOutput. If the user is specifying "WC", then the intermediate code points that are generated are Wide Characters. For CTL printing, this default value should be used.

If the locale is non-CTL locale and has the value for the keyword is PLSOutput, it is ignored and the mp(1) generates wide-character codes instead.

You can use the following optional keyword/value pairs if the locale supports CTL. These variables can assume any of the possible values given on the right side of the table.









Default is TEXT_SHAPED 

The following example illustrates the steps that you need to follow when you add a new PCF, TrueType, or Type1 printer-resident font to the configuration file.

Replace the font for displaying characters in the range 0x00000021 - 0x0000007f with a TrueType font instead of the currently configured PCF font.

Before adding a new font, look at various components in the configuration file that correspond to the currently configured font, as shown next.

FontNameAlias   iso88591R       PCF     /usr/openwin/lib/X11/fonts/75dpi/courR18PCF.Z
FontNameAlias   iso88591B       PCF     /usr/openwin/lib/X11/fonts/75dpi/courB18PCF.Z
FontGroup       iso88591         PCF       iso88591R iso88591B
MapCode2Font    0x00000020      0x0000007f      iso88591
CnvCode2Font    iso88591R _xuiso88591 /usr/lib/lp/locale/$LANG/mp/
CnvCode2Font    iso88591B _xuiso88591 /usr/lib/lp/locale/$LANG/mp/

Suppose you selected /usr/openwin/lib/locale/ja/X11/fonts/TT/HG-MinchoL.ttf as your candidate for doing the mapping in the en_US.UTF-8 locale. Because this is a Unicode character-mapped TrueType font file, in the mapping function within the .so module you only need to have a function that directly returns the incoming ucs-2 code points.

unsigned short _ttfjis0201(unsigned short ucs2) {

Save this in a ttfjis0201.c file. Create a shared object as follows.

cc -G -Kpic -o ttfjis0201.c

But if you are mapping a PCF file, such as /usr/openwin/lib/locale/ja/X11/fonts/75dpi/gotmrk20.pcf.Z, then look in the fonts.dir file in the /usr/openwin/lib/locale/ja/X11/fonts/75dpi/ directory. Become familiar with the encoding, corresponding to XLFD, which is:


If jisx0201 is the encoding, prepare a shared object that maps from ucs-2 to jisx0201. You need to obtain the mapping table for creating the .so module (if one is not already provided). For a Unicode locale, find the mappings from the many charsets to Unicode under Follow these mappings, in order to write a xu2jis0201.c file:

 unsigned short _xu2jis0201(unsigned short ucs2) {
                         if(ucs2 >= 0x20 && ucs2 <= 0x7d )
                                 return (ucs2);
                                 return (0x7e);
                         if(ucs2 >= 0xff61 && ucs2 <= 0xff9f)
                                 return (ucs2 - 0xff60 + 0xa0);

When you create a mapping file, include all the UCS-2 to jisx0201 cases.

cc  -G -o xu2jis0201.c

This example creates a shared object file.

Add this font by adding the following lines to the corresponding sections of mp.conf. The following example shows how to add the TrueType font. The PCF font follows the same pattern except that you change the keyword to PCF instead of TrueType.

FontNameAlias   jis0201R TrueType
FontGroup     jus0201        TrueType  		jis0201R
MapCode2Font		 	0x0020 	0x007f 		jis0201
CnvCode2Font  		jis0201R 		 _ttfjis0201 <.so path>

# this line needs to be deleted from mp.conf before adding.

MapCode2Font    0x0020  0x007f  jis0201 CnvCode2Font
jis0201R  _ttfjis0201 <.so path>
where the .so path points to the file.

Invoking mp(1) with the changed mp.conf file causes the range 0x0020-0x007f to be printed in the new font. Map the other Japanese character ranges too with the same .so file, for example, the range 0x0000FF61 0x0000FF9F.

To maintain backward compatibility, the /usr/openwin/lib/locale/$LANG/print/ file, if it exists, is used to create output in the current locale, where $LANG is one of the locale components. In that situation, no configuration file mechanism is used.

Refer to /usr/lib/lp/locale/en_US.UTF-8/mp/mp.conf, which is a sample mp.conf file.

Customizing Existing prolog Files and Adding New prolog Files

The prolog files can be divided into two main categories:

The customization of PostScript files is discussed first:

Customization of each category of prolog files is discussed next.

Common prolog Files

The common prolog files are:

These files are the print layout prolog files, of which is the common prolog file that is prepended before other prolog files.

The common prolog file,, which resides in the /usr/lib/lp/locale/C/mp/ directory, contains a PostScript routine to re-encode a font from the StandardEncoding to ISOLatin1 Encoding. The .reencodeISO routine is called from the print layout prolog files to change encoding of the fonts. Usually this prolog file does not need any customization. If the users are creating their own prolog files, set the environment variable MP_PROLOGUE to point to the directory that contains the modified prolog files.

Print Layout prolog Files

The print layout prolog files, mp.*.ps files, contain routines for controlling the page layout for printing. In addition to giving a header and a footer for a print page with user name, print date, and page number, these prolog files can provide other information. For example, the prolog files can give effective print area dimensions and landscape and portrait mode of printing to be used.

A set of standard functions needs to be defined in every prolog file. These functions are called when a new print page starts, print page ends, or a new column ends. The implementations of these functions define the print attributes of the printout.

The following PostScript variables are defined at runtime by the mp(1) binary. All the print layout files can use these variables for printing dynamic information such as user name, subject, print time. This information taken from the variables normally appears in the header or footer of the print page.


The name of the user who is running mp, obtained from the system passwd file.


Variable used to hold the name of the type of article to print. The possible values for this variable are:

  • “Listing for” - When the input is a text file

  • “Mail for” - When the input is a mail file

  • “Article from” - When the input is an article from a news group


The subject taken from the mail and news headers. You can use the '-s' option to force a subject to the mail and news files as well as to normal text files.


The time of print that appears in the header and footer. This information is taken from the localtime() function.

Following are the functions implemented in print layout prolog files. All these functions can use subfunctions.


usage : page_number endpage

Called when the bottom of a printed page is reached. This function restores the graphic context of the page and issues a “showpage.” In some prolog files the header and footer information is displayed in only a page-by-page mode rather than in a column-by-column mode. You can implement this function to call subfunctions that display the header and footer gray scale lozenges.


usage : page_number newpage

Routines or commands to be executed when a new page begins. Setting landscape print mode, saving the print graphic context, and translating the page coordinates are some of the functions for routine.


usage : page_number col_number endcol

Display header and footer information. Move to the new print position, and so forth.

For adding new print layout prolog files, you need to define the following variables explicitly within the print layout prolog file.


<number of columns in a print page> 


<width of print area in inches> 


<height of print area in inches> 

Locale-Dependent Prolog File

The locale-dependent prolog file is /usr/openwin/lib/locale/$LANG/print/ and it usually is a PostScript file. This file can contain included Type1 fonts that define PostScript prolog information with some additional PostScript routines. One of the main goals of the prolog file is to set the locale's fonts in an alias for a set of font names that are pre-defined and used in the mp(1).

Support for this file is provided to conform with the file that is used by /usr/bin/mp. If this file exists, then it is given preference and mp.conf file is not scanned for backward compatibility.

The sections about mp.conf file that follow are reprinted from the OpenWindowsTM Localization Guide.

What Is

The purpose of the file is to set up non-generic fonts. Applications use these pre-defined PostScript font names for printing. The prolog file must define at least the following font names for Desk Set Calendar manager and mp.

These fonts need to be able to print the local character set in the following example usage of those fonts:

Example of the File

The localization kit provides a sample for the Japanese environment. Alternatively, this file is found in the /usr/openwin/lib/locale/ja/print/ directory.

How to Add or Change Composite Fonts in an existing File

For example, the following defines a composite font called LC_Base-Font:

(Foo-Fine) makecodeset12 
(Base-Font) makeEUCfont

LC_Base-Font is a composite font of Foo-Fine and a base font called Base-Font. Foo-Fine is a font that contains the local character set. You do not need any in-depth PostScript knowledge to add or change a font.

How to Create a File

The best way is to study the example version. In the example, two routines need to be written, makecodeset12 and makeEUCfont. Makecodeset12 sets up local font encoding information. This routine might differ from locale to locale. MakeEUCfont combines the base font and the locale font to form a composite font. The creator of the prolog file should have good knowledge of PostScript in order to write makecodeset12 and makeEUCfont. file support is kept for backward compatibility only. Do not create a new file for the printing needs of a locale. Use mp.conf instead.

Where Is

The path is:


.xpr File Customization

These files are located, by default, at /usr/lib/lp/locale/C/mp/. A .xpr file corresponds to each PostScript prolog layout file, except for You can define an alternate prolog directory by defining the MP_PROLOGUE environment variable.

These files work as keyword/values pairs. Lines that start with "#" are considered comments. Spaces separate different tokens unless explicitly stated in the following description. Three main sections for each .xpr file are bound by the following keyword pairs:

Certain keyword/value pairs can be used in these three areas. Each area is described next.


All the keyword/value pairs that appear after the STARTCOMMON keyword and before the ENDCOMMON keyword define general properties of the print page. Different valid values for a keyword are separated by using "/".


"0" means the printing occurs in portrait and "1" means in landscape.

PAGELENGTH <unsigned integer>

A value that indicates the number of lines per logical page.

LINELENGTH <unsigned integer>

A value that indicates the number of single column characters per line.

NUMCOLS <unsigned integer>

The number of logical pages per physical page.

HDNGFONTSIZE <unsigned integer>

The heading font point size in decipoints.

BODYFONTSIZE <unsigned integer>

The body font point size in decipoints.

PROLOGDPI <unsigned integer>

The dots-per-inch scale in which the current .xpr file is created.

YTEXTBOUNDARY <unsigned integer>

This y-coordinate establishes the boundary for text printing in a page or logical page (column). This boundary is used as an additional check to see whether text printing is occurring within the expected area. This boundary is needed for Complex Text Layout and EUC printing, as character height information obtained from corresponding fonts can be wrong.

STARTTEXT <unsigned integer> <unsigned integer>

The decipoint x/y points where the actual text printing starts in the first logical page in a physical page.


The 1 indicates that a "Page" string needs to be appended before the page number in the heading.

0 indicates that only the page number is displayed.

EXTRAHDNGFONT "font string 1, font string 2, ... font string n”

The 'font string 1' to 'font string n' are X Logical Font Descriptions. The Token which separates the keyword EXTRAHDNGFONT from the comma separated font name list is '"', not spaces or tabs. These fonts are given preference over the built-in fonts when printing of the heading occurs. Usually, EXTRABODYFONT is used to assign printer-resident fonts that are configured in /usr/openwin/server/etc/XpConfig/C/print/models/<model name>/fonts directory. The fonts.dir contains the XLFD of the printer-resident fonts.

Usually a font is specified like

"-monotype-Gill Sans-Regular-r-normal- -*-%d-*-*-p-0-iso8859-2"

in the .xpr file. "%d", if present, is replaced by the mp(1) to the point size of the current heading fonts in the .xpr file. The x resolution and y resolution are specified "*" and the average width field is set as "0" to indicate selection of scalable font, if possible. You can give more specific font names also.

EXTRABODYFONT “font string 1, font string 2, ... font string n”

This is the same as EXTRAHDNGFONT, except that these fonts are used to print the page body.

XDISPLACEMENT <signed/unsigned int>

Gives the x coordinate displacement to be applied to the page for shifting the contents of the page in the x direction. This displacement can be a +ve or -ve value.

YDISPLACEMENT <signed/unsigned int>

This parameter is the same as x displacement except that the shifting happens in the y direction.

These two keywords are useful when you find that some printers have nonstandard margin widths and you need to shift the printed contents in a page.


The keyword value pairs in this section are bound by STARTPAGE and ENDPAGE keywords. This section contains drawings and heading information that is to be applied for a physical page. A physical page can contain many logical pages, but all the drawing routines that are contained between these keywords are applied only once to a physical page.

The valid drawing entities are LINE and ARC. XDrawLine and XDrawArc functions are executed on values of these keywords.

The dimensions within this section are mapped in PROLOGDPI units. Angles are in degrees.

LINE x1 y1 x2 y2

The /y unsigned coordinates define a pair of points for connecting a line.

ARC x y width height angle1 angle2

x and y are both unsigned integers that represent the arc origin. Width and height are unsigned ints that represent the width and height of the arc.


Unsigned coordinates represent the position in which the user information is printed on the heading.


Unsigned coordinates represent the position in which the time for printing is printed on the heading.


Unsigned coordinates represent the position to print the page string for each printed page.


Unsigned coordinates represent the position to print the subject in the page.


All keywords are the same as the previous STARTPAGE/ENDPAGE section except that the entries in this section are applied to NUMCOLS times to a physical page.

If NUMCOLS is 3, then the printable area of the physical page is divided into three, and lines, arcs, or heading decorations are three times per page.

Creating a New .xpr File

The following are the mp(1) program defaults for different keyword values if these values are not specified in the .xpr file for the STARTCOMMON/ENDCOMMON section.

No default values are needed for the other two sections bound by STARTPAGE/ENDPAGE and STARTCOLUMN/ENDCOLUMN.

When you create a new .xpr prolog file, you need to specify only the values that differ from the default.

To create a page with no decoration, use four logical pages per physical page, in portrait format.

In this situation, you do not need the other two sections:

These parameters are not needed if you are not putting decorations on the printed page. All the coordinates are in 300 dpi default unless you are not specifying the PROLOGDPI keyword. If target printer resolution is different, the .xpr file is scaled to fit into that resolution by the program.

When you create a .xpr file, you must know the paper dimensions beforehand. For U.S. paper, 8.5x11 inches, for a printer of resolution 300 dpi, 2550X3300 are the total dimensions. Most printers cannot print from the top left corner of the paper. Instead, they put some margin around the physical paper. That means that even if you try to print from 0,0 the printing won't be in the top left corner of the page. You need to consider this limitation when you create a new .xpr file.