newRPL fully supports font customization: each part of the display interface uses its own font, as well as selected environments such as the command line or the forms engine.

Since text support in newRPL is based on Unicode 10.0, fonts support up to 65536 different glyphs and represent up to 1048576 different code points. Fonts can be any size and be fixed-width or proportional.

A font object is represented on the stack as FONTDATA xx yyy…, where yyy… is a string of characters (A-Z, a-z, $ and #) encoding the glyphs and the translation table that associates glyphs to Unicode code points while xx is the length (padded to a multiple of 4 bytes) of the aforementioned block, expressed in nibbles.

To install a font on the system it must be stored into a variable, whose name will become the name of the font. The command FNTSTO is used to finalize the installation of the font. A font object can be recalled by the FNTRCL command and uninstalled by the FNTPG command.

newRPL already provides 11 system fonts which are always available and can't be uninstalled. Smaller sizes are suited for soft keys, while larger sizes are preferable for stack display; however nothing prevents using large sizes for soft keys and small sizes for stack display.

These are the independent areas and environments that can be customized with fonts:

• Stack (1^st level): this area usually contains the expression currently input or the last result computed. Given its relevance, it can be emphasized with a different font from the rest of the stack;
• Stack (other levels): a smaller font can be used to maximize the amount of data displayed in the other levels of the stack;
• Command line: this is the area where instructions are currently typed before being interpreted by newRPL;
• Menus: usually small fonts are used here, however some users might prefer a larger font. it's not possible to choose different fonts for Menu 1 and 2;
• Status Area: same as above. A larger font provides readability at the cost of less space for stack display;
• Plot objects: to maximize real estate for plots a very small font might be preferable;
• Forms: another environment where the ratio between readability and amount of information displayed can be tailored to the user's preferences.

To build a custom font is not difficult at all, but before proceeding with the explanations it is necessary to introduce some notions.

First of all, a font is defined as a collection of glyphs. The glyphs are the shapes that are actually drawn on the display when the calculator receives the request to print a character and can be imagined as a rectangular grid of pixels where some of them are lit and others aren't.

The height (in pixels) of this grid is called the size of the font, and it's the same for all the glyphs; the width, on the contrary may vary, or not. If the width of the grid is always the same the font is termed fixed-width otherwise is proportional.

The size of the font must take into account the possibility that some characters are taller than others (e.g. l versus n), that some have descenders while others haven't (p versus o) and that when multiple lines of text are written to the screen there should be a little separation between the rows to make the text readable.

The logical conclusion is that if the font is planned to be e.g. 10 pixel high, the actual room to draw the glyphs is reduced to the top 8 or 9 rows of the grid, with the bottom lines of pixels empty to either provide the space between the lines of text or the room to draw a descender.

Restrictions on thw width of a glyph are less severe because, as said before, it's not compulsory that all the glyphs share the same width: in fact, the width of a glyph ranges from 1 to 15 pixels; it's common practice to keep the last column of a glyph empty in order to prevent the characters from blending into each other.

The last concept to introduce is that of the translation table. A font can store up to 65536 glyphs (provided that the total width of the glyphs doesn't exceed 4095 pixels) but an Unicode character block can store up to 1048576 code points. The translation table realizes the connection between code points (which identify unequivocally a character) and glyphs (which determine their graphical appearance).

For example, a large part of the 1048576 code points will be unused, therefore all these code points can be mapped to a single glyph (e.g. a little square shape or similar symbol), providing a powerful way to reduce the memory footprint of the unused codes.

A more practical example arises from the consideration that many scripts share many glyphs: for example the capital latin b (code point U+0042), greek beta (code point U+0392) and cyrillic ve (code point U+0412) letters are represented by the glyph B.

In conclusion, to build a custom font three tools are needed:

1. a graphic editor capable of saving images in .bmp format to draw the glyphs;
2. a text editor to write the translation table;
3. the bmp2font tool to create the font object. The source code is available in newrpl/tools/fonts/bmp2font/ while the instructions to compile it are here.

Examination of the source bitmap of an existing font (e.g. Font10_StyleA.bmp shows that the structure of the bitmap file is very simple: each glyph is juxtaposed to the previous.

A closer examination of the file reveals that the bitmap is actually 11 pixel high rather than 10. The extra bottom row of pixels is used to encode the width of each glyph: under the first glyph there are five black pixels, therefore the width of that glyph is 5 pixels; under the second glyph there are five white pixels thus its width is 5 pixels again, and so on until the end of the bitmap.