{
    "mode": "man",
    "parameter": "groff_font",
    "section": "5",
    "url": "https://www.chedong.com/phpMan.php/man/groff_font/5/json",
    "generated": "2026-11-08T04:50:52Z",
    "sections": {
        "Name": {
            "content": "grofffont - GNU roff device and font description files\n",
            "subsections": []
        },
        "Description": {
            "content": "The  groff  font and output device description formats are slight extensions of those used by\nAT&T device-independent troff.  In distinction to the AT&T implementation, groff lacks a  bi‐\nnary  format; all files are text files.  (Plan 9 troff has also abandoned the binary format.)\nThe device and font description files for a device name are stored in  a  devname  directory.\nThe  device  description  file  is called DESC, and, for each font supported by the device, a\nfont description file is called f, where f is usually an abbreviation of a font's name and/or\nstyle.  For example, the ps (PostScript) device has groff font description  files  for  Times\nroman  (TR)  and Zapf Chancery Medium italic (ZCMI), among many others, while the utf8 device\n(for terminal emulators) has only font descriptions for the roman, italic,  bold,  and  bold-\nitalic styles (R, I, B, and BI, respectively).\n\nDevice  and  font  description files are read by the formatter, troff, and by output drivers.\nThe programs typically delegate these files' processing to an internal library, libgroff, en‐\nsuring their consistent interpretation.\n\nDESC file format\nThe DESC file contains a series of directives; each begins a line.  Their order is not impor‐\ntant, with two exceptions: (1) the res directive must precede any  papersize  directive;  and\n(2) the charset directive must come last (if at all).  If a directive name is repeated, later\nentries  in  the  file  override previous ones (except that the paper dimensions are computed\nbased on the res directive last seen when papersize is encountered).  Spaces and/or tabs sep‐\narate words and are ignored at line boundaries.  Comments start with the  “#”  character  and\nextend to the end of a line.  Empty lines are ignored.\n\nfamily fam\nThe default font family is fam.\n\nfonts n F1 ... Fn\nFonts F1, ..., Fn are mounted at font positions m+1, ..., m+n where m is the number of\nstyles  (see  below).  This directive may extend over more than one line.  A font name\nof 0 causes no font to be mounted at the corresponding position.\n\nhor n  The horizontal motion quantum is n basic units.  Horizontal quantities are rounded  to\nmultiples of n.\n\nimagegenerator program\nUse  program  to  generate PNG images from PostScript input.  Under GNU/Linux, this is\nusually gs(1), but under other systems (notably Cygwin) it might  be  set  to  another\nname.  The grohtml(1) driver uses this directive.\n\npaperlength n\nThe  vertical  dimension  of  the  output  medium  is  n  basic units (deprecated: use\npapersize instead).\n\npapersize format-or-dimension-pair-or-file-name ...\nThe dimensions of the output medium are as according to the argument, which is  either\na  standard  paper format, a pair of dimensions, or the name of a plain text file con‐\ntaining either of the foregoing.  Recognized paper formats are the ISO and DIN formats\nA0–A7, B0–B7, C0–C7, and D0–D7; the  U.S.  formats  letter,  legal,  tabloid,  ledger,\nstatement,  and  executive; and the envelope formats com10, monarch, and DL.  Matching\nis performed without regard for lettercase.\n\nAlternatively, the argument can be a custom paper format length,width (with no  spaces\nbefore  or  after  the comma).  Both length and width must have a unit appended; valid\nunits are “i” for inches, “c” for centimeters, “p” for points, and “P” for picas.  Ex‐\nample: “12c,235p”.  An argument that starts with a digit is always treated as a custom\npaper format.\n\nFinally, the argument can be a file name (e.g., /etc/papersize); if the  file  can  be\nopened, the first line is read and a match attempted against each other form.  No com‐\nment syntax is supported.\n\nMore  than  one argument can be specified; each is scanned in turn and the first valid\npaper specification used.\n\npaperwidth n\nThe horizontal dimension of the output  medium  is  n  basic  units  (deprecated:  use\npapersize instead).\n",
            "subsections": [
                {
                    "name": "pass_filenames",
                    "content": "Direct  troff  to  emit the name of the source file being processed.  This is achieved\nwith the intermediate output command “x F”, which grohtml interprets.\n\npostpro program\nUse program as the postprocessor.\n\nprepro program\nUse program as a preprocessor.  The html and xhtml output devices use this directive.\n\nprint program\nUse program as the print spooler.  If omitted, groff's -l and -L options are ignored.\n\nres n  The device resolution is n basic units per inch.\n\nsizes s1 ... sn 0\nThe device has fonts at s1, ..., sn scaled points (see below).  The list of sizes must\nbe terminated by a 0.  Each si can also be a range of sizes m–n.  The list can  extend\nover more than one line.\n\nsizescale n\nA typographical point is subdivided into n scaled points.  The default is 1.\n\nstyles S1 ... Sm\nThe first m font mounting positions are associated with styles S1, ..., Sm.\n"
                },
                {
                    "name": "tcommand",
                    "content": "The postprocessor can handle the t and u intermediate output commands.\n"
                },
                {
                    "name": "unicode",
                    "content": "The  output device supports the complete Unicode repertoire.  This directive is useful\nonly for devices which produce character entities instead of glyphs.\n\nIf unicode is present, no charset section is required in the  font  description  files\nsince the Unicode handling built into groff is used.  However, if there are entries in\na  font  description file's charset section, they either override the default mappings\nfor those particular characters or add new mappings (normally  for  composite  charac‐\nters).\n\nThe utf8, html, and xhtml output devices use this directive.\n\nunitwidth n\nQuantities  in the font description files are in basic units for fonts whose type size\nis n scaled points.\n"
                },
                {
                    "name": "unscaled_charwidths",
                    "content": "Make the font handling module always return unscaled glyph widths.  The grohtml driver\nuses this directive.\n"
                },
                {
                    "name": "use_charnames_in_special",
                    "content": "troff should encode named glyphs inside device control commands.  The  grohtml  driver\nuses this directive.\n\nvert n The vertical motion quantum is n basic units.  Vertical quantities are rounded to mul‐\ntiples of n.\n"
                },
                {
                    "name": "charset",
                    "content": "This directive and the rest of the file are ignored.  It is recognized for compatibil‐\nity  with  other troff implementations.  In GNU troff, character set repertoire is de‐\nscribed on a per-font basis.\n\ntroff recognizes but ignores the directives spare1, spare2, and biggestfont.\n\nThe res, unitwidth, fonts, and sizes lines are mandatory.  Directives not  listed  above  are\nignored  by  troff  but may be used by postprocessors to obtain further information about the\ndevice.\n"
                }
            ]
        },
        "Font description file format": {
            "content": "On typesetting output devices, each font is typically available at multiple sizes.  While pa‐\nper measurements in the device description file are in absolute units, measurements  applica‐\nble  to fonts must be proportional to the type size.  groff achieves this using the precedent\nset by AT&T device-independent troff: one font size is chosen as a norm, and all  others  are\nscaled  linearly  relative  to that basis.  The “unit width” is the number of basic units per\npoint when the font is rendered at this nominal size.\n\nFor instance, groff's lbp device uses a unitwidth of 800.  Its Times roman font (“TR”) has  a\nspacewidth  of  833; this is also the width of its comma, period, centered period, and mathe‐\nmatical asterisk, while its “M” is 2,963 basic units.  Thus, an “M”  on  the  lbp  device  is\n2,963 basic units wide at a notional type size of 800 points.  (800-point type is not practi‐\ncal  for  most purposes, but using it enables the quantities in the font description files to\nbe expressed as integers.)\n\nA font description file has two sections.  The first is a  sequence  of  directives,  and  is\nparsed similarly to the DESC file described above.  Except for the directive names that begin\nthe second section, their ordering is immaterial.  Later directives of the same name override\nearlier  ones,  spaces  and  tabs are handled in the same way, and the same comment syntax is\nsupported.  Empty lines are ignored throughout.\n\nname F The name of the font is F.  “DESC” is an  invalid  font  name.   Simple  integers  are\nvalid,  but  their use is discouraged.  (groff requests and escape sequences interpret\nnon-negative font names as mounting positions instead.  Further, a font named “0” can‐\nnot be automatically mounted by the fonts directive of a DESC file.)\n\nspacewidth n\nThe width of an unadjusted inter-word space is n basic units.\n\nThe directives above must appear in the first section; those below are optional.\n\nslant n\nThe font's glyphs have a slant of n degrees; a positive n slants in the  direction  of\ntext flow.\n\nligatures lig1 ... lign [0]\nGlyphs lig1, ..., lign are ligatures; possible ligatures are ff, fi, fl, ffi, and ffl.\nFor  compatibility with other troff implementations, the list of ligatures may be ter‐\nminated with a 0.  The list of ligatures must not extend over more than one line.\n",
            "subsections": [
                {
                    "name": "special",
                    "content": "The font is special: when a glyph is requested that is  not  present  in  the  current\nfont, it is sought in any mounted fonts that bear this property.\n\nOther  directives  in this section are ignored by troff, but may be used by postprocessors to\nobtain further information about the font.\n\nThe second section contains one or two subsections.  These can appear in  either  order;  the\nfirst  one  encountered commences the second section.  Each starts with a directive on a line\nby itself.  A charset subsection is mandatory unless the associated DESC  file  contains  the\nunicode directive.  Another subsection, kernpairs, is optional.\n\nThe directive charset starts the character set subsection.  (For typesetter devices, this di‐\nrective  is misnamed since it starts a list of glyphs, not characters.)  It precedes a series\nof glyph descriptions, one per line.  Each such glyph description comprises a set  of  fields\nseparated by spaces or tabs and organized as follows.\n\nname metrics type code [entity-name] [-- comment]\n\nname  identifies  the  glyph: if name is a printable character c, it corresponds to the troff\nordinary character c.  If name is a multi-character sequence not beginning with \\, it  corre‐\nsponds  to  the  GNU troff special character escape sequence “\\[name]”.  A name consisting of\nthree minus signs, “---”, indicates that the glyph is unnamed: such glyphs  can  be  accessed\nonly  by  the  \\N escape sequence in troff.  A special character named “---” can still be de‐\nfined using .char and similar requests.  The name “\\-” defines the  minus  sign  glyph.   Fi‐\nnally,  name  can  be  the  horizontal  motion escape sequences, \\| and \\^ (“thin” and “hair”\nspaces, respectively), in which case only the width metric described below is applied; a font\ncan thus customize the widths of these spaces.\n\nThe form of the metrics field is as follows (on one line; it may be broken here for readabil‐\nity).\n\nwidth[,[height[,[depth[,[italic-correction[,[left-italic-correction[,[\nsubscript-correction]]]]]]]]]]\n\nThere must not be any spaces, tabs, or newlines between these subfields, which are  in  basic\nunits  expressed as decimal integers.  Unspecified subfields default to 0.  Since there is no\nassociated binary format, these values are not required to fit into the C language data  type\nchar as they are in AT&T device-independent troff.\n\nThe width subfield gives the width of the glyph.  The height subfield gives the height of the\nglyph  (upwards  is  positive);  if  a glyph does not extend above the baseline, it should be\ngiven a zero height, rather than a negative height.  The depth subfield gives  the  depth  of\nthe  glyph, that is, the distance below the baseline to which the glyph extends (downwards is\npositive); if a glyph does not extend below the baseline, it should be given  a  zero  depth,\nrather than a negative depth.  Italic corrections are relevant to glyphs in italic or oblique\nstyles.   The  italic-correction is the amount of space that should be added after an oblique\nglyph to be followed immediately by an upright  glyph.   The  left-italic-correction  is  the\namount of space that should be added before an oblique glyph to be preceded immediately by an\nupright glyph.  The subscript-correction is the amount of space that should be added after an\noblique glyph to be followed by a subscript; it should be less than the italic correction.\n\nFor  fonts  used with typesetting devices, the type field gives a featural description of the\nglyph: it is a bit mask recording whether the glyph is an ascender, descender, both, or  nei‐\nther.  When a \\w escape sequence is interpolated, these values are bitwise or-ed together for\neach  glyph  and  stored  in the ct register.  In font descriptions for terminal devices, all\nglyphs might have a type of zero, regardless of their appearance.\n\n0      means the glyph lies entirely between the baseline and a horizontal line  at  the  “x-\nheight” of the font, as with “a”, “c”, and “x”;\n\n1      means the glyph descends below the baseline, like “p”;\n\n2      means the glyph ascends above the font's x-height, like “A” or “b”); and\n\n3      means  the  glyph  is  both an ascender and a descender—this is true of parentheses in\nsome fonts.\n\nThe code field gives a numeric identifier that the postprocessor uses to  render  the  glyph.\nThe  glyph can be specified to troff using this code by means of the \\N escape sequence.  The\ncode can be any integer (that is, any integer parsable by the C standard library's  strtol(3)\nfunction).\n\nThe  entity-name  field  defines  an  identifier for the glyph that the postprocessor uses to\nprint the troff glyph name.  This field is optional; it was introduced so  that  the  grohtml\noutput driver could encode its character set.  For example, the glyph \\[Po] is represented by\n“£”  in  HTML  4.0.  For efficiency, these data are now compiled directly into grohtml.\ngrops uses the field to build sub-encoding arrays for PostScript fonts containing  more  than\n256 glyphs.  Anything on the line after the entity-name field or “--” is ignored.\n\nA line in the charset section can also have the form\nname \"\nidentifying name as another name for the glyph mentioned in the preceding line.  Such aliases\ncan be chained.\n\nThe  directive  kernpairs  starts  a list of kerning adjustments to be made to adjacent glyph\npairs from this font.  It contains a sequence of lines formatted as follows.\ng1 g2 n\nThe foregoing means that when glyph g1 is typeset immediately before g2,  the  space  between\nthem should be increased by n.  Most kerning pairs should have a negative value for n.\n"
                }
            ]
        },
        "Files": {
            "content": "/usr/share/groff/1.23.0/font/devname/DESC\ndescribes the output device name.\n\n/usr/share/groff/1.23.0/font/devname/F\ndescribes the font known as F on device name.\n\nSee also\nGroff: The GNU Implementation of troff, by Trent A. Fisher and Werner Lemberg, is the primary\ngroff manual.  You can browse it interactively with “info groff”.\n\n“Troff  User's Manual” by Joseph F. Ossanna, 1976 (revised by Brian W. Kernighan, 1992), AT&T\nBell Laboratories Computing Science Technical Report No. 54, widely called simply “CSTR #54”,\ndocuments the language, device and font description file formats, and device-independent out‐\nput format referred to collectively in groff documentation as “AT&T troff”.\n\n“A Typesetter-independent TROFF” by Brian W. Kernighan, 1982, AT&T Bell Laboratories  Comput‐\ning  Science  Technical  Report No. 97, provides additional insights into the device and font\ndescription file formats and device-independent output format.\n\ngroff(1), subsection “Utilities”, lists programs available for describing fonts in a  variety\nof formats such that groff output drivers can use them.\n\ntroff(1) documents the default device and font description file search path.\n\ngroffout(5), addftinfo(1)\n\ngroff 1.23.0                                31 March 2024                              grofffont(5)",
            "subsections": []
        }
    },
    "flags": [],
    "examples": [],
    "see_also": []
}