diff --git a/doc/html/man/term.5.html b/doc/html/man/term.5.html
index 221db40..9c9b5b8 100644
--- a/doc/html/man/term.5.html
+++ b/doc/html/man/term.5.html
@@ -1,6 +1,8 @@
-<!-- 
+<!--
+  * t
   ****************************************************************************
-  * Copyright (c) 1998-2010,2015 Free Software Foundation, Inc.              *
+  * Copyright 2018-2023,2024 Thomas E. Dickey                                *
+  * Copyright 1998-2016,2017 Free Software Foundation, Inc.                  *
   *                                                                          *
   * Permission is hereby granted, free of charge, to any person obtaining a  *
   * copy of this software and associated documentation files (the            *
@@ -26,231 +28,338 @@
   * sale, use or other dealings in this Software without prior written       *
   * authorization.                                                           *
   ****************************************************************************
-  * @Id: term.5,v 1.22 2015/04/26 14:50:23 tom Exp @
+  * @Id: term.5,v 1.77 2024/04/20 21:24:19 tom Exp @
 -->
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
 <HTML>
 <HEAD>
 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
-<meta name="generator" content="Manpage converted by man2html - see http://invisible-island.net/scripts/readme.html#others_scripts">
-<TITLE>term 5</TITLE>
-<link rev=made href="mailto:bug-ncurses@gnu.org">
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<meta name="generator" content="Manpage converted by man2html - see https://invisible-island.net/scripts/readme.html#others_scripts">
+<TITLE>term 5 2024-04-20 ncurses 6.5 File formats</TITLE>
+<link rel="author" href="mailto:bug-ncurses@gnu.org">
+
 </HEAD>
 <BODY>
-<H1 class="no-header">term 5</H1>
+<H1 class="no-header">term 5 2024-04-20 ncurses 6.5 File formats</H1>
 <PRE>
-<STRONG><A HREF="term.5.html">term(5)</A></STRONG>                                                         <STRONG><A HREF="term.5.html">term(5)</A></STRONG>
+<STRONG><A HREF="term.5.html">term(5)</A></STRONG>                          File formats                          <STRONG><A HREF="term.5.html">term(5)</A></STRONG>
 
 
 
 
-</PRE>
-<H2><a name="h2-NAME">NAME</a></H2><PRE>
-       term - format of compiled term file.
+</PRE><H2><a name="h2-NAME">NAME</a></H2><PRE>
+       term - compiled <EM>terminfo</EM> terminal description
 
 
-</PRE>
-<H2><a name="h2-SYNOPSIS">SYNOPSIS</a></H2><PRE>
+</PRE><H2><a name="h2-SYNOPSIS">SYNOPSIS</a></H2><PRE>
        <STRONG>term</STRONG>
 
 
-</PRE>
-<H2><a name="h2-DESCRIPTION">DESCRIPTION</a></H2><PRE>
+</PRE><H2><a name="h2-DESCRIPTION">DESCRIPTION</a></H2><PRE>
 
-</PRE>
-<H3><a name="h3-STORAGE-LOCATION">STORAGE LOCATION</a></H3><PRE>
-       Compiled terminfo descriptions are placed under the direc-
-       tory <STRONG>/usr/share/terminfo</STRONG>.   Two  configurations  are  sup-
-       ported (when building the ncurses libraries):
+</PRE><H3><a name="h3-Storage-Location">Storage Location</a></H3><PRE>
+       Compiled   terminfo   descriptions   are  placed  under  the  directory
+       <STRONG>/usr/share/terminfo</STRONG>.  Two configurations are supported  (when  building
+       the <EM>ncurses</EM> libraries):
 
        <STRONG>directory</STRONG> <STRONG>tree</STRONG>
-            A  two-level  scheme is used to avoid a linear search
-            of a  huge  UNIX  system  directory:  <STRONG>/usr/share/ter-</STRONG>
-            <STRONG>minfo/c/name</STRONG>  where <EM>name</EM> is the name of the terminal,
-            and <EM>c</EM> is the first character of <EM>name</EM>.  Thus, <EM>act4</EM> can
-            be  found  in  the  file  <STRONG>/usr/share/terminfo/a/act4</STRONG>.
-            Synonyms for the same  terminal  are  implemented  by
-            multiple links to the same compiled file.
+            A two-level scheme is used to avoid a linear search of a huge Unix
+            system directory: <STRONG>/usr/share/terminfo/c/name</STRONG>  where  <EM>name</EM>  is  the
+            name of the terminal, and <EM>c</EM> is the first character of <EM>name</EM>.  Thus,
+            <EM>act4</EM>  can  be  found  in  the   file   <STRONG>/usr/share/terminfo/a/act4</STRONG>.
+            Synonyms  for  the same terminal are implemented by multiple links
+            to the same compiled file.
 
        <STRONG>hashed</STRONG> <STRONG>database</STRONG>
-            Using  Berkeley  database,  two  types of records are
-            stored: the terminfo  data  in  the  same  format  as
-            stored  in  a directory tree with the terminfo's pri-
-            mary name as  a  key,  and  records  containing  only
-            aliases pointing to the primary name.
+            Using Berkeley database, two types  of  records  are  stored:  the
+            terminfo  data  in  the  same format as stored in a directory tree
+            with the terminfo's primary name as a key, and records  containing
+            only aliases pointing to the primary name.
 
-            If built to write hashed databases, ncurses can still
-            read terminfo  databases  organized  as  a  directory
-            tree,  but  cannot  write  entries into the directory
-            tree.  It can  write  (or  rewrite)  entries  in  the
-            hashed database.
+            If  built  to  write  hashed  databases,  <EM>ncurses</EM>  can  still read
+            terminfo databases organized as a directory tree, but cannot write
+            entries  into  the  directory  tree.   It  can  write (or rewrite)
+            entries in the hashed database.
 
-            ncurses  distinguishes  the two cases in the TERMINFO
-            and TERMINFO_DIRS environment variable by assuming  a
-            directory  tree  for  entries  that  correspond to an
-            existing directory, and hashed database otherwise.
+            <EM>ncurses</EM>  distinguishes  the  two  cases  in   the   <EM>TERMINFO</EM>   and
+            <EM>TERMINFO</EM><STRONG>_</STRONG><EM>DIRS</EM>  environment  variable  by assuming a directory tree
+            for entries that correspond to an existing directory,  and  hashed
+            database otherwise.
 
 
-</PRE>
-<H3><a name="h3-STORAGE-FORMAT">STORAGE FORMAT</a></H3><PRE>
-       The format has been chosen so that it will be the same  on
-       all  hardware.   An  8 or more bit byte is assumed, but no
-       assumptions about byte  ordering  or  sign  extension  are
-       made.
+</PRE><H3><a name="h3-Legacy-Storage-Format">Legacy Storage Format</a></H3><PRE>
+       The format has been chosen so that it will be the same on all hardware.
+       An 8 or more bit  byte  is  assumed,  but  no  assumptions  about  byte
+       ordering or sign extension are made.
 
-       The  compiled  file  is  created with the <STRONG>tic</STRONG> program, and
-       read by the routine <EM>setupterm</EM>.  The file is  divided  into
-       six parts: the header, terminal names, boolean flags, num-
-       bers, strings, and string table.
+       The  compiled  file  is  created  with the <STRONG>tic</STRONG> program, and read by the
+       routine <STRONG><A HREF="curs_terminfo.3x.html">setupterm(3x)</A></STRONG>.  The file is divided into six parts:
 
-       The header section begins the file.  This section contains
-       six  short  integers in the format described below.  These
-       integers are
+            a) <EM>header</EM>,
 
-            (1) the magic number (octal 0432);
+            b) <EM>terminal</EM> <EM>names</EM>,
 
-            (2) the size, in bytes, of the names section;
+            c) <EM>Boolean</EM> <EM>flags</EM>,
 
-            (3) the number of bytes in the boolean section;
+            d) <EM>numbers</EM>,
 
-            (4) the number of short integers in the numbers  sec-
-            tion;
+            e) <EM>strings</EM>, and
 
-            (5)  the  number  of  offsets (short integers) in the
-            strings section;
+            f) <EM>string</EM> <EM>table</EM>.
 
-            (6) the size, in bytes, of the string table.
+       The <EM>header</EM> section begins the file.  This section  contains  six  short
+       integers in the format described below.  These integers are
 
-       Short integers are stored in two 8-bit bytes.   The  first
-       byte  contains  the least significant 8 bits of the value,
-       and the second byte contains the most significant 8  bits.
-       (Thus,  the  value  represented is 256*second+first.)  The
-       value -1 is represented by the two bytes 0377, 0377; other
-       negative  values  are  illegal. This value generally means
-       that the corresponding capability  is  missing  from  this
-       terminal.   Note that this format corresponds to the hard-
-       ware  of  the  VAX  and  PDP-11  (that  is,  little-endian
-       machines).  Machines where this does not correspond to the
-       hardware must read the integers as two bytes  and  compute
-       the little-endian value.
+            (1) the <EM>magic</EM> <EM>number</EM> (octal 0432);
 
-       The  terminal  names  section comes next.  It contains the
-       first line of the terminfo description, listing the  vari-
-       ous  names  for the terminal, separated by the `|' charac-
-       ter.  The section is terminated with an ASCII NUL  charac-
-       ter.
+            (2) the size, in bytes, of the <EM>terminal</EM> <EM>names</EM> section;
 
-       The  boolean flags have one byte for each flag.  This byte
-       is either 0 or 1 as the flag is present  or  absent.   The
-       capabilities are in the same order as the file &lt;term.h&gt;.
+            (3) the number of bytes in the <EM>Boolean</EM> <EM>flags</EM> section;
 
-       Between the boolean section and the number section, a null
-       byte will be inserted, if necessary, to  ensure  that  the
-       number  section begins on an even byte (this is a relic of
-       the  PDP-11's  word-addressed   architecture,   originally
-       designed  in  to  avoid  IOT traps induced by addressing a
-       word on an odd byte boundary).   All  short  integers  are
-       aligned on a short word boundary.
+            (4) the number of short integers in the <EM>numbers</EM> section;
 
-       The numbers section is similar to the flags section.  Each
-       capability takes up two bytes, and is stored as a  little-
-       endian short integer.  If the value represented is -1, the
-       capability is taken to be missing.
+            (5) the number of offsets (short integers) in the <EM>strings</EM> section;
 
-       The strings section is also similar.  Each  capability  is
-       stored  as  a short integer, in the format above.  A value
-       of -1 means the capability  is  missing.   Otherwise,  the
-       value  is  taken  as  an  offset from the beginning of the
-       string table.  Special characters in ^X or \c notation are
-       stored  in their interpreted form, not the printing repre-
-       sentation.  Padding information $&lt;nn&gt; and parameter infor-
-       mation %x are stored intact in uninterpreted form.
+            (6) the size, in bytes, of the <EM>string</EM> <EM>table</EM>.
 
-       The  final  section  is the string table.  It contains all
-       the values of string capabilities referenced in the string
-       section.  Each string is null terminated.
+       The  capabilities  in  the <EM>Boolean</EM> <EM>flags</EM>, <EM>numbers</EM>, and <EM>strings</EM> sections
+       are in the same order as the file &lt;term.h&gt;.
+
+       Short integers are signed, in the range  -32768  to  32767.   They  are
+       stored  as  two  8-bit  bytes.   The  first  byte  contains  the  least
+       significant 8 bits of the value, and the second byte contains the  most
+       significant 8 bits.  (Thus, the value represented is 256*second+first.)
+       This format corresponds to the hardware of the VAX and PDP-11 (that is,
+       little-endian  machines).   Machines  where this does not correspond to
+       the hardware must read the  integers  as  two  bytes  and  compute  the
+       little-endian value.
+
+       Numbers  in  a  terminal  description,  whether they are entries in the
+       <EM>numbers</EM> or <EM>strings</EM> table, are positive  integers.   Boolean  flags  are
+       treated  as  positive  one-byte integers.  In each case, those positive
+       integers represent a terminal capability.  The  terminal  compiler  tic
+       uses  negative  integers  to handle the cases where a capability is not
+       available:
+
+       <STRONG>o</STRONG>   If a capability is absent from this terminal, tic stores  a  -1  in
+           the corresponding table.
+
+           The integer value -1 is represented by two bytes 0377, 0377.
+           Absent Boolean values are represented by the byte 0 (false).
+
+       <STRONG>o</STRONG>   If  a capability has been canceled from this terminal, tic stores a
+           -2 in the corresponding table.
+
+           The integer value -2 is represented by two bytes 0377, 0376.
+           The Boolean value -2 is represented by the byte 0376.
+
+       <STRONG>o</STRONG>   Other negative values are illegal.
+
+       The <EM>terminal</EM> <EM>names</EM> section comes after the  <EM>header</EM>.   It  contains  the
+       first  line  of the terminfo description, listing the various names for
+       the terminal, separated by  the  "|"  character.   The  <EM>terminal</EM>  <EM>names</EM>
+       section is terminated with an ASCII NUL character.
+
+       The  <EM>Boolean</EM>  <EM>flags</EM>  section  has  one  byte  for  each  flag.  Boolean
+       capabilities are either 1 or 0 (true or false) according to whether the
+       terminal supports the given capability or not.
+
+       Between  the  <EM>Boolean</EM> <EM>flags</EM> section and the <EM>number</EM> section, a null byte
+       will be inserted, if necessary,  to  ensure  that  the  <EM>number</EM>  section
+       begins  on  an even byte This is a relic of the PDP-11's word-addressed
+       architecture, originally designed to avoid traps induced by  addressing
+       a  word  on  an odd byte boundary.  All short integers are aligned on a
+       short word boundary.
+
+       The <EM>numbers</EM> section is similar to  the  <EM>Boolean</EM>  <EM>flags</EM>  section.   Each
+       capability  takes  up two bytes, and is stored as a little-endian short
+       integer.
+
+       The <EM>strings</EM> section is also similar.  Each capability is  stored  as  a
+       short integer.  The capability value is an index into the <EM>string</EM> <EM>table</EM>.
+
+       The <EM>string</EM> <EM>table</EM> is the last section.  It contains all of the values of
+       string capabilities referenced in the <EM>strings</EM> section.  Each string  is
+       null-terminated.  Special characters in ^X or \c notation are stored in
+       their interpreted  form,  not  the  printing  representation.   Padding
+       information  $&lt;nn&gt;  and  parameter  information %x are stored intact in
+       uninterpreted form.
 
 
-</PRE>
-<H3><a name="h3-EXTENDED-STORAGE-FORMAT">EXTENDED STORAGE FORMAT</a></H3><PRE>
-       The  previous  section describes the conventional terminfo
-       binary format.  With some minor variations of the  offsets
-       (see  PORTABILITY),  the same binary format is used in all
-       modern UNIX systems.  Each system uses a predefined set of
-       boolean, number or string capabilities.
+</PRE><H3><a name="h3-Extended-Storage-Format">Extended Storage Format</a></H3><PRE>
+       The previous section describes the conventional terminfo binary format.
+       With  some  minor variations of the offsets (see PORTABILITY), the same
+       binary format is used in all modern Unix systems.  Each system  uses  a
+       predefined set of Boolean, number or string capabilities.
 
-       The  ncurses  libraries  and applications support extended
-       terminfo binary format, allowing users to define capabili-
-       ties  which are loaded at runtime.  This extension is made
-       possible by using the fact that the other  implementations
-       stop  reading the terminfo data when they have reached the
-       end of the size given in the header.  ncurses  checks  the
-       size,  and  if it exceeds that due to the predefined data,
-       continues to parse according to its own scheme.
+       The <EM>ncurses</EM> libraries and applications support extended terminfo binary
+       format, allowing users to  define  capabilities  which  are  loaded  at
+       runtime.   This  extension  is made possible by using the fact that the
+       other implementations stop reading the terminfo  data  when  they  have
+       reached  the  end  of the size given in the header.  <EM>ncurses</EM> checks the
+       size, and if it exceeds that due to the predefined data,  continues  to
+       parse according to its own scheme.
 
        First, it reads the extended header (5 short integers):
 
-            (1)  count of extended boolean capabilities
+            (1)  count of extended Boolean capabilities
 
             (2)  count of extended numeric capabilities
 
             (3)  count of extended string capabilities
 
-            (4)  size of the extended string table in bytes.
+            (4)  count of the items in extended string table
 
-            (5)  last offset of  the  extended  string  table  in
-                 bytes.
+            (5)  size of the extended string table in bytes
 
-       Using  the  counts and sizes, ncurses allocates arrays and
-       reads data for the extended capabilities in the same order
-       as the header information.
+       The  count-  and  size-values for the extended string table include the
+       extended capability <EM>names</EM> as well as extended capability <EM>values</EM>.
 
-       The extended string table contains values for string capa-
-       bilities.  After the end of these values, it contains  the
-       names  for  each  of  the  extended capabilities in order,
-       e.g., booleans, then numbers and finally strings.
+       Using the counts and sizes, <EM>ncurses</EM> allocates arrays and reads data for
+       the extended capabilities in the same order as the header information.
+
+       The  extended  string  table  contains  values for string capabilities.
+       After the end of these values, it contains the names for  each  of  the
+       extended  capabilities  in  order,  e.g.,  Booleans,  then  numbers and
+       finally strings.
+
+       By storing terminal descriptions  in  this  way,  <EM>ncurses</EM>  is  able  to
+       provide  a  database  useful  with  legacy  applications,  as  well  as
+       providing data for applications which need  more  than  the  predefined
+       capabilities.  See <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG> for an overview of the way <EM>ncurses</EM> uses
+       this extended information.
+
+       Applications which manipulate terminal data  can  use  the  definitions
+       described  in  <STRONG><A HREF="term_variables.3x.html">term_variables(3x)</A></STRONG>  which  associate the long capability
+       names with members of a <STRONG>TERMTYPE</STRONG> structure.
 
 
-</PRE>
-<H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE>
-       Note that it is possible for <EM>setupterm</EM> to expect a differ-
-       ent  set  of capabilities than are actually present in the
-       file.  Either the database may  have  been  updated  since
-       <EM>setupterm</EM> has been recompiled (resulting in extra unrecog-
-       nized entries in the file) or the program  may  have  been
-       recompiled  more  recently  than  the database was updated
-       (resulting in missing  entries).   The  routine  <EM>setupterm</EM>
-       must  be prepared for both possibilities - this is why the
-       numbers and sizes are included.   Also,  new  capabilities
-       must  always  be added at the end of the lists of boolean,
-       number, and string capabilities.
+</PRE><H3><a name="h3-Extended-Number-Format">Extended Number Format</a></H3><PRE>
+       On occasion, 16-bit signed integers are not large enough.  With <EM>ncurses</EM>
+       6.1,  a new format was introduced by making a few changes to the legacy
+       format:
 
-       Despite the consistent use of  little-endian  for  numbers
-       and  the  otherwise self-describing format, it is not wise
-       to count on portability of binary terminfo entries between
-       commercial  UNIX  versions.  The problem is that there are
-       at least three versions of terminfo (under HP-UX, AIX, and
-       OSF/1)  which  diverged from System V terminfo after SVr1,
-       and have added extension capabilities to the string  table
-       that  (in the binary format) collide with System V and XSI
-       Curses extensions.  See <STRONG><A HREF="terminfo.5.html">terminfo(5)</A></STRONG> for  detailed  discus-
-       sion of terminfo source compatibility issues.
+       <STRONG>o</STRONG>   a different magic number (octal 01036)
+
+       <STRONG>o</STRONG>   changing the type for the <EM>number</EM> array from signed 16-bit  integers
+           to signed 32-bit integers.
+
+       To   maintain   compatibility,  the  library  presents  the  same  data
+       structures to direct users of the <STRONG>TERMTYPE</STRONG>  structure  as  in  previous
+       formats.   However,  that  cannot  provide  callers  with  the extended
+       numbers.   The  library  uses  a  similar  but  hidden  data  structure
+       <STRONG>TERMTYPE2</STRONG> to provide data for the terminfo functions.
 
 
-</PRE>
-<H2><a name="h2-EXAMPLE">EXAMPLE</a></H2><PRE>
-       As  an  example, here is a hex dump of the description for
-       the Lear-Siegler ADM-3, a  popular  though  rather  stupid
-       early terminal:
+</PRE><H2><a name="h2-FILES">FILES</a></H2><PRE>
+       <EM>/usr/share/terminfo</EM>
+              compiled terminal description database
+
+
+</PRE><H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE>
+
+</PRE><H3><a name="h3-setupterm">setupterm</a></H3><PRE>
+       Note  that  it  is  possible for <STRONG>setupterm</STRONG> to expect a different set of
+       capabilities than  are  actually  present  in  the  file.   Either  the
+       database   may   have  been  updated  since  <STRONG>setupterm</STRONG>  was  recompiled
+       (resulting in extra unrecognized entries in the file)  or  the  program
+       may  have  been  recompiled more recently than the database was updated
+       (resulting in missing entries).  The routine <STRONG>setupterm</STRONG> must be prepared
+       for  both  possibilities  -  this  is  why  the  numbers  and sizes are
+       included.  Also, new capabilities must always be added at  the  end  of
+       the lists of Boolean, number, and string capabilities.
+
+
+</PRE><H3><a name="h3-Binary-Format">Binary Format</a></H3><PRE>
+       X/Open  Curses  does  not  specify  a format for the terminfo database.
+       System V curses used a directory-tree of binary files, one per terminal
+       description.
+
+       Despite  the  consistent  use  of  little-endian  for  numbers  and the
+       otherwise  self-describing  format,  it  is  not  wise  to   count   on
+       portability   of   binary  terminfo  entries  between  commercial  Unix
+       versions.  The problem is that there are at  least  three  versions  of
+       terminfo  (under  HP-UX,  AIX,  and OSF/1) which diverged from System V
+       terminfo after SVr1, and  have  added  extension  capabilities  to  the
+       string  table  that  (in  the  binary format) collide with System V and
+       X/Open Curses extensions.  See <STRONG><A HREF="terminfo.5.html">terminfo(5)</A></STRONG> for detailed  discussion  of
+       terminfo source compatibility issues.
+
+       This  implementation  is by default compatible with the binary terminfo
+       format used by Solaris curses, except in a few less-used details  where
+       it  was  found that the latter did not match X/Open Curses.  The format
+       used by the other Unix versions can be matched by building <EM>ncurses</EM> with
+       different configuration options.
+
+
+</PRE><H3><a name="h3-Magic-Codes">Magic Codes</a></H3><PRE>
+       The  magic  number  in a binary terminfo file is the first 16-bits (two
+       bytes).  Besides making it more reliable for the library to check  that
+       a  file  is  terminfo,  utilities such as <STRONG>file(1)</STRONG> also use that to tell
+       what the file-format is.  System V defined more than one magic  number,
+       with 0433, 0435 as screen-dumps (see <STRONG><A HREF="scr_dump.5.html">scr_dump(5)</A></STRONG>).  This implementation
+       uses 01036 as a continuation of that sequence,  but  with  a  different
+       high-order byte to avoid confusion.
+
+   <STRONG>The</STRONG> <EM>TERMTYPE</EM> <STRONG>Structure</STRONG>
+       Direct  access  to  the  <STRONG>TERMTYPE</STRONG>  structure  is  provided  for  legacy
+       applications.  Portable  applications  should  use  the  <STRONG>tigetflag</STRONG>  and
+       related  functions  described in <STRONG><A HREF="curs_terminfo.3x.html">curs_terminfo(3x)</A></STRONG> for reading terminal
+       capabilities.
+
+
+</PRE><H3><a name="h3-Mixed-case-Terminal-Names">Mixed-case Terminal Names</a></H3><PRE>
+       A small number of terminal descriptions  use  uppercase  characters  in
+       their  names.   If  the  underlying  filesystem  ignores the difference
+       between  uppercase  and  lowercase,  <EM>ncurses</EM>  represents   the   "first
+       character"  of  the  terminal  name used as the intermediate level of a
+       directory tree in (two-character) hexadecimal form.
+
+
+</PRE><H3><a name="h3-Limits">Limits</a></H3><PRE>
+       <EM>ncurses</EM> stores compiled terminal descriptions in three related formats,
+       described in the sections
+
+       <STRONG>o</STRONG>   <STRONG>LEGACY</STRONG> <STRONG>STORAGE</STRONG> <STRONG>FORMAT</STRONG>, and
+
+       <STRONG>o</STRONG>   <STRONG>EXTENDED</STRONG> <STRONG>STORAGE</STRONG> <STRONG>FORMAT</STRONG>, and
+
+       <STRONG>o</STRONG>   <STRONG>EXTENDED</STRONG> <STRONG>NUMBER</STRONG> <STRONG>FORMAT</STRONG>.
+
+       The  legacy storage format and the extended number format differ by the
+       types of numeric capability which they can store (i.e.,  16-bit  versus
+       32-bit  integers).   The  extended storage format introduced by <EM>ncurses</EM>
+       5.0 adds data to either of these formats.
+
+       Some limitations apply:
+
+       <STRONG>o</STRONG>   total compiled entries cannot  exceed  4096  bytes  in  the  legacy
+           format.
+
+       <STRONG>o</STRONG>   total  compiled  entries  cannot exceed 32768 bytes in the extended
+           format.
+
+       <STRONG>o</STRONG>   the name field cannot exceed 128 bytes.
+
+       Compiled entries are limited to 32768 bytes because  offsets  into  the
+       <EM>strings</EM>  <EM>table</EM>  use  two-byte  integers.   The legacy format could have
+       supported 32768-byte entries, but  was  limited  to  a  virtual  memory
+       page's 4096 bytes.
+
+
+</PRE><H2><a name="h2-EXAMPLES">EXAMPLES</a></H2><PRE>
+       As  an  example,  here  is  a description for the Lear-Siegler ADM-3, a
+       popular though rather stupid early terminal:
 
        adm3a|lsi adm3a,
                am,
                cols#80, lines#24,
-               bel=^G, clear= 32$&lt;1&gt;, cr=^M, cub1=^H, cud1=^J,
+               bel=^G, clear=\032$&lt;1&gt;, cr=^M, cub1=^H, cud1=^J,
                cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
                home=^^, ind=^J,
 
+       and a hexadecimal dump of the compiled terminal description:
+
        0000  1a 01 10 00 02 00 03 00  82 00 31 00 61 64 6d 33  ........ ..1.adm3
        0010  61 7c 6c 73 69 20 61 64  6d 33 61 00 00 01 50 00  a|lsi ad m3a...P.
        0020  ff ff 18 00 ff ff 00 00  02 00 ff ff ff ff 04 00  ........ ........
@@ -275,35 +384,22 @@
        0150  00 08 00 0c 00 0b 00 0a  00                       ........ .
 
 
-
-</PRE>
-<H2><a name="h2-LIMITS">LIMITS</a></H2><PRE>
-       Some  limitations:  total  compiled  entries cannot exceed
-       4096 bytes.  The name field cannot exceed 128 bytes.
-
-
-</PRE>
-<H2><a name="h2-FILES">FILES</a></H2><PRE>
-       /usr/share/terminfo/*/*  compiled terminal capability data
-       base
-
-
-</PRE>
-<H2><a name="h2-SEE-ALSO">SEE ALSO</a></H2><PRE>
-       <STRONG><A HREF="ncurses.3x.html">curses(3x)</A></STRONG>, <STRONG><A HREF="terminfo.5.html">terminfo(5)</A></STRONG>.
-
-
-</PRE>
-<H2><a name="h2-AUTHORS">AUTHORS</a></H2><PRE>
+</PRE><H2><a name="h2-AUTHORS">AUTHORS</a></H2><PRE>
        Thomas E. Dickey
-       extended terminfo format for ncurses 5.0
-       hashed database support for ncurses 5.6
+       extended terminfo format for <EM>ncurses</EM> 5.0
+       hashed database support for <EM>ncurses</EM> 5.6
+       extended number support for <EM>ncurses</EM> 6.1
 
        Eric S. Raymond
+       documented legacy terminfo format, e.g., from <EM>pcurses</EM>.
+
+
+</PRE><H2><a name="h2-SEE-ALSO">SEE ALSO</a></H2><PRE>
+       <STRONG><A HREF="ncurses.3x.html">curses(3x)</A></STRONG>, <STRONG><A HREF="curs_terminfo.3x.html">curs_terminfo(3x)</A></STRONG>, <STRONG><A HREF="terminfo.5.html">terminfo(5)</A></STRONG>, <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG>
 
 
 
-                                                                <STRONG><A HREF="term.5.html">term(5)</A></STRONG>
+ncurses 6.5                       2024-04-20                           <STRONG><A HREF="term.5.html">term(5)</A></STRONG>
 </PRE>
 <div class="nav">
 <ul>
@@ -311,17 +407,25 @@
 <li><a href="#h2-SYNOPSIS">SYNOPSIS</a></li>
 <li><a href="#h2-DESCRIPTION">DESCRIPTION</a>
 <ul>
-<li><a href="#h3-STORAGE-LOCATION">STORAGE LOCATION</a></li>
-<li><a href="#h3-STORAGE-FORMAT">STORAGE FORMAT</a></li>
-<li><a href="#h3-EXTENDED-STORAGE-FORMAT">EXTENDED STORAGE FORMAT</a></li>
+<li><a href="#h3-Storage-Location">Storage Location</a></li>
+<li><a href="#h3-Legacy-Storage-Format">Legacy Storage Format</a></li>
+<li><a href="#h3-Extended-Storage-Format">Extended Storage Format</a></li>
+<li><a href="#h3-Extended-Number-Format">Extended Number Format</a></li>
 </ul>
 </li>
-<li><a href="#h2-PORTABILITY">PORTABILITY</a></li>
-<li><a href="#h2-EXAMPLE">EXAMPLE</a></li>
-<li><a href="#h2-LIMITS">LIMITS</a></li>
 <li><a href="#h2-FILES">FILES</a></li>
-<li><a href="#h2-SEE-ALSO">SEE ALSO</a></li>
+<li><a href="#h2-PORTABILITY">PORTABILITY</a>
+<ul>
+<li><a href="#h3-setupterm">setupterm</a></li>
+<li><a href="#h3-Binary-Format">Binary Format</a></li>
+<li><a href="#h3-Magic-Codes">Magic Codes</a></li>
+<li><a href="#h3-Mixed-case-Terminal-Names">Mixed-case Terminal Names</a></li>
+<li><a href="#h3-Limits">Limits</a></li>
+</ul>
+</li>
+<li><a href="#h2-EXAMPLES">EXAMPLES</a></li>
 <li><a href="#h2-AUTHORS">AUTHORS</a></li>
+<li><a href="#h2-SEE-ALSO">SEE ALSO</a></li>
 </ul>
 </div>
 </BODY>