FM StyleSheet ©MJH

(File modified: June 1, 2026 5:35 pm)
This site works better with Javascript enabled.
Michael J. Hannah, Los Ranchos, NM.

The purpose of this Style Sheet is to record the details of how I produce web pages from documents created with the Adobe® FrameMaker 2019® desktop publishing software (abbreviated throughout this document as FM) using its hyperlink and “Save as HTML” conversion features. This document with its formatting definitions also provides a template document for all other FrameMaker documents. The various formatting options were originally created when I was converting a set of FrameMaker documents to their set of web pages constituting the on-line book I was writing to describe and record “My Way” of customizing the genealogy software “The Master Genealogist™”. These were made to reside at the root directory of my own web domain dedicated to genealogy topics. Later those formatting options were further adapted to convert a set of FrameMaker documents to their set of web pages on the topic of the game of Bridge, as well as about this and other separate documents on Computer topics, and about my sIBM medical condition. Each of these topics were made to reside in a topic subdirectory of this separate web domain for my personal miscelleanous pages. I now expect to use the specifications in this style sheet as a baseline and template for any FrameMaker document which I convert to web pages, all of which are expected to reside in various topic subdirectories of my two personal web domains.

As new font families became publically available for free download, and became commonly set as new defaults for web browsers on laptops and smart phones, I updated my font choices to more modern options for both FrameMaker documents and their converted HTML files. I also learned how to ensure these downloaded font families were used both on Windows with Framemaker, but also when copied to my personal web domains for use by my HTML pages. For visual (and mental) consistency I now use these formatting styles and font families for all documents composed in FrameMaker, whether or not that file is intended to be converted to HTML. Finally I also have “tried” to customize a Microsoft® Word® master template to mirror the styles in this StyleSheet to be able to produce any Word documents I may need to create using matching formatting and font families. But that effort is still a work-in-progress as I only infrequently use Word, generally for shared incoming or outgoing documents.

I choose to have some special features on many of my web pages which are not directly possible by simply creating FM documents and using the program’s function to convert them to HTML. While some of these features can be produced by special HTML conversion coding in FM’s Reference Pages, I still find my current Adobe® FrameMaker 2019® version incomplete in its conversion of a document to HTML. Some of these limitations are due to my continued use of the now outdated FM’s 2019 version, and some because I only use the basic FM mode and not its “structured mode” or other more advanced features. These limiting factors are primarily due to my having been an early beta tester of FM in the late 1980s and into the 90s, and my subsequently constantly using it as my desktop publishing software in versions for over 30 years without these very latest modern features. I consider myself too familiar and entrenched in its long-time standard features and thus unwilling (and too old) to change to the new.

While the version I am using of FM can convert its document to basic HTML, I have found that this output file requires further customizing for my web use. I therefore found it necessary to write a custom Perl© script 1 which postprocesses the HTML produced by FM’s basic mode. Over time the actions I have gradually added to this script have grown it to over 1300 lines of code. Among “cleaning up” what I find to be many inappropriate or inadequate ways the basic FM conversion constructs some HTML elements, and adding several features to the web page not directly able to be provided by basic FM, the script also inserts any desired custom JavaScript into the HTML, and links each page to a common custom Responsive CSS (Cascading Style Sheet) file appropriate for a given group of web pages.

Most of these web customizations are accomplished by a combination of custom HTML entities, custom CSS styles, and custom JavaScript. The custom HTML entries include FM Hypertext markers, and entries on the FM Reference pages. Custom CSS styles created in custom .css files are described with the paragraph, character, and table formats below, as well as by linking to custom font familes. Among other things the special Perl Script mentioned above inserts links to these .css and font files as well as inserting JavaScript code from a text file into the HTML file to define those custom actions.

The first web feature I created was a “top-button” to remain fixed at the bottom left which when clicked will jump to a fixed location within this web file, usually the top of the file. This can be useful to provide a quick way to jump back to the top of the file, or to some form of table of contents of this file, or a table of links to related files associated with this file, whatever is appropriate for this file. A very early text/word in the document is set to the top-button character format and has a Hyperlink to the desired anchor name in the file. That text is not displayed within the content of the document but instead becomes the label within the button, and its SPAN Class of the character format invokes the CSS required to place the button at the bottom left of the browser window.

Next there are two places on the page where the reader now can click to send me comments and questions via email:

JavaScript recognizes a click on these features and uses a standard “mailto:” HTML statement to invoke the reader’s default mail agent. The script automatically sets the “To:” to my email address, and creates a “Subject:” which indicates not only the name of the current web page, but also the hash link indicating to which part of that page the browser last jumped as a result of clicking a hyperlink into or within this page. The default CSS keeps these two email links hidden, but if (and only if) JavaScript is active the CSS of the links is automatically modified to make them visable. This way if JavaScript is not running, the user is unaware of anything missing other than a gentle warning in red at the top of the page which states: “This site works better with JavaScript enabled.”

Much of the CSS I use is common to all my web pages for all my various topics to provide a consistent appearance for the page layout and all headings, font families, paragraph styles, and tables. Further I have included CSS @media functions to attempt to have “Responsive HTML” for all my pages to make them at least “readable” on the wide variety of screen sizes in use these days. This also includes appropriate CSS to allow line height to adjust to the user’s font size, and such entities as tables and margins to automatically and appropriately resize and scroll to adjust to screen size, and using the HTML <wbr> entity to indicate where long words can be split if needed on a small screen. For testing purposes I also included changing the value of the “--background” CSS variable within each @media section to a different color to know which section is operational. But for production purposes I remove those changes to have that variable always set to my custom parchment-like color for all my page’s backgrounds of #FFF8DE (RGB 255, 248, 222). Also I (try to remember to) use the W3C Validation Service to validate my custom HTML and CSS files.

Inserting a hypertext command in an FM document has been a feature since early in FM’s existence. However only some of the many defined FM hypertext commands intended for links between FM documents will be converted to equivalent HTML constructs. Thus since my focus is to convert to HTML I limit my use to the three FM hypertext commands listed below which will convert.

FM provides a checkbox option on the Hypertext pop-up window labeled “Validate Command upon Insertion”. I recommend always checking this option so that FM will provide appropriate warning messages when inserting or editing hypertext commands. Regardless of your response to any warnings FM will store whatever is entered as the parameter to the hypertext command. I created a separate document which itemizes all the different types of HTML hyperlinks I am likely to try to produce from an FM document, which FM hypertext parameter entries will produce a warning or error, and what exact HTML hyperlink is produced from that parameter entry upon FM’s basic conversion to an HTML file. Since an invalid hypertext parameter will be accepted by FM, even with a warning, my Perl program also does some validation of the HTML hyperlink FM actually produces.

Each of the three hypertext commands I use is entered by chosing an option from a menu of all the possible FM hypertext commands. The three menu items below will cause a pop-up to appear prefilled with the (one word) command name of that option.

Whatever text is entered as the parameter to this “newlink” command, such as “newlink some link”, will be considered a linkname and will always convert to the HTML construct:

with no bracketed text, which creates that named target HTML hyperlink tag at this location in this document’s converted HTML file.

The complete construct of the parameter to this “gotolink” command is “gotolink filename.fm:linkname” where filename can include a leading path. If there is no colon separator in the parameter FM will assume that the entire entry is a linkname within this current FM document whatever the format of that text. If the entry includes a “filename.fm” followed by a separator colon, that filename must be of some other FM document on disk. The absence of a linkname will always produce a warning if the option mentioned above is checked, and may produce a meaningless hyperlink. The “Validate” option will search for the file if a filename is entered, and will always search for the linkname within the specified file. The HTML hyperlink that will be produced from the complete entry shown above is:

The exact HTML hyperlink produced will depend upon the FM hypertext data entered, such as the nature of the filename and whether it includes a leading path, as described concerning my testing of all likely valid and invalid data entries in the separate document previously mentioned, and in the list below describing my restricted valid data entry.

The parameter of this “message” command must be a complete URL of some external web page, possibly with a linkname, such as “messsage https://www.rr-nm.net/IBM/Alinker-IBM.HTML#Updates” which converts to the HTML hyperlink construct:

<A HREF="https://www.rr-nm.net/IBM/Alinker-IBM.HTML#Updates" CLASS="URL">active text…</A>

An FM anchor identifying the FM hypertext command and its parameter is inserted at the current cursor location which will be within an area of text all having the same character format. This “area of text” with its common character format becomes the “active” text of FM’s inserted “Jump to” and “Go to” hyperlink commands. If the anchor is placed in text in a paragraph which contains no character override format, then all of the surrounding non-formatted text of the paragraph will be bracketed as the “active” text to trigger the command since that text is all the “same” character format. Often I use an override format (e.g. computer) to provide visual contrast for the specific text which I wish to be “active”, and thus can place the anchor (usually at the beginning but) within the override formatting of that text which will now bracket only all that contiguously formatted text as active. However, it is not always appropriate to use some overriding visual formatting on what is to be the active text. For this reason I created the FM hyperLink character format for the sole purpose of specifying the “active” text to be bracketed by the converted HTML hyperlink. This override format’s definition allows it to be assigned to a specified amount of text without also imposing any extra textual formatting on that text. As noted with the description of this format if that text already had an override format, assigning this hyperlink format will revert that text’s formatting to the paragraph default. WARNING: If the CSS of the active text formatting imposes a specific color such as my red format, the browser coloring automatically used for all active text will override that coloring, thus that text will not be red. However if the character itself is a color, such as colored emoji, then that character’s color will still appear.

To avoid unnecessary complexity I follow a strict data entry practice for the parameters of the few FM hypertext commands I use. What I limit myself in entering in the parameter depends upon which FM hypertext command is being inserted and where the target of the hyperlink is located. Much of my data entry practice is based on testing which determined what the FM conversion will (and won’t) produce from a given hypertext entry for the HTML hyperlink. As mentioned above those testing results are described in detail in my separate document.

For the “Specify Named Destination” (or “newlink”) command I choose to make the parameter a short label of possibly abbreviated text, without internal spaces, which reflects the topic being referenced by the new linkname.

For the “Go to URL” (or “message”) command the parameter must be a complete URL of some external web page, and since I know any linkname will be converted into the HTML hyperlink I often include one.

For every “Jump to Named Destination” (or “gotolink”) command a “linkname” must be included as part of its FM hypertext parameter, even if that is the only value entered. A linkname is required to avoid the majority of the errors FM could introduce in converting invalid hypertext, especially if one is prone to either turn off or ignore its warning option. To provide a default linkname which would always be useable for linking to each of my FM documents, I define an anchor named “Top” for all my documents to simply open it at its beginning. This named anchor is inserted by FM during conversion by including the following HTML text at the very beginning of every document’s Reference Pages “Start of Doc/Replace With” which uses my special HTML syntax character codes:

Because this top-of-document linkname is only added to the document in the conversion process the “Validate” option will not find it. Thus any link to one of my FM documents entered with this linkname will produce the “does not yet contain the named destination” warning, but that may be ignored as the linkname will exist in the converted HTML document. An example of getting this warning is with a link to a topic index file whose link should always be to the FM filename. The Perl conversion script will always change an FM link to indexGroupname.fm to index.HTML, and will insert the target to indexGroupname, but only if the true FM filename is used.

The filename portion of the “gotolink” command’s parameter depends upon the relative location of the FM document with respect to this current FM document. I choose to limit the relative locations I use of the document containing the linkname to the following, with the first format preferred:

Data entry: For ease of entry I almost always enter the parameter with just the “linkname” (with no leading colon). But the parameter may include “this” filename, and may even have the optional leading relative pathname text of “./” indicating “this” folder. Thus either “this-document.fm:linkname” or “./this-document.fm:linkname” are also acceptable, although entering “this-document.fm:linkname” probably makes the most sense as that matches what is always the converted output.

Converted hyperlink: Regardless of the three above entry formats it will always include “this” filename but will not include the leading relative pathname text indicating this folder:

Data entry: Obviously the parameter must contain the filename and linkname. But the parameter may have the optional leading relative pathname text of “./” indicating “this” folder, thus either “folder-document.fm:linkname” or “./folder-document.fm:linkname” is acceptable.

Converted hyperlink: Similar to a link within the current document the converted hyperlink will not include the leading relative pathname text indicating this folder:

Perl Target: A Base Target is required to be defined in this document to avoid needing to set an explicit target as this same-folder name is not within the HREF value to use as the target.

Data entry: Obviously the parameter must contain the filename and linkname. But the parameter also must include the leading relative pathname text of “../” indicating the parent folder such as “../parent-document.fm:linkname”.

Converted hyperlink: The parameter will be converted to a hyperlink including the relative anonymous pathname text:

Perl Target: The name of the parent folder is not within the HREF value. However a Perl script will extract it from the current working directory and use it as the default target.

Data entry: Obviously the parameter must contain the sibling folder name, the filename and linkname.. But the parameter also must include the leading relative pathname text of “../” indicating the same parent folder as the current file, such as “../sibling-folder/other-group-document.fm:linkname”. I am unaware of any alternative format which will work.

Converted hyperlink: The parameter will be converted to a hyperlink including the relative pathname text of the common parent folder:

<A HREF="../sibling-folder/other-group-document.HTML#linkname" CLASS="Hypertext">active text…</A>

Data entry: Obviously the parameter must contain the child folder name, the filename and linkname. The parameter may have the optional leading relative pathname text of “./” indicating “this” folder in front of the child folder name, thus either “child-folder/child-document.fm:linkname” or “./child-folder/child-document.fm:linkname” is acceptable.

Converted hyperlink: Similar to a link within the current document the converted hyperlink will not include the leading relative pathname text indicating this folder in front of the child folder name and will simply begin with the child folder name:

<A HREF="child-folder/child-document.HTML#linkname" CLASS="Hypertext">active text…</A>

Data entry: Obviously the parameter must contain the child and grandchild folder names, the filename and linkname. The parameter may have the optional leading relative pathname text of “./” indicating “this” folder in front of the child folder name, thus either “child-folder/grandchild-folder/grandchild-document.fm:linkname” or “./child-folder/grandchild-folder/grandchild-document.fm:linkname” is acceptable.

<A HREF="child-folder/grandchild-folder/grandchild-document.HTML#linkname" CLASS="Hypertext">active text…</A>

For many HTML actions I define single character macros which will be replaced with custom HTML code wherever that character is inserted in the document, with examples described in more detail in the HTML characters section. However, the FM Reference Pages also can be used to define HTML code which will be automatically inserted within the created HTML file. I primarily use the StartOfDoc, EndOfDoc, and Head macros within the System Macros which will be inserted in the HTML file in the fixed locations described below along with Perl script inserts.

The “Head” HTML code in this document’s Reference Pages System Macros StartOfDoc macro

This typically includes custom text for the browser to label this page, including a link to my site icon and a title with a copyright symbol. [Any HTML syntax characters in this code must instead use the macro character to be converted to the actual HTML character.]

[This element is replaced by the Perl script with <BODY onresize="setView()"> to automatically invoke the custom responsive JavaScript.

The primary contents is JavaScript code, primarily for the CSS to be responsive to the browser window size, as well as the code for the email buttons to open a Mail compose window with a Subject reflecting the location last linked within this file. [Macro HTML syntax characters not required in this text file.]

The “Replace With” HTML code in this document’s Reference Pages StartOfDoc macro text.

This typically includes code to insert at the top-of-page: first a hyperlink anchor named “Top”, then links to the parent site index and topic index pages, the title of this page with copyright notice, and a special character macro which will display an icon image at top right reflective of this topic. [Any HTML syntax characters in this code must instead use the macro character to be converted to the actual HTML character.]

The “Replace With” HTML code in this document’s Reference Pages EndOfDoc macro.

This typically includes a Disclaimer text about the comments within this page, information about its construction, and copyright text. [Any HTML syntax characters in this code must instead use the macro character to be converted to the actual HTML character.]

I choose to have my Perl script examine the “CLASS” attribute of all hyperlinks produced in the converted HTML to check for either “Hypertext” set by the FM “Jump to Named Destination” (or “gotolink”) command or “URL” set by the FM “Go to URL” (or “message”) command as shown above. Not only does the script then do some checking to ensure such hyperlinks are valid, but it also may insert an appropriate “TARGET” attribute into the HTML hyperlink element. To avoid having the script examine and possibly alter a hyperlink inserted manually, such as may be inserted in the Reference Pages StartOfDoc and EndOfDoc, either do not include a “CLASS” attribute or use some other classname than those automatically used by FM. Regardless I try to ensure an appropriate target value is also included in such manual hyperlinks as appropriate.

For any “URL” class the script inserts a target of “_blank” which opens these external links in a new separate tab. No other modification of the hyperlink is made.

For any “Hypertext” class where the HREF is to this same document the script removes the filename while leaving the anchor linkname, and then inserts a target of “_self” which opens these links in this same tab.

Otherwise any “Hypertext” class will reference some other FM document on this site relative to the current document. Whenever I post multiple HTML files about a common topic I “group” them into their own separate common folder with a name indicating that topic. I also choose to have links to files in each group have different targets than links to files in any other group so the browser will have separate tabs open for each group.

Most files of the same topic reside in the same folder. As noted above Perl cannot easily identify the groupname of file in the same folder from the HREF to set as the explicit target name. If every FM file associated with a given topic will insert a common HTML “base” code after conversion to set its own groupname as the default target name for hyperlinks within that document then there is no need for an explicit target. In the absense of an explicit target in an HTML hyperlink the browser will automatically use the “base” target for that file’s links. Thus the following HTML code is typically set in the FM Reference Pages generally at the end of any “Start of Doc/Head” code using the special HTML syntax character codes:

As a result of this “base” entry in the converted HTML file any link to a file within its same group (which means any file in its same folder) does not require an explicit target inserted within such HTML hyperlinks as it will use this base name as the target. Note that if no “base” target is set in the file the Perl script will automatically add that HTML command using the current folder name as the default target name. Note that by use of a “base” target different than the folder name a separate topic “group” can be displayed in their own tab.

Due to my folder grouping a link to a file located in some other folder now implies it is in a different group. As noted above for any “sibling” or “child” folder the “groupname” of such a referenced document in a “gotolink” command can be determined from the contents of the resulting HREF attribute of the link. That “groupname” then can be used by the script to construct an appropriate explicit target name for all such “other folder” files. While the parent folder name is not included in the HREF attribute, its folder name can be extracted by Perl from the current working directory for use as the target name.

Because of the limited legitimate formats of a CLASS="Hypertext" converted HTML hyperlink resulting from my restricted data entry to a “Jump to Named Destination” (or “gotolink”) command as described above, the following are the only five formats of the resulting HREF element which can be in a converted HTML hyperlink:

One way the script can quickly distinguish among them is by the number of slash characters (‘/’) within the HREF text: the first two formats have none, the second two have one, and the third has two. My script uses this characteristic to identify the type of location and thus the modification actions to take. It then determines the groupname and sets the default target name as that name.

• If there are zero slashes there are two valid cases for the location of the link: this document, and a document in this same group/folder. These two cases are distinquished by the text before the .HTML extension which is the filename.

If the filename is the same file the script is processing, the script removes the filename and extension as unneeded text and the target is set to “_self” which will open this link in this current browser tab. (Any further checking of the hyperlink by the script, such as for a special reserved filename, will obviously be skipped.)

For all other filenames the link is to a document in this folder. The default “base” target within this HTML file mentioned above is sufficient for browser use and the script will not insert an explicit target. However it is still possible that this is one of the reserved filenames which is checked later, so the script sets the default target name to the current file’s groupname as a flag for that later checking.

• If there is only one slash there are two valid cases for the location of the document with the link: in the parent folder, and in a child folder. These two cases are distinquished by the text before the slash which is the folder name.

If the folder name is exactly “../” (which is the anonymous relative path of the parent folder) the parent’s folder name is extracted from the current working directory and the default target name is set to that value.

If the text before the slash is not the parent relative path the default target name is set to that text before the one slash, which is the child folder name.

• If there are exactly two slashes there are two valid cases: the document is in a sibling folder, or in a grandchild folder. If the text before the first slash is exactly “../” (which is the anonymous relative path of the parent folder) it is a sibling and the name of the sibling folder will be the text between the two slashes. If not then that text before the first slash is a child folder name and the name of the grandchild folder will be the text between the two slashes. The default target name is set to the text between the two slashes.

• If there are three or more slashes the script reports an ERROR with enough information about this link in the file so it may be fixed in the FM document. It will then ignore this link and not insert a target, but process the rest of the HTML file.

In all these cases the script will now check if the HREF filename is one of the special reserved names. If so the script will change the target appropriately so it will open in its own special browser tab.

First the script will check if the HREF filename is the very special case with the reserved name beginning with “index”. First while I do not use this name as a folder name and therefore will (should) not match the currently set default target name, I reserve the name “Site” as the groupname of files at the top root level for a site’s domain. Thus “indexSite” will be the filename at the root and will be set by the script as the special target name of this very special file. For all other files of the format “indexGroupname.HTML” the script will compare this file’s “Groupname” with its default target name, which if it is not a link to the current folder should be its folder name. If a match the script will set the target name to “indexGroupname”. For either case of these special filenames, to correspond to the filename change which the script will perform when such a specially named FM document was itself converted, the script will also change the filename in the HREF to exactly “index.html” which is the default file served when a URL is just to its group folder.2 Note that each folder may have only one file named exactly “index.html” but references can be to such a file name in multiple folders other than the current folder.

If the filename begins with exactly “index” but the following text was neither “Site” nor its groupname as noted above, this violates my file naming conventions and is an error. The script will report an error and leave the hyperlink unchanged.

The target names for the remaining special filenames will simply be identical to their reserved FM names including their identifying trailing uppercase characters but minus their file extension. Thus there will be a separate set of special targets for each groupname in whatever folder. These remaining special filenames are: a separate file for a table of contents of this topic is named “GroupnameTOC”, a file which is a separate introduction to this topic is named “GroupnameINTRO”, and a file containing a separate overall index to this topic is named “GroupnameINDEX”.

If no special filename was found and the default target name is this current file’s groupname, no explicit target is inserted in the hyperlink as there is expected to be a base target. Finally all other filenames will have a target explicitly set to the already set default target name.

Thus by using these data entry restrictions the Reference Pages and Perl script can ensure all links to any type of file in a given group/folder will have a target inserted which is appropriate to that group and file. For example this will cause all ordinary files in the same group/topic to open and display in the same appropriate tab.

With the advent of modern digital devices like the “smart” phone which have introduced their own often proprietary HTML features and fonts, it has become increasingly difficult to provide a consistent appearance to the FM documents and the display of the HTML produced across muliple platforms such as a laptop or a phone.3 A major issue concerns what font families will be used by that platform’s browser, as many of the FM traditional fonts are not easily (or at all) available on a given phone or manufacturer’s platform. In these cases the display will often default to using the platform’s own, often proprietary, different font-families. As a result I have shifted from using old fonts which I had been using in FM for years to a more modern set of font families. These allow me to both install them on Windows to use in FM, as well as store copies on my on-line servers for my web pages to use. In addition my CSS use of line-height as a function of em (the size of the current font) also resolves the issue that some font families default to larger line heights.

I have thus settled on six typeface categories for various text purposes in my documents: Serif for most text; SansSerif, MonoComputer, MonoSerif, and MonoSansSerif for highlighting and special purpose text; and three Symbol families for Symbols or Emojis. The specific font families chosen for these categories are all publically available and their licenses permit my personal non-commercial usel. In order by category they are: New Century Schoolbook 4, FreeSans 5, Inconsolata 6, Courier Prime 7, and Noto Sans Mono 8; plus Symbola 9 and FreeMono 10. While both Noto Sans Mono and Symbola contain most symbols in the Unicode Basic Multilingual Plane (UBMP) they also include basic text characters: Noto Sans Mono monspaced sans and Symbola variable spaced serif. FreeMono was downloaded as a fallback to provide some additional monospaced special Unicode characters otherwise unavailable in Noto Sans Mono such as the Box characters. In addition Noto Emoji 11 and Noto Color Emoji 12 were downloaded to provide most of the various Unicode symbols and colored emoji beyond the UBMP which I am likely to use.

As shown below and recommended as standard practice, my CSS also references other similar generic font families presumably available on platforms as fallback for each category in case the link to my local font files does not work. [I assume that if either my local copies or the global copies of my chosen fonts are available they should be used first. Thus I put other fallback fonts after both versions of my preferred families.]

For the HTML files my post-process Perl script adds a link to a separate stylesheet file named {groupname}-Fonts.css containing all the @font-face rules for the font families used by that group of HTML files posted on a common topic. This separate stylesheet is then referenced in the custom CSS stylesheet file for that group which in turn references their custom local font name. Example @font-face rules for my chosen font for SansSerif category in such a Fonts separate stylesheet are shown below. They reference the local url location of the individual font-face files, and set the common custom local font-family name for all variations:

src: url(../Common/Server-Fonts/freefont-20120503/FreeSans.woff) format('woff');

src: url(../Common/Server-Fonts/freefont-20120503/FreeSansBold.woff) format('woff');

src: url(../Common/Server-Fonts/freefont-20120503/FreeSansOblique.woff) format('woff');

src: url(../Common/Server-Fonts/freefont-20120503/FreeSansBoldOblique.woff) format('woff');

The CSS that specifies which HTML elements shall use each category of typeface chosen for that group’s HTML pages is included in the main stylesheet for that group as shown below and occurs near the beginning of the Body section to ensure them as defaults:

Used as the default for all standard text in most paragraph formats. I include the Symbola family as a fallback to display any emoji/symbol characters within the UBMP which may be included in ordinary (non-monospaced) text.

• Primary: New Century Schoolbook, Symbola; Secondary: Times New Roman, serif.

• FM entities: paragraphs without an explicitly specified font-family; and the separate character formats serif and smSerif.

Used for contrast to the default serif, such as with all major headings, and where I wish have a paragraph with a default Sans-Serif typeface so it is possible to apply character formats to individual characters. This chosen Sans-Serif font family (FreeSans) makes a good contrast for the character format sans and for header paragraphs but not for normal full paragraphs as the characters take up less width due to their lack of serif. However when used as a character override, this font displays slightly taller than the default Serif font, so I set sans override formats, such as sans, to a font size in CSS of 0.97em. As FM does not have a “relative” size setting there is no special action in FM. I leave a full font size for the paragraphs which default to this font as this will display any non-sans override characters as slighly shorter.

This font family also aligns higher on the line thus giving a larger bottom margin for each line. This is unnoticible for heading paragraphs but disturbs normal paragraph spacing.13 Therefore the following equivalent normal paragraph names ending in “Sans” and the two Index paragraphs with this as their default font family are set with a slightly lowered vertical alignment to visually match paragraphs with other default fonts:

I do not include Symbola as a fallback since is it is a Serif font and I don’t expect such characters in these formats which are primarily designed for headings and contrast.

Used for fixed data, typically computer text, which I force to SemiBold/600 for contrast. I chose this specific family to be (semi-)sans as a contrast to normal serif text, but specifically because it has a slashed zero to be distinguishable from a capital Oh. Inconsolata and its fallback Courier fonts include some, but not all, symbols/emojis within the UBMP, although they do not always align. I do not include Symbola as a fallback as it is serif and not monospaced. Any symbol/emoji characters which must be monospaced and aligned should use the general monospaced Sans-Serif text category described below. However because of my stretching this Inconsolata font as noted below, my other general monospaced characters need to be stretched to align with these “computer” monospaced characters. (See the monospace paragraphs discussion.) I also specify several standard fallback fonts to try to ensure this text is different than the default narrative text.

NOTE: This typeface Inconsolata for this category of text has no defined italics. While many browsers will automatically produce a pseudo italics, I almost never use italics with these “computer” paragraph and character formats so this is not an issue for me. When visually compared, the default height of the actual characters of this font is slightly shorter than the equivalent default serif font. I generally find this appropriate for ordinary text so do not adjust it for either the paragraph format Computer or the character format computer.

I find the Inconsolata default width cramped. FM sets font Stretch to 125%, and the specific Inconsolata-w-local font-files for web use were downloaded defined internally with a ‘w’idth” 125%. (NOTE: Since also forced SemiBold/600 when assigned to these paragraph and character formats, trying to change its text weight using any override character format within that paragraph is ignored!!)

• Primary: Inconsolata; Secondary: Courier Prime, Courier New, Source Code Pro, Roboto Mono, monospace.

This special font family is used for fixed ordinary text which must align, such as in tables. Most Symbol/Emoji characters do not exist in this monospace font, so this font catetory should not be used for them. I choose not to include Symbola as fallback as it is not monospaced. If necessary I should use the MonsSans paragraph for such characters. This monospace Serif font width is “slightly” narrower than the other monospaced fonts, thus like all my monospaced fonts it has its unique stretch value to align horizontally with the Computer font. (See the monospace paragraphs discussion.) If symbol/emoji characters are undefined in this Monospaced Serif format the HTML will show them in whatever is the browser’s default for such characters, which may not be monospaced and thus not align.

• FM entities: paragraph formats MonoSerif and E-mail (also originally named e-mail); and the character format monoSerif.

For general monospaced text output. I choose to have a different font than the monospaced Sans-Serif I use above for computer data to differentiate their separate uses. Noto Sans Mono does contain many of the emoji/symbol characters within the UBMP and displays them monospaced aligned with the rest of its text in both FM and HTML. However, I added FreeMono as a fallback to provide several monospaced special characters undefined in Noto Sans Mono which I wish to use. I do not include the font Symbola as a fallback since it is not monospaced. The definition of the Noto Sans Mono font family produces a font size slightly larger than the other font families I use, thus like all my monospaced fonts it has its unique stretch value to align horizontally with the Computer font. (See the monospace paragraphs discussion.)

• FM entities: paragraph formats MonoSans (was Mono) and Equation; character formats monoSans (was mono) and the automatic character formats for equation characters and variables. Note: the character format EqNum, which numbers equations, converts to PLAIN TEXT so there is no SPAN declaration in CSS for it.
Warning: FM has no fallback font mechanism, thus only the Noto Sans Mono font will display in FM. Characters which “would” fallback to FreeMono in HTML will likely show in “some” FM font, but they are unlikely to be monospaced or align.

I generally use the Symbola font family for symbols/emojis but it only includes the UBMP characters. I do include it as fallback for any formats using standard serif text characters if that format may include some of these UBMP characters. But I can have text intended to contain only symbols and emoji characters, some of which may be beyond the UBMP. I therefore have defined paragraph and character formats for these symbol specific situations. [I do not currently define Symbol paragraphs with all vertical and horizontal text alignments as I currently do not use these paragraphs in tables. But all variations of (‘Bot’, ‘Mid’, ‘Top’) and (‘Left’, ‘Ctr’, ‘Right’) could easily be added for Symbol tables if that situaton arises.] I assign the two font families which will default to text variations first as I generally prefer that variation so do not need to append the Unicode text variation selector (︎), but do include a color emoji variations font family last which will be used if there is not a text variation for that character. These three families should include most any symbol/emoji character I am likely to use. I can specifically force an emoji variation on an individual character by appending the Unicode emoji variation selector (️). That third fallback font will be used with the selector as an emoji variation likely does not exist in the first two families.

• FM entities: special paragraph formats Symbol and SymbolCtr; character format symbol.

There are several different alignment characteristics which exist for paragraphs and their text with respect to their presence in narrative flows and in tables, and these are dependent upon the font used. Vertical alignment in narrative flow involves how a paragraph or a whole table relates to other elements before and after them, and how the lines of text within a paragraph relate to lines before and after other lines in that paragraph (ie.e line height). Vertical alignment of a paragraph within a table cell relates to the cell itself and other paragraphs within that same cell. A paragraph and a whole table has a horizontal alignment within the narrative flow boundaries. Likewise a paragraph will have a horizontal alignment within its table cell. Finally horizontal alignment of the lines of text within a paragraph relates to the boundaries of that paragraph.

Many defaults for a table (e.g. the presence of a title) are set in its FM Table Format. In addition, paragraph styles to appear as default in a new table can be set for a given table format by assigning the desired FM paragraph formats on a new (or existing) table to any of the title, rows of heading cells, rows of body cells, and rows of footing cells. To save these paragraph defaults one must now update or save that FM table format. Further, after inserting a new table of a given format its default number of rows, headers, and footers can be saved if the format is updated or saved after the table is open. The FM paragraph format of a footnote within a table cell or table title is automatically set to the format name TableFootnote, but could be changed under Format/Document/Footnote Properties. (See also the more complete discussion about formatting Footnotes.) I choose to retain that default format name in both FM and HTML. I have removed from the paragraph catalog the following default paragraph format names for paragraphs within tables which I don’t use but are in the default FM document templates: Table Title, CellHeading, CellBody, CellFooting. Since all my table formats have been modified to use my custom paragraph formats, these default paragraph formats now “should” never occur in my documents.

Sometimes the nature of a set of data lends itself to be displayed as multiple thin side-by-side columns or tables. One example is a list of paragraphs of short data, which is best displayed as side-by-side columns of data running down the first column at the left, then continuing down the second to the right, etc. Another is a set of tables, typically narrow and of identical height, best displayed side-by-side, first table on the left and subsequent to the right. Both are difficult to accomplish with FM, requiring manually constructed multiple split text flows.

However such side-by-side display can be accomplished with custom HTML and CSS. Further to ensure more general usability, the CSS for such side-by-side display should be responsive to the available display screen size. The number of side-by-side columns of a list of paragraphs should increase or decrease to fit as the screen width is changed, with fewer columns increasing in height as needed. The number of side-by-side tables should also increase or decrease to fit as the screen width is changed, with overflow of any subsequent side-by-side tables placed below as the screen width is narrowed. Using appropriate HTML conversion code in FM which then links to custom CSS, both of these types of responsive display can easily be accomplished.

Side-by-side HTML columns containing a consecutive list of paragraphs can be formatted upon HTML conversion by appropriate XML Item Element code in the FM Reference Pages HTML Mapping Section for the paragraph type being used within the columns. That code defines a uniquely named “Parent” HTML Section for this paragraph type. For example the List paragraph has the XML Item Element code shown below to name a containing parent “ListSec” Section (and the ListNarrow paragraph equivalently names a containing parent “ListSecNarrow” Section).

So long as consecutive paragraphs have the same named Parent, upon conversion FM will construct a single named HTML SECTION container for this consectutive set of paragraphs. Any other paragraph format (i.e. without this same named Parent) will end this containing Section. The custom CSS parameters for this Section define a responsive container for columns, where each column has a maximum width. The contained children, e.g. the consecutive paragraphs, will form as many columns of this width, side by side, left to right, as can fit in this size browser window. If the window is too narrow (e.g. a mobile device) the consecutive paragraphs will at worst display as a single column. The CSS difference between the two Sections of “ListSec” and “ListSecNarrow” is simply the maximum column width as shown below.

Displaying a set of tables side-by-side also can be formatted in FM by using a single pair of consecutive Flex paragraphs to contain these tables. Similar to the above codes for a sequence of paragraphs, the XML Item Element code in the FM Reference Pages HTML Mapping Section for this Flex paragraph type defines a uniquely named “Parent” HTML Section.

In this case all the table anchors (each with my appropriate custom table character format) for that set of tables that are desired to display side-by-side should be the only items in the first Flex paragraph of the pair. That Flex paragraph should immediately be followed by the second Flex paragraph of the pair which is completely empty. Upon HTML conversion this pair of consecutive Flex paragraphs will be enclosed in a “parent” HTML “Flex” SECTION entity due to the XML Element code in the Reference Pages HTML Mapping Section. The custom separate CSS for this “Flex” Section defines a container where the contained children, e.g. the two or more narrow tables, will abut side by side, left to right, if they can fit in the browser window.

Any subsequent table which can not fit will display below the previous table(s). If the window is too narrow (e.g. a mobile device) the consecutive tables will at worst display as a single column, one above the next. For an example see the two Blank formatted tables below.

Every time an FM document is “saved as HTML” a new companion CSS file is automatically created, but only the in-use paragraph (and character) formats are translated to CSS properties. Among other things, appropriate properties for the four HTML table elements (table, tr, td, and th) defining a table are not translated into CSS from FM properties for any FM Table formats, nor is there any way to specify that a table should be scrollable in HTML. Further the HTML which is produced does not create thead or tfoot elements to enclose the header and footer rows to identify whether a tr row containing th cells is within a header or footer.

Since the FM conversion does not output such table information which is needed by the post-processing Perl script to produce appropriate HTML formatting, I assign a custom FM Character Format to the FM table anchor (and only that anchor, not any surrounding characters). The naming scheme of a table anchor Character format is “Table-formatname” to mirror the FM Table Catalog format naming scheme of “T-formatname”. (As these Character formats never transfer to MS Word they are the only capitalized Character format names.) Since the table format name is not otherwise output by FM to HTML it is essential to assign this matching character format to the table anchor so the Perl script can assign the appropriate CSS CLASS name to the table (i.e. this formatname) to invoke that specific CSS styling.

Actions in the Perl script based on these formatnames include recognizing my fixed set of formatnames who are to have HTML elements inserted to provide centering of only these tables. In addition to adding these and other missing HTML elements based on such custom cues in the FM generated HTML, the postprocessing Perl script changes the default CSS stylesheet link in the HTML to a common CSS file used for all this group of FM documents. Thus for the table itself and for the paragraphs in an FM table to match the “look” of the CSS table class assigned by the format cue to that table, both FM and CSS table settings and paragraph formats should be chosen to produce equivalent “looks” to their tables. Only in that way can the look of the FM document approximate the resulting web page and vice versa.

FM does not have scrolling tables as part of its desktop publishing definitions, since its primary purpose is publication as a printed document. Thus it simply duplicates headings for any table which cross a printed page. However, on a web page it is often desired to restrict the view of a table to the current screen size and include scrollbars to indicate there is more to the table. After lengthy investigation on the internet and learning CSS I have developed a method to produce automatic scrolling based solely on Responsive CSS code along with inserting appropriate HTML.

To provide a scroll cue to the postprocessing script, the name of the FM character format applied to the FM table anchor described above has two parts. The first part is the common “Table-formatname” text which identifies the defined table format name, the second is a suffix of the exact case-sensitive text “Scroll” appended to that character format name. Thus an actual FM character format name for a table anchor of a table to be scrolled is “Table-formatnameScroll”. This suffix is detected by the Perl script to cause it to then add HTML elements as described below to bracket this formatname style of table and cause scrolling. The associated CSS styles for these elements are defined so that:

• the table size will adjust to the screen size of the device or window size when viewing the page,

• all header rows will have column sizes matching the content columns below and the header will remain at the top of the scrolling body of the table,

• all header rows will remain fixed at the top as the body of the table is scrolled for the three decorated table formats, otherwise only the last (if multiple) header row will remain fixed for all scrolled basic table formats,

• and any hyper link jumps to targets within a scrolled table will automatically scroll the table to position the target to be visible just below the fixed header row.

Just like for non-scrolled tables the fixed list of scrolling table formatnames which are intended to be centered will have extra HTML elements recognized by CSS to ensure any such scrolled table whose width is less than the current screen will itself be centered.

If a Title is included with the FM table it is output as an HTML caption element within the bracketing HTML table elements. However the Perl script’s addition of the thead (and tfoot) elements does not include the caption within thead. Since the added containing div elements to cause scrolling must bracket the entire table, the caption will not remain fixed at the top with the last of (or all of) the heading rows. Thus the CSS code for scrolling will cause such a caption internal to the table to scroll up out of sight when scrolling down the table. If I wish a title to remain for a scrolling table, I therefore provide it as a separate paragraph in front of the table, instead of as part of the FM table. Unfortunately if the format has the entire table aligned left, there is no way in FM to identify the width of such a table and thus center this separate title paragraph over that table. However a table class which centers the table itself can be matched with a leading separate title paragraph which in turn is also centered.

As mentioned above in the beginning overall description of scrolling, whether all header rows, or just the last, remain fixed at the top as the body of the table is scrolled depends on specific table formats to trigger the required CSS. I choose this so that I can choose between these options depending upon the nature of the data in the table. Scrolled FormatB, FormatM, and FormatT tables retain all header rows, all scrolled “basic*” table formats retain the last row, and blank tables do not define a character format to cause scrolling. While additional table classes with additional matching CSS code could be defined to fix one or more footer rows to the bottom of the scrolling area, the table classes and code I use does not (currently) do so. Any FM table footer rows will simply appear when the body of the table is scrolled to the bottom.

Using “Responsive” HTML I define CSS variables to specify vertical padding for hyperlink anchors which can be set by @media statements according to the size of the screen to ensure the hypertext target appears below any headers. I use variables since headers can be squeezed and thus their vertical height can grow as the screen width decreases. Thus I set most variables to increasing vertical padding for these anchors for narrower screens.

--scroll-padding-top is used to move any named <a> link target within a scrolled table below the fixed header of the table.

--FNum-padding-top is used to move any <a> link target named FNum, which are endnote targets within the text, down to display some lines of context above it.

--index-padding-top is used to move any named <a> link target within a scrolled index below the alphabet jumpbar in an Index file.

Different CSS files for a given group of pages can have different values, such as for larger image headers in all the scroll tables in the Bridge group. Current values used for standard pages are:

As mentioned above in the beginning overall description of scrolling, the CSS code which actually provides scrolling is invoked by using the postprocessing Perl script. It adds a surrounding <div class="Scroll"> to the HTML of the table if the table’s character format specifies scrolling. Obviously some of the display values could be changed as desired, but most of this code is required in some manner to produce the formatting desired. The “Scroll” suffix on the table class name will cause Perl to insert the following HTML structure surrounding the table’s HTML. If the table formatname is one of a fixed set defined in the script (e.g. formatnames with “Ctr”) the added ScrollM div element provides centering of this fixed set of scrolled tables.

The CSS to cause the last or all rows of the header to remain fixed to the top and to have background to cover the scrolled text behind the headers depends upon the formatname of the table. The borders for header cells must be set “within” the heading cells if they are being fixed, and differ depending upon the formatname of the table. First the header statements for scrolled basic tables:

The vertical alignment of a whole table is set by the top and bottom margin properties of the table itself in both FM and CSS. In FM this is set by the Top and Bottom margins on the Basic tab of the FM Table Format. In CSS this is set by the properties margin-top and margin-bottom of the CSS table element. As described above, assigning an appropriate CSS class with values to match the FM table format provides a way to ensure these values will display the same in both using the same units.

Paragraphs, whether or not within a table cell, can also have their own top and bottom vertical margin (spacing) properties in both FM and CSS set by the same types of properties as tables. These properties are usually for the purpose of separating a paragraph from elements before and after in a narrative flow. These paragraph margins will also affect the vertical space between paragraphs within a table cell in both FM and HTML, but not the vertical alignment of the paragraph within the table cell. That alignment is set with the paragraph in FM, but with the table’s CSS for HTML. Thus, if different, these alignments can produce different display results within a table in FM versus CSS as described below.

In both FM and CSS the vertical space between paragraphs, whether in a narrative flow or in the same table cell, will be the larger (not the sum) of the preceding paragraph’s “below” margin and the following paragraph’s “above” margin. For this reason most of my paragraphs have a zero “below” margin so that paragraph spacing is always controlled by the “above” margin. For extra space below, I can insert a paragraph with only a non-breaking space. My default is for all paragraph margins to be set the same in both FM and CSS, so I need to choose the paragraphs used in a table cell with this imposed correspondance in mind.

The default for this space between most narrative paragraphs is an unchanging height of 14pt/1.1667rem. Other values used for special paragraphs are also unchanging:

This is intentionally less than the changable default line height for a desktop monitor of 15.6pt/1.3rem. In contrast to these unchanging heights between paragraphs, as described below line height will adjust larger or smaller when displayed in HTML depending upon the font size and changeable size of the browser window.

In both FM and CSS the vertical spacing of lines of text within a paragraph is based on the font size of the font which is set as default for that paragraph, the separately specified paragraph’s line spacing, as well as the font family itself. (For example see the issue with the Sans-Serif font family I use.) Most browsers will normally increase an individual line height within a paragraph beyond its default if needed to accomodate elements other than normal text such as things as superscripts and footnote numbers, as well as increase for larger override font sizes within that line. In the one case of superscript footnote markers within the text I choose to prevent them from changing the converted default HTML line height as described below. Further I chose to make all HTML line heights Responsive to the size of the browser’s window by defining line height based on a custom CSS variable (--base-line-height) whose value changes with the size of the window.

While setting an FM paragraph’s Line Space to some value will provide a default and affect the paragraph’s line spacing, I make a point to not mark this parameter “Fixed” which is more difficult to match in CSS. Usually the line-height value should be somewhat larger than the default font size. The default or “normal” CSS value for a desktop monitor in most browsers usually is equivalent to at least 1.1-1.2 times the font height. As shown below I use a factor of 1.3 as the default. With that in mind and depending upon the purpose of the paragraph I set the CSS paragraph line-height using one of three types of values. Either it is a fixed multiplier on the unit rem (usually the browser’s fixed base font size 14) to produce a fixed height, or a fixed multiplier on the unit em which is based on the paragraph’s defined font size, or more appropriately a calculation of a multiplier on my custom CSS variable --base-line-height. This variable is typically used to set line height for all paragraphs and its value is some multiplier of the unit em so that this line height is based on the paragraph’s font size. Thus normally a paragraph with smaller font will have smaller line height, and a paragraph with larger font have larger line height.

Responsive HTML recommends varying the line height based on screen size, starting at the smallest value for small screens like portrait smart phones and increasing for wider screens. Because I set all paragraph line-heights based on this --base-line-height variable, and the variable’s value itself is a multiplier of em, I can simply change the value of this one base-line variable based on the width of the screen to now proportionally affect the line height of all paragraphs according to their font size. In that way the line height of all paragraphs will increase when there is more real estate to display the text, and decrease with less. I set a default base value of the variable as 1.3em, which is a standard amount for viewing pages on a desktop monitor as mentioned above. CSS @media statements then override that default for differently sized screens, and will do this dynamically if the user changes the browser’s screen size:

• default for most desktop monitors (width greater than 50 but less than 75 rem): 1.3em

Usually I just use this variable’s unmodified value for all paragraphs. Some recommend that smaller fonts should have somewhat larger line height, and larger have smaller line height. I do sometimes use a multiplier of 0.9 on this variable for a given paragraph if for some reason I wish the line height to be smaller than it normally would be (regardless of screen size), but do not currently make is larger. For example I use smaller line height for all paragraphs intended to be within table cells, and for lists.

NOTE: the default that FM automatically sets for Line Space for a 12pt font is 14pt which is a smaller factor of 1.1667em of the font size than my above default base value. I prefer the FM display to match the desktop monitor factor of 1.3. Therefore I need to override the FM default Line Space on all paragraphs. Computing from all the font sizes which I use, the following are the values of 1.3 times the font, and 1.3 times 0.9 times the font, for use in setting the FM paragraphs Line Space. Where I choose to have approximately a half line space, I use just under half. For example for a 12pt paragraph whose FM Line space would be 15.6pt using a factor of 1.3, I use 7pt which is only a factor of 0.5834 instead of 0.65.

CSS and FM font-size	CSS is --base 1.3*font	CSS is 0.9--base 1.30.9font
0.6667rem=8pt	10.4	9.36
0.75rem=9pt	11.7	10.53
0.8083rem=9.7	12.61	11.349
0.8333rem=10pt	13	11.7
0.9167rem=11pt	14.3	12.87
0.97rem=11.64pt	15.132	13.6188
1.0rem=12pt	15.6	14.04
1.1667rem=14pt	18.2	16.38
1.2rem=14.4pt	18.72	16.848
1.3333rem=16pt	20.8	18.72
1.5rem=18pt	23.4	21.06

I use this base multiplier to force a smaller than default line-height for several reasons:

• Some paragraphs I wish to appear more compressed because of the nature of their use or font:

• the paragraphs Singleline, and the List and ListNarrow paragraphs which are typically used for lists

• the various monospaced paragraphs which use their special monospaced font families to align data

• and all the paragraphs intended to be interior to a table data cell: Bot*, Mid*, Top* (and the seldom used Mapping Table Cell paragraph)

• Finally I reduce the line height of the Major paragraph and the sometimes used Mapping Table Title paragraph which have the largest font sizes to prevent their line height being “too” large, as a reduced line-height is recommended for paragraphs with the largest fonts.

The vertical alignment of a paragraph (and its entire block of text) within an FM table cell is set in FM in that paragraph format’s Cell Vertical Alignment setting on the Table Cell tab to one of AsIs/Top/Middle/Bottom. Thus for those paragraphs specifically intended to be in a table cell with a spcific vertical alignment their paragraph format names begin with (Top, Mid, or Bot) as appropriate.

But there is no CSS paragraph element property to set vertical alignment within an HTML table cell. Vertical alignment is only able to be (partially) set by the vertical-align property of the table cell itself, either in the th (header or footer) or td (data) cell element, to one of top/middle/bottom. Thus for those tables specifically intended to have its table cells’ paragraphs with a spcific vertical alignment their table format names end with (T, M, or B) as appropriate.

However the vertical alignment of a paragraph within its table cell can also be affected by its space between paragraphs and its line height noted above. Any FM paragraph format with any FM Cell Vertical Alignment setting “could” be used in a table where that class’ CSS table cell has any of the, possibly non-matching, CSS vertical-align properties. But the paragraph’s “look” in the FM versus CSS tables will be affected by the two environments’ (possibly different) sets of margins and alignment settings. These differences could defeat the desire for the look of the FM document to approximate the resulting web page when editing the document. Thus to get matching output an FM paragraph with a given Cell Vertical Alignment should only be placed in a table with the matching table cell CSS vertical-align properties. For example the cells in an ‘M’ table (e.g.T-basicM format) should have paragraph formats which begin with ‘Mid’ (e.g. MidLeftSans).

One clear difference between FM and CSS in the vertical alignment of paragraphs within table cells is that a CSS margin-top paragraph setting will be honored within the CSS table cell to move a “first” paragraph either:

• included in the paragraph box’s total height to lower the first line of text when positioning if a “middle” alignment.

In contrast, within the FM table cell the paragraph’s alignment is not affected by a first paragraph’s FM “above” margin. FM ignores the “above” margin on any paragraph at the top of a column or table cell (and ignores the “below” margin on any paragraph at the bottom of a column or table cell which I usually set to zero). Thus the “look” of the FM table will differ from the CSS table if there is a non-zero “above/top” (or “below/bottom”) margin assigned the paragraph which will occur at the top (or bottom) of a table cell in either or both FM and CSS.

Note that in the HTML table an entire row will have the box height of the maximum amount of text in any cell in that row. If the text of any cell will vertically fill that height, then there will be no extra vertical margins. And if all the cell text is the same height, the assignment of an FM paragraph format which matches the CSS vertical alignment may not matter.

There are different parameters which must be set to control the horizontal alignment of an entire table, an entire paragraph, or the text within a paragraph as shown below.

In FM the horizontal alignment of the table itself is set by the Align property on the Basic tab of the FM Table Format to one of AsIs/Left/Center/Right/Side Closer to Binding/Side Farther from Binding. But in CSS it is set in the table element, usually by the values of ‘0’ (zero) or “auto” assigned appropriately to the table’s margin-left and margin-right properties . Assigning an appropriate CSS class to match the FM table format can cause the two alignments to be the same. Since most of my defined tables do not have a fixed CSS width, the table width will generally expand based on its contents up to but not beyond the width of the screen. Thus centering a table is generally only noticable if the content is small enough where the resulting width of the table is less than the screen.

Paragraphs can also have their own left and right margin properties in both FM and CSS set by the same types of properties, usually for the purpose of indenting the entire paragraph from the outside edges of a narrative flow or a table cell. Again, my default is for all paragraph margin values be set to produce the same margins in both FM and CSS, so I also need to choose the paragraphs used within a table cell with this imposed correspondance in mind.

Such alignments are visually important to both identifying the heirarchy of paragraphs within the narrative of the document and a matching Table of Contents to reflect that heirarcy.

The Table of Contents paragraph heirarchy generally has a one-to-one relationship to the narrative paragraph headings and heirarchy noted below. (See also the list of Index Paragraphs which could also be used in a TOC.)

(Do not need to use DefHead with its larger text and underlining since this level TOC heading is usually hyperlinked which will display underlined.)

Body1 can reflect subordinate topics under a Major which do not deserve the importance of a separate Minor paragraph heading, such as subitems in a list under this Major topic. They may be identified in the text in a variety of ways such as Bullet or Number paragraphs, or a level 4 heading using BodySans, or even just an embedded bold term beginning the narrative paragraph.

Like Body1 above, Indent1 can be used to reflect subordinate topics under Minor which do not deserve a separate Topic paragraph heading, or even a list of Topic headings

Like Body1 and Indent1 above, Subindent1 can be used to reflect subordinate topics under Topic, typically identified with a Level 4 heading using BodySans.

While the primary method of establishing a heirarchy of headings and content for paragraphs is by font size, style, and family, horizontal alignment also can provide an obvious visual indicator of heirarchy. The folowing are the paragraph formats in the order which I generally use to indicate importance from most to least.

The horizontal alignment which positions the text within a paragraph’s boundaries affects its position both in a narrative flow and within a table cell. This alignment is set in the paragraph format in both FM and CSS. In FM it is the paragraph format’s Alignment setting on the Basic tab to one of left/center/right/justified. In CSS it is the paragraph element’s text-align property set to one of left/center/right/justify. Making these settings match allows the same set of paragraph formats to equivalently position the overall text of the paragraph horizontally in both narratives and table cells.

I define two sets of main paragraphs who first line is outdented with text: Bullets (and Subbullets), Numbers (and Subnumbers), Outdent1 (and SubOutdent1), and the List paragraphs. (See also Footnotes for an equivalent outdent.) Generally it is necessary to use paragraph formats with fixed left first line outdent values to offset that one line of text. In word processing it is typical to set a tab stop at the left margin used for the subsequent lines of the paragraph. Then a tab can be used after the outdented text to cause the remaining text to align on the tab stop which matches that margin. However, tab stops are not available in HTML/CSS. Therefore for more precise alignment of columns of text across a line, I use a table such as my Blank table format. Otherwise I determine a consistent set of outdent values based on my fonts as shown below to use for HTML outdent margins to match be equivalent to an FM tab stop. [See also the paragraph formats with outdent margins used for the special paragraphs in an Index.]

Determining the outdent value for formatting for these two types of paragraphs (Bullets and Numbers) takes multiple steps. Note, however, basing the outdent text and spacing to align with a single value of the indent for the following lines only works because these paragraph use exactly the same font family and font size as the “normal” paragraphs (e.g. Body) they are to align with. Since all my “normal” paragraphs use 12pt font the resulting value will work for all.

• I first create multiline FM examples of both types of paragraphs with trial separation space entities and convert them to HTML to view in my browser.

• I now manually modify the HTML text to insert different space entities (after the number and suffix, and around the bullet) until both types of paragraphs appear to begin their following text at the same (as close as possible) left margin. I now also experiment to determine what leading space entities, which would be used in HTML instead of a tab, will begin their following text at the same left margin.

• I now manually modify the CSS text-indent and margin-left values in rem units as needed for both paragraphs to align the first line with the normal left margin, but adjust the indented left margin of the following lines to match where the subsequent text on the first line now begins.

• Finally I convert the above determined rem values to compute the equivalent pt values needed to set the First and Left Indents in FM.

Following the above process, when all these paragraphs are using the main Serif font the following leading characters in the first line outdent for these two types of paragraphs produced an approximately equal width of 22.5pt/1.875rem in FM and HTML respectively.

Thus I base these sets of paragraphs’ parameters on this width to indent the main body of their text as required from the outdented first line. This 22.5pt amount of indent is now used as the offset for all FM tab stops in all normal 12pt paragraphs. For paragraphs using different font sizes I choose to have an equivalent indent which is proportional to the different font size.

While a common way in word processing software like FM to indent or align text within a line is with tabs, tab stops do not exist in CSS so some workaround equivalent is required. In HTML generally only relative alignment can be obtained by inserting some number of space characters to indent the beginning of a line, possibly following some leading text. FM’s conversion to HTML does provide a mechanism to always replace a given character, like the tab character, with some other fixed text. The first idea I had was to replace a tab with one or more HTML space entities. These spaces must be HTML entities and not actual space characters since HTML collapses multiple consecutive ordinary white space characters into a single space.

However, the width and height of any spaces inserted is not a fixed amount as it will be based on their font family and the default size and height of their HTML container, such as their containing paragraph or character format. Thus the same amount of the same spacing characters in two paragraphs with different font sizes would not align, and if the replacement character has a format with larger height it could even increase the line height. Even with these considerations the only special case where alignment might be achieved is initial replacement characters used to indent from the left margin of left alignment paragraphs with no leading text or intermediate text between such characters. To align groups of arbitrary characters across a line the only reliable way is to use columns in a table with left aligned table cell paragraphs. While my custom set of list paragraphs (List, ListNarrow, and ListWide) will align in HTML due to their conversion to custom Flex side-by-side tables and custom CSS, they will not align in FM without custom changes to the FM flow.

Fortunately my typical use of tabs is to emulate indenting the beginning of a short line to some tab stop. Typically this is used at the beginning of a paragraph which generally is not expected to wrap, unless an indented first line is desired, since any following lines will not align with the first line. This limited use does lend itself to converting the tab character to some fixed spacing entity with a width equal to the outdent value calculated above. This is further helped by my self-imposed restriction mentioned above to have the width of any indents or outdents in main paragraphs be based on a multiple of a consistent width. Thus I set any tab stops and left indents of FM paragraphs using 12pt font as multiples of 22.5pt. As long as I can replace the FM tab character to some non-visable HTML entity equal to this fixed width, the indent alignments in both FM and HTML will produce the same look.

Instead of converting the tab character to some number of defined HTML entities I convert it to the HTML text which will insert a gif image file! My actual image is a line only 8 pixels high and 100 pixels wide. However I now can use CSS to set the width to exactly 1.875em. This CSS variable “em” is the font size set for the containing element, e.g. the paragraph.

Font size	Font * Image	FM width
8 pt	8 * 1.875em	15 pt
9 pt	9 * 1.875em	16.875 pt
10 pt	10 * 1.875em	18.75 pt
11 pt	11 * 1.875em	20.635 pt
normal 12 pt	12 * 1.875em	22.5 pt
14 pt	14 * 1.875em	26.25 pt
16 pt	16 * 1.875em	30 pt
18 pt	18 * 1.875em	33.75 pt

Thus if the containing element is defined with a different font size, the image width will be proportionally larger or smaller due to that font size. Also with the image aligned to the text baseline its height is so small it will not affect the line height of any of my paragraphs. Finally by setting its CSS visibility to “hidden” the resultant HTML image will simply take up the desired fixed width without any visable output.

WARNING: The relative pathname to the image file in Common must be appropriately set as the last line in Reference Pages/Character Macros to find this file.

However, since this replacement is simply a fixed width image it will not produce alignment within a line. Converted leading images in HTML will align with indent or outdent offsets as long as the FM tab stops for those offsets are set to the same values the image will produce proportional to font size. Thus in both FM and HTML the text of a Body1 or Body1Sans paragraph with a leading FM tab character will now vertically align with the text following the outdent of a Bullet1 paragraph so long as that paragraph’s bullet and leading space add up to a tab/image width of 1.85em. It will also align with the beginning text of an Indent1 paragraph set to that offset of 1.85em for that font size:

The two Small paragraph formats and the Footnote paragraphs which all use 10pt font now will intentionally have smaller offset widths in both FM and HTML based on their font size and thus have only 18.75pt offsets. But within those set of paragraphs leading tabs/images will also align with indented paragraphs in the set. However if I want alignment between any of these small font paragraphs and standard paragraphs, different manual spacing produced by selected HTML spacing characters is required to account for their different font sizes. By observation the following manual spacing in a standard paragraph can produce an approximately equivalent indent to the smaller tab/image spacing in a smaller font paragraph:

Body1 with leading &emsp;&ensp; HTML characters which seems close enough
I am guessing I am unlikely to want to align such a standard narrative paragraph’s indent to a small font paragraph but at least this records here the manual spacing required. Alternatively I believe I am more likely to want to align a small font paragraph’s leading indent with a standard narrative indent, and the following space entities will do this:

See the detailed discussion about Endnotes which describes the contents of the Endnotes Section. Similar to the above Bullet and Number paragraph outdents, the set of paragraph formats used for footnotes have proportionally smaller outdent values since those paragraphs use a smaller font with smaller font width. The custom text which I use to automatically number a footnote is: “number, period, emspace”. (This intentionally matches the outdent numbering format of the main Number paragraphs but due to the smaller font size the total width is smaller.) If there are ten or more endnotes, then the leading outdent text with a number having two or more digits will obviously be wider. However I chose to fix the outdent based on the width resulting from using a single digit, which was observed to be the same as the width of a proportional converted tab (see above) in the font size of these a paragraphs: 1.875em*10pt = 18.75pt = 1.5625rem for FM and HTML. This defines the indented left margin of the endnote text. I then made a right indented margin for the entire paragraph using the same value, and set FM tab stops based on multiples of that “tab stop” value. This produces the desired basic left/right margins and tab stops for a footnote with an outdented first line.

With these final horizontal values based on multiples of the corresponding observed outdent width I now can set all the horizontal FM tab stops and margins, and CSS left margins, for all paragraphs. Thus a tab as the first character to indent the beginning of an FM main paragraph will produce the equivalent indent in the HTML. And multiple tab beginning a line will align with equivalent paragraphs indented with their left margins.

The first Footnote line is outdented. In the body it has no autonumbering so starts at the standard margin
Second forced line is at the subsequent indented margin, then

T one tab

T two tabs

This is a following IndentFoot paragraph

T with a forced line having one tab

T and two tabs

The first SubindentFoot line is outdented. It has no defined autonumber. A sufficient amount of text to wrap to the following line will be indented at the first tab stop of the IndentFoot paragraph.
A forced line is also indented at the first tab stop of the IndentFoot paragraph
Any additional tabs will NOT display the same in FM and CSS.

The first Small line starts at the standard margin,
as does the forced second line, then

T one tab

T two tabs

T three tabs

This is a following IndentFoot paragraph

T with a forced line having one tab

T and two tabs

Because the default font is variable spaced, any spacing between any characters beginning an outdent line and subsequent characters desired to align with standard indents will also have to be variable. Fortunately the visual spacing in FM and HTML are roughly equivalent so first attempts in FM will generally be close in HTML. The following are examples using a paragraph with the standard Serif font and demonstrate this variability problem. The usual indent tried after one character is &emsp;  which shows generally good but mixed results.

Since the first line of the SubindentFoot paragraph is also outdented, any spacing between any characters beginning its first line and subsequent characters will also require inserted spacing so that the beginning of those subsequent characters will align with the standard indent for continuation lines of this paragraph.

T IndentFoot paragraph left margin. All the remaining are SubindentFoot paragraphs.

This SubindentFoot paragraph uses a tab as the leading text to align with wrapped text in following lines for this paragraph
T and with forced contination paragraphs

FM defines two separate types of footnotes: footnotes within the text of the document, and footnotes within a table. Each uses a standard separate paragraph format name for the actual text of that footnote type: Footnote and TableFootnote. The actual paragraph format to be used for each can be changed in Format/Document/Footnote Properties but I choose to retain the defaults. In addition to different paragraph formats, the placement of the actual text of these two types of notes are handled very differently in FM versus their default conversion to HTML. In FM the text for a Footnote is placed at the end of the page on which it occurs, or overflowing to the next page if necessary; while the text for a TableFootnote is placed at the bottom immediately following their table. However by default in the converted HTML the text of both are grouped together and placed at the end of the web page as intermingled endnotes and numbered sequentially in the order they appear in the body. [Separate endnotes can be defined in FM and then cross references can be used to have citations to an endnote. Instead I choose to only use inserted footnotes in both text and tables as being easier and more consistent data entry, and let the HTML conversion automatically combine them as endnotes.]

Endnotes which came from a footnote in a table could be formatted differently than those from the main text since their HTML paragraph class names retain their separate FM paragraph format names. But since they are combined as intermingled endnotes, in both FM and HTML I choose to make the formatting for these two paragraph types identical. I also set FM’s “next paragraph” to IndentFoot for both types of footnote paragraph formats so that any following paragraphs as part of that same footnote text have this same fixed left margin as their common leading footnote paragraphs. The FM conversion encloses all these paragraphs within a single endnote of both types with a same named (case sensitive) HTML <DIV CLASS="footnote">. Thus in CSS one could use that common HTML class to force some common formatting for the two types of paragraphs. However neither the default stylesheet produced by FM’s conversion, nor my current custom CSS stylesheets, have any special CSS formatting for this separate DIV class.

FM automatically creates both the <a> hyperlink tag around the endnote marker in the text to be an HREF link to the unique paragraph name of the endnote, and the <a> hyperlink tag named its paragraph name as the target within the endnote text. As noted below I also programmed my Perl script to create a hyperlink around the marker number beginning the endnote to jump back to a target link named FNum-nnn at its companion marker number nnn in the text.

For either the in-line footnote marker number or the endnote number the CSS pseudo class “target” can introduce a temporary red icon to flag the inline target marker, or can flag the endnote number and highlight the endnote’s background as an aid to find the target in the display among the surrounding text.

When the target is an endnote I only flag and highlight if there are so many endnotes that I created a scrolling table to contain them all. The flag is the icon ⏩︎ which points to the following text, and the highlight color is the CSS variable FootnoteTargetColor which is set to #FFDAB9 (standard name “PeachPuff”) to contrast with my personal background color. (The CSS selector A:target::before used below inserts the content just after the endnote number but before the endnote’s text. The CSS selector div.footnote:has(A:target) uses the very new relational pseudo-class “:has()” to highlight the background color of all the content of the single div.footnote which contains (has) the current hyperlinked target. (The background-color chosen (#FFDAB9; called “PeachPuff”) provides a contrast to my web page background color.) Older browser versions should simply ignore this construct and thus do no full text highlighting.)

For the back link to the in-line target marker in the main text only the temporary icon ⯅ is inserted to point upwards to the superscript marker number itself. (The CSS qualified selector A[name|="FNum"] used below matches any hyperlink anchor element whose name value begins with “FNum–”. Note the hyphen suffix automatically included by CSS which is part of FM’s automatic footnote/endnote numbering, which is why I use this CSS structure.)

What is used for the numbering style (numbers, letters, special characters, etc.) of FM footnote in-line markers for either regular footnotes or table footnotes can be different between the two and can be changed in FM in Format/Document/Numbering Properties. For FM output I choose to retain its default of arabic numbers for a Footnote and lowercase letters for a TableFootnote. WARNING: Whatever the numbering styles chosen in this way for FM TableFootnote markers does not appear in HTML. Since both types of footnotes upon conversion will be intermingled as HTML endnotes, the numbering style of these converted markers for both types will use whatever is the defined Footnote marker numbering style.

There appears to be no separate formatting font/style options in FM for either type of the marker numbering characters themselves. For either type in FM they always occur in the font of the paragraph in which they occur. However the actual formatting of each can have separate styling in HTML as their converted output uses separate HTML elements and class names. The <A> hyperlink element with class="footnote" defines the styling of the in-line marker within the body/table which it encloses (which is an FM character format not defined in the Character Catalog). The companion numbering beginning that endnote text is instead enclosed in a <SPAN> element with class="footnoteNumber" (which is another FM character format also not defined in the Character Catalog). Since they are separately identifiable in HTML they could be separately styled using CSS.

Since FM permits the insertion of multiple consecutive in-line footnotes, the Perl script also automatically separates such consecutive markers in the HTML body with commas, a feature not automatically provided by FM. (A superscript comma can be manually inserted between two consecutive markers in the text, but since my output is intended to be HTML I find it easier to let my Perl script [remember to] do this automatically.) In addition the script inserts a target <a> hyperlink named FNUM-nnn before each footnote’s marker structure where nnn is this unique marker number. This provides a target for the hyperlink created around the number beginning the endnote text to use to jump back to this point in the main text.

My CSS styling includes the element A.footnote when setting the default for multiple elements to the Sans-Serif font to have a contrast with the default Serif text for most paragraphs. As shown below I also separately set its font-size at the fraction 0.75em of the size of the containing paragraph font. Although FM’s default Footnote Properties sets the in-line footnote reference markers in the FM main body to superscript, FM’s conversion doesn't set superscript in the converted HTML so the below CSS adds the vertical formatting. In both FM and HTML the paragraph line-height can be affected by superscripts for footnotes. (See also a more complete discussion of paragraph line height.) I retain FM’s default Footnote Properties formatting which increases the line-height in the FM document. However I also choose to have special CSS styling shown below to prevent footnote markers from affecting the line-height in HTML.

Like setting the paragraph format to be use as described above, the FM format of the marker beginning the footnote/endnote paragraph can be changed in Format/Document/Footnote Properties. The default defines no prefix but does define a suffix for both footnotes of only a period followed by a normal space. Instead I choose to define the FM suffix with a trailing non-breaking larger em space (\sm) for both footnotes to provide wider separation. As part of the HTML conversion FM adds the suffix period to the marker at the beginning of the endnote, but does not append any type of space. Therefore my Perl script adds the HTML em space (&emsp;) back in to match FM. Further my Perl script also surrounds the marker number in the endnote with an HREF hyperlink back to the hyperlink named FNum-nnn in the document which is the companion nnn footnote marker number in the text. I find this reverse linkage extremely useful when browsing a page with many endnotes. (This hyperlink encloses the suffix period but not the separator space.)

I also choose to outdent the first line of the paragraph of either type of footnote as described in the separate section below to make it easier to identify the beginning of each footnote in a list. In both FM and HTML the fixed left margin following the outdent in the automatic first paragraph of a footnote, and the fixed left margin of any subsequent paragraphs in the footnote is based on the footnoteNumber contents and properties described above. (See the separate description about determining this required footnote fixed outdent amount.) This fixed subsequent left margin can be observed in this example endnote 16 in this sentence since it is after a sufficient number of other endnotes in this document to require a two digit number, and has both overflow lines and a subsequent paragraph. For FM tab stops following the first indent I use the 18.75pt width based on the conversion of a tab when in a paragraph with 10pt font, as noted in the discussion about tabs.

As mentioned above the endnote number begining the endnote is enclosed in a SPAN element with class="footnoteNumber". In order for this number to match the marker font within the main text, my CSS styling includes the HTML element SPAN.footnoteNumber when setting the default for multiple elements to the Sans-Serif font. I also set the endnote number to a slightly smaller font size than the paragraph’s font (0.8333rem), which is required due to this Sans-Serif font being slightly larger.

As repeatedly noted above, the HTML conversion combines both types of footnotes as endnotes. My Perl script automatically adds a heading in the HTML to that set of endnotes. If the heading will be part of a table it will use the pargraph format “Title” with character format “bold”, otherwise it will use the paragraph format “DefTerm”. If I have “enough” endnotes I will often add an entry linking to this heading in that page’s table of contents at the beginning of the document. I use an FM “Jump to Named Destination” hypertext link with the name “Endnotes” which I reserve for this use. The Perl script will note the presence of this named hypertext link and add the corresponding named anchor as a target on the heading. Finally, if there are a significant number of endnotes (currently set at 10 or more) the script will bracket all of them within a predefined HTML div with a Class named “footnotes” and add the HTML code for a scrolling table of Class “basicT” with a single data row and column containing all endnotes.

The paragraph margins in both FM and CSS are set using three types of parameters. However FM and CSS use different variables, and FM has an additional fourth available type of parameter. In addition FM values are usually set in pts, where in CSS I usually use rem.

• Indent: left margins of the paragraph’s first and subsequent lines, & right margin

FM: Size, Family, Weight, Angle, Variation, Underline, Overline, Strikethrough, Stretch

• and FM tabs: offsets from left margins, and alignment (e.g. left, right, center)

In CSS to be Responsive I use the rem unit, which is normally the browser’s default character font size.17 Most browsers default one rem to a value typically equivalent to 16px, or 12pt, and the latter is the standard text pt size I use in FM. Thus I use the conversion of (pts/12=rems) to set the values from the FM pts value to the equivalent CSS rem browser (or em paragraph) values.

The Indent values for horizontal left margin alignment of text uses “first” and “left” value which are measured from the same text flow left margin, but are set differently in FM and CSS. To set the FM first and subsequent line indents the same, set the “first” indent value identical to the “left” indent value. To have a hanging outdent set “first” to zero and “left” to a positive value, and to indent it set “first” to a positive value and “left” to zero. In contrast to FM’s “Indent: first”, the CSS “text-indent” for the first line is instead measured from the “margin-left” value used for the rest of the paragraph. So to set the HTML first line the same as the subsequent line indents of this paragraph, simply set the “text-indent” value to zero. To have a hanging outdent for the first line set it to a negative value, and to indent it set it positive.

The vertical Space values for all paragraphs, except for a few special cases, are defined with zero space below. (See also the separate discussion about line height in the Table and Paragraph Vertical Alignment section.) Thus most spacing between paragraphs is controlled solely by the space above. The internal vertical line spacing is set in FM by the paragraph’s Line Space value which will affect the default/minimum single line spacing. While this value can be “fixed” I typically do not mark that as this is difficult to accomplish in CSS. The top and bottom CSS space margins are set to match the FM space above and below which define the spacing between paragraphs. Most CSS sets “line-height” to the default of “normal”. Often it is recommended to be a fixed unitless number (equivalent to using the unit em) which is a multiplier on the paragraph’s font size rather than a fixed height. Thus the discussion of line height mentioned above includes defining a custom CSS variable --base-line-height based on the unit em. Further, for Responsive display I use @media commands and modify the variable’s value based on screen size. So not only will the line height vary with font size, it also varies with the amount of screen real estate.

As noted above the FM paragraph formats cannot override the CSS table setting of the vertical position of the paragraphs within a table’s cells. To have the FM tables “look” like how they will appear in HTML, one must select FM paragraphs whose Cell Vertical Alignment setting match the vertical alignment imposed by that CSS table format. Several paragraph format names are constructed from two alignment values: its FM (only) vertical alignment, then its horizontal alignment (e.g. BotRight). Their other settings generally match those of “Singleline”. The default alignment of any other paragraphs is set to top/left.

My paragraph format names can have a suffix of ‘1’, or a suffix of ‘L’. A suffix of ‘1’ usually imples a zero top alignment, except for the “number” formats which instead imply initializing the paragraph numbering to ‘1’ but have full line spacing. A suffix of ‘L’ implies full line spacing above, and in the case of “number” formats defaults the “next” paragraph to itself. Otherwise both “suffix” formats set the “Next Paragraph Tag” to the same name without the suffix which has a non-zero but half-line spacing at the top.

“Sub” paragraph formats generally have tighter line spacing than their non-Sub equivalents.

Within the notation for any given set of formatting values, a vertical bar ‘|’ indicates FM values first followed by CSS values. Since they are only specified if different than default, the five possible assignments begin with a unique code to make searching for such assignments easier.

For those few paragraph formats whose Alignment|text-align settings are not left, and/or have a leading FM autonumber, that formatting is described first immediately following the format name.

Default for FM indent is 0/0/0, so the default for CSS also is 0/0/0. I only specify non-default indent values, but if indenting exists it will be specified beginning with the text “(Indent:”.

Next can come numbers beginning with the text “[space:” which define spacing above, spacing below, and line space. FM numbers are pt values. While paragraphs often have some spacing above, except in a few cases they have zero spacing below with most inter-paragraph spacing determined by the following paragraph’s spacing above. In the CSS line-height value the abbreviated text “--base” refers to setting it to my custom CSS variable “--base-line-height”, possibly preceded by a multiplier, as discussed above. As these values vary I do not define a default and specify “space” for all paragraphs.

Next will be any FM tab stop values beginning with the text “(tab:”. FM has the defaults of normal horizontal left margins for that type of paragraph whatever is available beyond its left margin. As noted above there is no equivalent to tab stops in CSS. As a memory aid (only) for setting FM paragraph formats I always specify the tab stops or “no tabs”.

Finally font size and/or font family and possibly any font decorations for that paragraph will follow the text “[font:”. As with most other formatting values they are only specified if any of these are different than the defaults, which are:
[font: 12 pt, New Century Schoolbook, Regular | 1.0rem, New Century Schoolbook-local, normal].

My naming scheme 18 has all paragraph format names begin with an uppercase character.

This is a Body para, [space: 14, 0, 15.6 | 1.1667rem, 0, --base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
The Body paragraph and the Body1 paragraph (below) are used for most narrative text.19

T one tab

T two tabs

T three tabs

T four tabs

This is a BodySans para, [space: 14, 0, 15.6 | 1.1667rem, 0. --base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
with altered vertical alignment, with “Next Paragraph Tag” of the normal Body.
Identical to a Body paragraph but with this different font.
This paragraph is generally used for contrast to the default Body paragraph, and where I wish to be able to apply alternative character formats to the paragraph’s overall Sans-Serif characters
Can be used as the Level 4 heading below Major, Minor and Topic as contrast to following paragraphs in Serif.

T one tab

T two tabs

T three tabs

T four tabs

This is a Body1 para, [space: 0, 0, 15.6 | 0, 0, --base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
with “Next Paragraph Tag” of Body
used for the first narrative paragraph after a heading whenever no space above is desired

T one tab

T two tabs

T three tabs

T four tabs

This is a Body1Sans para, [space: 0, 0, 15.6 | 0, 0, --base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
with altered vertical alignment, with “Next Paragraph Tag” of the normal Body.
Identical to a Body1 paragraph but with this different font.
Used for a first contrast narrative paragraph after a heading whenever no space above is desired.

This is a BotCtr para
Alignment: Center | center, [space: 0, 0, 14.04 | 0, 0, 0.9--base] (no tabs)
for use in ‘B’ table cells with bottom vertical alignment
All paragraphs intended for table cells have smaller line height

This is a BotCtrSans para
Alignment: Center | center, [space: 0, 0, 14.04 | 0, 0, 0.9--base]

(no tabs) [font: FreeSans | FreeSans-local]
for use in ‘B’ table cells with bottom vertical alignment

This is a BotIndent para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0)
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (tab: 45pt L, 67.5pt L, 90pt L)
for use in ‘B’ table cells with bottom vertical alignment

This is a BotIndentSans para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0)
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (tab: 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
for use in ‘B’ table cells with bottom vertical alignment

This is a BotLeft para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
for use in ‘B’ table cells with bottom vertical alignment

This is a BotLeftSans para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
for use in ‘B’ table cells with bottom vertical alignment

This is a BotRight para, Alignment: Right | right,
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (no tabs)
for use in ‘B’ table cells with bottom vertical alignment

This is a BotRightSans para, Alignment: Right | right,
[space: 0, 0, 14.04 | 0, 0, 0.9--base]
(no tabs) [font: FreeSans | FreeSans-local]
for use in ‘B’ table cells with bottom vertical alignment

This is a Body para for comparison to the Bullet paragraphs. See the discussion concerning paragraphs with an outdent such as these bulleted paragraphs.

T one tab

• This is a Bullet para, Autonumbered= [\ •\sm]
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0)
[space: 7, 0, 15.6 | 0.5834rem, 0, --base]
(tab: 45pt L, 67.5pt L, 90pt L)
with paragraph text set equivalent to the first indent stop
and is used for interior paragraphs in unnumbered hanging bulleted lists,
whenever only half-space above is desired.

T one tab

T two tabs

T three tabs

• This is a Bullet1 para, Autonumbered= [\ •\sm]
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base]
(tab: 45pt L, 67.5pt L, 90pt L)
paragraph text set equivalent to the first indent stop
typically used for the first bulleted paragraph following a heading,
or whenever no space above is desired.
with “Next Paragraph Tag” of Bullet

T one tab

T two tabs

T three tabs

• This is a BulletL para, Autonumbered= [\ •\sm]
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0)
[space: 14, 0, 15.6 | 1.1667rem, 0, --base]
(tab: 45pt L, 67.5pt L, 90pt L)
with paragraph text set equivalent to the first indent stop
typically used for the first bulleted paragraph following another paragraph,
or whenever full line space above is desired.
with “Next Paragraph Tag” of Bullet

T one tab

T two tabs

T three tabs

This is a Computer para, (Indent: 45pt, 45pt, 0 | 0, 3.75rem, 0),
[space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 67.5pt L, 90pt L)
[font: Inconsolata SemiBold, DemiBold, Stretch: 125% | Inconsolata-w-local, 600, Download width: 125%]

with semibold monospace text,
left indented set equivalent to the normal second indent stop,
with computed reduced Line Space
Usually used for computer data to be entered
The font and its specific fallback families include some,
but not all, symbols/emojis within the UBMP

If symbols/emojis are necessary instead use this MonoSans paragraph format whose monospaced characters should closely align

WIWIWIWIWIWIWIWIWIWIWIW MonoSans

┞┭┵╁║╱▆ ▏▐▓▕■□▲▶▷▼◀◆◉

WIWIWIWIWIWIWIWIWIWIWIW Computer
┞┭┵╁║╱▆ ▏▐▓▕■□▲▶▷▼◀◆◉

The following set of “definition” paragraph formats are designed to occur in the following (non-alphabetical) sequence. All “See” paragraphs have a small space below for extra separation from the following paragraph and italic text for comments or cross-references with no tab stops. [See also the similar Index “See” paragraph formats.]

This is a DefHead para,
[space: 14, 0, 18.2 | 1.1667rem, 0, --base] (no tabs)
[font: 14pt, FreeSans, DemiBold, Underline | 1.1667rem, FreeSans-local, bold, underline]
intended above a collection of DefTerm/Definition paragraph pairs
with “Next Paragraph Tag” of DefTerm, and “Keep With Next Paragraph”
Similar to the Minor paragraph but with less line height
no tabs since the tab space would be underlined

This is a DefHeadSee para
(Indent: 10pt, 10pt, 0 | 0, 0.8333rem, 0), [space: 0, 3, 15.6 | 0, 0.25rem, --base]
(no tabs) [font: Italic | italic]
with “Next Paragraph Tag” of DefTerm, and “Keep With Previous Paragraph”
indented <half indent stop under DefHead, with small spacing below.
For comments on this set of definitions or (see also …) other sets of definitions

This is a Definition para
(Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0), [space: 0, 0, 15.6 | 0, 0, --base]
(tab: 45pt L, 67.5pt L, 90pt L)
with “Next Paragraph Tag” of DefTerm
This uses the standard first level of indentation, such as in the paragraph Indent

T one tab

T two tabs

This is a DefinitionSee para
(Indent: 32.5pt, 32.5pt, 0 | 0, 2.7083rem, 0), [space: 0, 3, 15.6 | 0, 0.25rem, --base]
(no tabs) [font: Italic | italic]
with “Next Paragraph Tag” of DefTerm,
indented <half indent stop under Definition, with small spacing below.
For comments on this one definition or (see also …) of similar definitions

This is a DefTerm para, [space: 0, 0, 15.6 | 0, 0, --base] [font: Bold | bold]
with “Next Paragraph Tag” of Definition, and “Keep With Next Paragraph”
It also can be considered a Level ‘2A’ para between Minor and Topic

T one tab

T two tabs

T three tabs

T four tabs

This is a DefTermSee para
(Indent: 10pt, 10pt, 0 | 0, 0.8333rem, 0), [space: 0, 3, 15.6 | 0, 0.25rem, --base]
(no tabs) [font: Italic | italic]
with “Next Paragraph Tag” of Definition, and “Keep With Previous Paragraph”
indented <half indent stop under DefTerm to be more than DefHeadSee,
with small spacing below.
For comments on this one term or (see also …) of similar terms

(EQ 1)

This is an Equation para
Alignment: Center | center, Autonumbered= E:(EQ <n+>)\sm\sm
[space: 10, 10, 11.7 | 0.8333rem, 0.8333rem, 0.9--base]
(no tabs) [font: 10pt, Noto Sans Mono | 0.8334rem, Noto Sans Mono-local]
While the Autonumber can be set to the character format EqNum
neither the name nor presence of that format is output to HTML
It has space above and below for offset.

(tab: 52.8 L, 105.6 L, 158.4 L)
[font: 11pt, Courier Prime | 0.9167rem, Courier Prime-local]

my monospaced serif font

In Notepad and most email programs using plain text a tab is eight 11pt monospace characters wide or 52.8pt
1234567812345678123456781

This Body paragraph defines a Flex paragraph
(Indent: 0, 0, 0 | 0, 0, 0), [space: 0, 0, 0 | 0, 0, 0] (no tabs) [font: 8pt, Light Salmon | ]
This format is required to be used as a pair of paragraphs which contain no text: the first will only contain the anchors for two or more narrow tables intended to be displayed side by side, and the immediately following second Flex paragraph must remain completely empty. These paragraphs generate no height or space. However to be able to see these paragraphs in FM I define it with 8pt Light Salmon text. Upon conversion a pair of consecutive Flex paragraphs will be enclosed in a “parent” HTML “Flex” Section entity due to the XML Element code in the Reference Pages HTML Mapping Section described above. For an example see the two Blank formatted tables below.

While there “should” be a second Flex paragraph to make a pair, any subsequent paragraph without a “Flex” Parent element will end the enclosing parent Section. (See also the List paragraph.) The CSS for a Flex paragraph produces no text output or vertical spacing with zero height text and line. The separate CSS for the Flex Section defines a container where the contained children, e.g. the two or more narrow tables, will abut side by side if they can fit in the browser window. If the window is too narrow (e.g. a mobile device) any child element/table which can not abut with the previous element(s) in this container will display below the previous.

For more about Footnotes see above for a discussion of the formatting of footnote paragraphs and footnote markerss, and about the HTML conversion of footnotes to Endnotes and the formatting of that separate section.

1. This is a Footnote para, (used within the body of the document)
Alignment: Left | left, (Indent: 0, 18.75pt, 18.75pt | -1.5625rem, 1.5625rem, 1.4rem),
[space: 0, 0, 11.7 | 0, 0, 0.9--base] (tab: 37.5pt L, 56.25pt L, 75pt L), [font: 10pt | 0.8334rem]
and has “Next Paragraph Tag” set to IndentFoot.
Although left alignment is my default for paragraphs, it is mentioned here because it is not the normal FM default of “Justified” for footnotes,
Note that in FM both right and left margins are equally indented and with an outdent first line for the footnote number. However since most lines of non-aligned text will not reach the right margin, I find the same margin as the left is too generous in an HTML scrolling table, so have reduced it to 1.4rem.
A leading single digit with a trailing period and emspace in this Footnote paragraph font in the body displays the same in both FM and HTML except for the font of the number.
See the discussion about tabs explaining the proportionately smaller tab stops due to the smaller font size.

T one tab

T two tabs

T three tabs

1. Test with a number, period and em space set to the font sans to match the uncatalogued footnoteNumber style which is the Class produced in the converted HTML for the footnote marker and able to be defined in CSS. Note that the first line text does align with subsequent lines when used in FM and works in HTML even though they have different methods of specifying outdents.

Test using a Footnote para without a number but with em space, en space, nbsp in the default font. This is just what a tab will be, but cannot use a tab in FM on the first line of a Footnote paragraph in the main text to get to that margin as an extra tab stop at the left margin would make entering tabs in this paragraph format inconsistent when entered in the text versus as a true footnote. This is another reason I defined the IndentFoot format. I make this test paragraph long enough so that I am sure that it extends to multiple lines.

Test with an IndentFoot para for comparison to align the text as a subsequent continuation paragraph after a Footnote paragraph but without the inconsistent outdent first line as described above.

This continuation IndentFoot paragraph contains a footnote 20 for an example of no line-height change within an HTML line of text (where space is left in FM) as a result of a true footnote within a paragraph.

This is a Halfline para, [space: 7, 0, 15.6 | 0.5834rem, 0, --base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
with about half line spacing above and none below,
often used for spaced unmarked lists, or a continuing paragraph following an inserted Quotation paragraph, or to have a half spacing with a blank paragraph containing only a non-breaking space character.

T one tab

T two tabs

T three tabs

T four tabs

This is a HeadFoot para
Alignment: Center, | center [space: 0, 0, 15.6 | 0, 0, --base] (no tabs)
used in table header and footer cells

This is an Indent para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0),
[space: 7, 0, 15.6 | 0.5834rem, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
with text indented set equivalent to the normal first indent stop, half space above,
and is used for interior indented paragraphs, or continuing bulleted or numbered lists,
or whenever only half-space above is desired.
with examples of other paras above and below showing matching alignment

T one tab

T two tabs

T three tabs

This is an IndentSans para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0),
[space: 7, 0, 15.6 | 0.5834rem, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
[font: FreeSans | FreeSans-local]
with altered vertical alignment, with “Next Paragraph Tag” of the normal Indent.
Identical to an Indent paragraph but with this different font,
with text indented set equivalent to the normal first indent stop, half space above,
and is used for contrasting interior indented paragraphs, or within bulleted or numbered lists

T one tab

T two tabs

T three tabs

This is an Indent1 para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0),
[space: 0, 0, 15.6 | 0, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
with text indented set equivalent to the normal first indent stop, no space above,
used for the first para in a set of indented paragraphs following a heading,
or continuing a main bulleted or numbered paragraph,
whenever no space above is desired,
with examples of other paras above and below showing matching alignment
with “Next Paragraph Tag” of Indent

T one tab

T two tabs

T three tabs

This is an Indent1Sans para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0),
[space: 0, 0, 15.6 | 0, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
[font: FreeSans | FreeSans-local]
with altered vertical alignment, with “Next Paragraph Tag” of the normal Indent.
Identical to an Indent1 paragraph but with this different font,
with text indented set equivalent to the normal first indent stop, no space above,
and is used for contrasting interior indented paragraphs, or within bulleted or numbered lists

T one tab

T two tabs

T three tabs

This is an IndentFoot para (in the Body)
(Indent: 18.75pt, 18.75pt, 18.75pt | 0, 1.5625rem, 1.4rem),
[space: 0, 0, 11.7 | 0, 0, 0.9--base], (tab: 37.5pt L, 56.25pt L, 75pt L), [font: 10pt | 0.8333rem]
with both margins indented and left justify
Although left alignment is my default for all paragraphs, it is mentioned here because it is not the normal FM default for footnotes which is “Justified”.
Since most lines of non-aligned text will not reach the right margin, I find the same margin as the left is too generous in an HTML scrolling table, so have reduced it to 1.4rem.
It’s margins are formatted in both FM and CSS to align as a subsequent continuation paragraph after a Footnote or TableFootnote paragraph but without the outdent first line as described for those paragraphs. For a small font paragraph with the left margin to align with normal paragraphs see IndentSm..
See the discussion about tabs explaining the proportionately smaller tab stops due to the smaller font size.

T one tab

T two tabs

T three tabs

This is an IndentFoot with a continuation line

T having one tab with a following SubindentFoot for comparison

a. T SubindentFoot with outdent first line and emspace
T with a continuation line

This is an IndentFoot with a continuation line

T having one tab with a following SubindentFoot for comparison

This is an IndentL para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0),
[space: 14, 0, 15.6 | 1.1667rem, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
with text indented set equivalent to the normal first indent stop, full space above
used for the first para in a set of indented paragraphs following a heading,
or continuing a main bulleted or numbered paragraph, or
whenever full line space above is desired,
with examples of other paras above and below showing matching alignment
with “Next Paragraph Tag” of Indent

T one tab

T two tabs

T three tabs

• This is a Bullet paragraph which can relate to Indent paragraphs for comparison to show text alignment

This is Singleline para with only a leading tab for comparison in FM, which works in FM and is close in HTML, but any overflow lines are not indented.

T This is Singleline para with one letter then emspace+enspace for comparison, which is also close but overflows

This is an IndentSm para, (Indent: 22.5pt,22.5pt, 0 | 0, 1.875rem, 0),
[space: 0, 0, 11.7 | 0, 0, 0.9--base] (tab: 37.5pt L, 56.25pt L, 75pt L)
[font: 10pt | 0.8333rem].

It’s margins are formatted in both FM and CSS like the Small* paragraphs to align as a subsequent continuation paragraph after normal paragraphs. For a small font paragraph with the margins to align with footnote paragraphs see IndentFoot.
See the discussion about tabs explaining the proportionately smaller tab stops due to the smaller font size.

T one tab

T two tabs

T three tabs

T four tabs

See the Index discussion below about creating a separate web page which is an Index to an entire collection of web pages. It contains two special character formats and several special paragraph formats only used in an Index for the index entries themselves, as well as for the navigation aid of an alphabet jumpbar, and for the target divider at the begining of each letter’s entries.

The following describes List, ListNarrow, and ListWide paragraphs
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0)
[space: 0, 0, 12 | 0, 0, 0.9--base] (tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
which are formatted with lessened line height and as indented paragraphs with the first line outdented. (See also the general discussion of outdent paragraphs.) As indicated in the description of Side by Side elements, a set of consecutive List (ListNarrow/ListWide) paragraphs will be enclosed in a named “parent” HTML Section entity. Each paragraph in succession goes down the first column and then down the second, etc., left to right, for as many columns as will fit in the width of the browser. As the screen width narrows the number of columns reduces while they get longer. The current use of this paragraph type is intended for a list of terms, numbered phrases, or limited lines.

As mentioned in that above description of Side by Side elements, in FM such columns cannot be created automatically. While this is a handy responsive feature in HTML, one must manually split the FM text flow containing these paragraphs and manually define that containing flow as connected multicolumns to provide the approximately equivalent appearance on a printed page. As a result I seldom use either the List or ListNarrow paragraphs for an FM document I expect to print.

Due to my regular use of these paragraphs in HTML documents, I specify an outdent width to match the converted width of a tab to be consistent with all other outdent paragraphs using the main Serif font. Thus the same spacing for leading outdent characters will work in these paragraphs as for normal paragraphs. Since it matches the converted width of a tab, any of these List paragraphs can appear as a continuation paragraph by beginning the first line with a tab. Thus normal tab stops of a Body paragraph are specified for FM.

The CSS and FM formatting of all the paragraphs List, ListNarrow, and ListWide are identical. The only difference is the CLASS name of the Parent Section defined on the Reference pages for these paragraphs. It is the different CSS definition of the “parent” which restricts these columns to an appropriate value. For List this parent is ListSec for columns of 12em wide. Note that the outdented first line text can be preceded by values to make it “look” like a bulleted or numbered list.

The following ListNarrow paragraphs have the same formatting as List
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0)
[space: 0, 0, 12 | 0, 0, 0.9--base] (tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
As indicated in the description of Side by Side elements, a set of consecutive ListNarrow paragraphs will be enclosed in a named “parent” HTML Section entity. The CSS and FM formatting of the paragraphs List, ListNarrow, and ListWide are identical. It is the different CSS definition of the “parent” which restricts these columns to an appropriate value. For ListNarrow this parent is ListSecNarrow for columns of 7.9em wide.

The following ListWide paragraphs have the same formatting as List
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0)
[space: 0, 0, 12 | 0, 0, 0.9--base] (tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
As indicated in the description of Side by Side elements, a set of consecutive ListWide (or List) paragraphs will be enclosed in a named “parent” HTML Section entity. The CSS and FM formatting of the paragraphs List, ListNarrow, and ListWide are identical. It is the different CSS definition of the “parent” which restricts these columns to an appropriate value. For ListWide this parent is ListSecWide for columns of 22em wide, which generally gives two columns on a monitor or wider screen.

While all of these paragraphs define an identical width outdent allowing numbering the lines in either paragraph, generally this paragraph consists of short terms or phrases immediately starting the first line with no separate outdented text. However if there needs to be more text on a given line and the line wraps, each line will be visually distinct due to the wrapped text being indented. As this outdent width matches the converted width of a tab, tab stops are defined in FM for these paragraphs.

This is a Major para, Alignment: Center | center
[space: 21, 14, 21.06 | 1.75rem, 1.1667rem, 0.9--base],
(no tabs),
[font: 18pt, FreeSans, DemiBold
| 1.50rem, FreeSans-local, bold]
with “Next Paragraph Tag” of Body1,
and “Keep With Next Paragraph”
and is the Level 1 heading.

This is a Mapping Table Cell para, Alignment: Justified I justify,
[space: 0, 0, 14.04 | 0, 0, 0.9--base]. (no tabs), [font: FreeSans | FreeSans-local]
It is only used in the FM Reference Pages. I “never?” use this for text which will be output, although it has a CSS paragraph definition similar to Body1 but with less line height. (Its automatic paragraph catalog name is converted by FM to an HTML CLASS name of Mapping-Table-Cell since CLASS names cannot contain spaces.) It uses the FreeSans font so the temporary Cyrillic characters I use which will be converted to special HTML codes by the FM Reference Pages Character Macros will actually display in FM in that macro table

This is a Mapping Table Title para,
[space: 0, 0, 21.06 | 0, 0, 0.9--base] (no tabs) [font: 18pt]
This format is only used in the FM Reference Pages as a table title and seldom for text which will be output,
but I have used it for a large para font which is able to be colored
(its automatic paragraph catalog name is converted by FM to an HTML CLASS name of Mapping-Table-Title since CLASS names cannot contain spaces)

This is a MidCtr para, Alignment: Center | center
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (no tabs)
for use in ‘M’ table cells with middle vertical alignment

This is a MidCtrSans para, Alignment: Center | center
[space: 0, 0, 14.04 | 0, 0, 0.9--base]
(no tabs) [font: FreeSans | FreeSans-local]
for use in ‘M’ table cells with middle vertical alignment

This is a MidIndent para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0),
[space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 45pt L, 67.5pt L, 90pt L)
for use in ‘M’ table cells with middle vertical alignment

This is a MidIndentSans para, (Indent: 22.5pt, 22.5pt, 0 | 0, 1.875rem, 0),
[space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
for use in ‘M’ table cells with middle vertical alignment

This is a MidLeft para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
for use in ‘M’ table cells with middle vertical alignment

This is a MidLeftSans para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
for use in ‘M’ table cells with middle vertical alignment

This is a MidRight para, Alignment: Right | right,
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (no tabs)
for use in ‘M’ table cells with middle vertical alignment

This is a MidRightSans para, Alignment: Right | right,
[space: 0, 0, 14.04 | 0, 0, 0.9--base]

(no tabs) [font: FreeSans | FreeSans-local]
for use in ‘M’ table cells with middle vertical alignment

This is a Minor para
[space: 18, 0, 18.2 | 1.50rem, 0, --base] (no tabs)
[14pt, FreeSans, DemiBold, Underline | 1.1667rem, FreeSans, bold, underline]
with “Next Paragraph Tag” of Body1, and “Keep With Next Paragraph”
and is the Level 2 heading, no tabs since the tab space would be underlined

The following two Monospace paragraph formats I defined (along with Computer which also is monospaced) are primarily used for special purposes when the characters in paragraphs of multiple lines of text must align horizontally. Because both their default fonts are special there is no paragraph format ‘Mono’ as that name might imply it used the default serif font. (See also the companion computer, monoSans and monoSerif character formats.) For example I can create descendancy charts using Unicode box drawing special characters which require a monospace font. However that use requires a font family which contains these non-text characters in both FM and HTML. Unfortunately in FM the MonoSerif format’s font family does not contain such non-text characters, but the MonoSans format does. Perversely (only) in FM the MonoSans font family does not contain them, but MonoSerif does. With CSS either the primary family or a specified fallback family contains the characters desired so whether or not they are in the primary doesn’t matter. While all these mono fonts will display these symbols in HTML, if I want them (also) visible in FM, then using the monoSans character format in a MonoSerif paragraph will display those special characters in both output forms. Since the following are paragraph formats their monospace text also can be decorated with other character override formats such as bold (or monoSans). (Note that the computer font format is always bold so that override has no effect.)

All the monospaced paragraphs below are 12pt in FM and 1.0rem in CSS. While FM requires a stretch value for their font widths to align horizontally as shown below, the rem value in CSS ensures their equivalent width. All FM Line Space values are 14.04pt so multiple lines look vertically the same. However CSS line space is based on the em font width value of the current font using the global CSS variable --base-line-height. Since these three font families have different widths their line-height setting must use different multipliers for the lines to align vertically. The examples below all align with the 45pt (3.7rem) indent of Computer in both FM and HTML by using two of the specially converted leading tabs on the non-Computer paragraphs.

This is a MonoSans para, [space: 0, 0, 14.04 | 0, 0, 0.886--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
[font: 12pt, Noto Sans Mono, Stretch: 104.7% | 1.0rem, Noto Sans Mono-local & FreeMono-local]
with no spacing above or below.
Its full-size (12pt) monospace sans font has smaller uppercase but since it has larger lowercase letters than the default paragraph font its overall look is slightly larger but its separate imposed stretch value ensures it aligns horizontally with Computer. (See also the monospace paragraphs overall discussion above.) Its line space is set slightly less to give good inter-line spacing. While its font height is slightly larger than the other chosen mono fonts with its smaller line height value it aligns vertically reasonably well. Most box drawing and other special characters exist in HTML between these two font families and align monospaced:

WIWIWIWIWIWIWIWIWIWIW
┞┭┵╁║╱▆ ▏▐▓▕■□▲▶▷▼◀◆◉

This is a MonoSerif para [space: 0, 0, 14.04 | 0, 0, 0.906--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
[font: 12pt, Courier Prime, Stretch: 104.2% | 1.0rem, Courier Prime-local]

similar to SingleLine and Computer, no spacing above or below.
Its full-size (12pt) monospace serif font has smaller uppercase but since it has larger lowercase letters than the default paragraph font its line space can be slightly more than Computer and give good vertical alighment. Its normal weight is very light, which along with its monospace font can be used for various forms of contrast. Its predefined font width is “slightly” narrower than the other fonts I use, but with its separate imposed stretch value it aligns well horizontally. (See also the monospace paragraphs overall discussion above.)

I choose to reserve a slightly smaller and much bolder monospace serif font for the Computer paragraph as computer input.

Note: Many symbol/emoji characters, such as Box drawing, do not exist in this FM font. Even if they will display they may not all be the same fixed width and will not align. However as shown below using the monoSans character font within this MonoSerif paragraph format will display symbol characters in HTML aligned with the paragraph’s serif characters, although they will not align in FM.

WIWIWIWIWIWIWIWIWIWIWI monoSans characters in MonoSerif
┞┭┵╁║╱▆ ▏▐▓▕■□▲▶▷▼◀◆◉⬆

By default FM formats all Number paragraphs with an outdent for the number and the subsequent lines indented. See the discussion concerning paragraphs with an outdent. I have set FM to start the autonumber of these Number(*) paragraphs at the beginning of the first line. While I could define the FM autonumber to end with a tab to cause the following FM text to start consistently at a tab stop in FM, tabs do not convert well to HTML as discussed above. I choose to follow the FM autonumber and a period with an em space, which is directly converted to an HTML &emsp;. This makes the CSS based on em simple and works with whatever font size in HTML. However the FM left margin must then be set in fixed points based on observation of matching the first character following the em space after a single digit autonumber. This will make the subsequent lines of the paragraph line up with the beginning of the text in the first line.

1. This is a Number1 para, Autonumbered= [a:<n=1>.\sm]
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0),
[space: 14, 0, 15.6 | 1.1667rem, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
text indented to be equivalent to the normal first indent stop to match similar paragraphs
used to start numbering with “one” in a numbered list and thus usually first in a list,
with “Next Paragraph Tag” of Number

T one tab

T two tabs

T three tabs

• This is a Bullet para for comparison of indentation.
with a forced subsequent line

3. This is a Number para, Autonumbered= [a:<+>.\sm]
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0),
[space: 7, 0, 15.6 | 0.5834rem, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
text indented to be equivalent to the normal first indent stop to match similar paragraphs
used for subsequent incremented half-spaced paragraphs in numbered lists,
with “Next Paragraph Tag” defaulting to this paragraph and thus will continue incrementing

T one tab

T two tabs

T three tabs

This is an Indent1 paragraph for comparison to show its use as a continuation paragraph

4. This is a NumberL para, Autonumbered= [a:<+>.\sm]
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0),
[space: 14, 0, 15.6 | 1.1667rem, 0, --base] (tab: 45pt L, 67.5pt L, 90pt L)
text indented to be equivalent to the normal first indent stop to match similar paragraphs
used for subsequent incremented full-spaced paragraphs in numbered lists,
with “Next Paragraph Tag” defaulting to this paragraph and thus will continue incrementing

T one tab

T two tabs

T three tabs

This is a Outdent1 para
(Indent: 0, 22.5pt, 0 | -1.875rem, 1.875rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base]
(tab: 45pt L, 67.5pt L, 90pt L)
text indented to be equivalent to the normal first indent stop to match similar paragraphs but has no Autonumber so the first line will be hanging at the normal left margin,
with no space above, with “Next Paragraph Tag” of Indent to align as following text.
See also Outdent paragraphs and Manual Spacing for Leading Characters.

T one tab

T two tabs

T three tabs

“This is a Quotation para, Autonumbered=[“ (entered as \‘) ]
(Indent: 39.65pt, 45pt, 45pt | -0.445833rem, 3.75rem, 3.75rem),
[space: 7, 0, 14.04 | 0.5834rem, 0, --base] (tab: 67.5pt L, 90pt L)
right indented, and left indented to be equivalent to the normal second indent stop
with an automatic outdented leading quote character, half space above,
typically followed by a Halfline paragraph
[Identical to Quote but this paragraph name is built-in and default in Word]
Used for direct quotation paragraphs

T one tab

T two tabs
last of these paragraphs needs the closing quote as text”

“This is a Quote para, Autonumbered=[“]
(Indent: 39.65pt, 45pt, 45pt | -0.445833rem, 3.75rem, 3.75rem),
[space: 7, 0, 14.04 | 0.5834rem, 0, --base] (tab: 67.5pt L, 90pt L)
right indented, and left indented to be equivalent to the normal second indent stop
with an automatic outdented leading quote character, half space above,
typically followed by a Halfline paragraph
[A legacy FM paragraph name but alternate name Quotation is default in Word]
Used for direct quotation paragraphs

T one tab

T two tabs
last of these paragraphs needs the closing quote as text”

“This is a QuoteSans para, Autonumbered=[“]
(Indent: 39.65pt, 45pt, 45pt | -0.445833rem, 3.75rem, 3.75rem),
[space: 7, 0, 14.04 | 0.5834rem, 0, --base]
(tab: 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
right indented, and left indented to be equivalent to the normal second indent stop
with an automatic outdented leading quote character, half space above,
typically followed by a Halfline paragraph
Used for direct quotation paragraphs

T one tab

T two tabs
last of these paragraphs needs the closing quote as text”

This is a Singleline para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
with no spacing above or below, and reduced line height
often used for unmarked lists or as a blank paragraph with only a non-breaking space character

T one tab

T two tabs

T three tabs

T four tabs

This is a Small para, [space: 0, 0, 11.7 | 0, 0, 0.9--base]
(tab: 18.75pt L, 37.5pt L, 56.25pt L, 75pt L) [font: 10pt | 0.8333rem],
often used as a smaller blank paragraph with no spacing above or below to add minimal interparagraph spacing when the default spacing before the next paragraph would be none. See the discussion about tabs explaining the proportionately smaller tab stops due to the smaller font size.

T one tab

T two tabs

T three tabs

T four tabs

Compare with a Footnote paragraph in the text which uses the same size font but has an outdent defined for the marker number in the first line with indented subsequent lines, and is also indented on the right.
T one tab

T two tabs

T three tabs

T four tabs

Compare with an IndentFoot paragraph in the text which uses the same size font but is indented at the left margin used by the subsequent text of a Footnote, but is also indented on the right. With the margin at the same first tab stop as Small it could be used like a “SmallIndent” paragraph such as for “fine print” in a narrative.

T one tab

T two tabs

T three tabs

This is a SmallSans para, [space: 0, 0, 11.7 | 0, 0, 0.9--base]
(tab: 18.75pt L, 37.5pt L, 56.25pt L, 75pt L) [font: 10pt, FreeSans | 0.8333rem, FreeSans-local]
with altered vertical alignment, with “Next Paragraph Tag” of the normal Small.

Identical to a Small paragraph but with this different font.
I use this format for file notes at the beginning of a web page, and to contrast with Small

T one tab

T two tabs

T three tabs

T four tabs

This is a SmallCtr para, Alignment: Center | center,
[space: 0, 0, 10.53 | 0, 0, 0.81--base] (no tabs) [font: 10pt | 0.8333rem],
Line space: 0.9 for Ctr * 0.9 for Small = 0.81
often used as a subtitle comment with no spacing above or below
and for small centered text in table cells

This is a SmallCtrSans para, Alignment: Center | center,
[space: 0, 0, 10.53 | 0, 0, 0.81--base]
(no tabs) [font: 10pt, FreeSans | 0.8333rem, FreeSans-local],
Line space: 0.9 for Ctr * 0.9 for Small = 0.81
often used as a subtitle comment with no spacing above or below
and for small centered text in table cells

This is a SmallRight para, Alignment: Right | right,
[space: 0, 0, 11.7 | 0, 0, 0.9--base] (no tabs) [font: 10pt | 0.8333rem],
often used as a smaller right-aligned paragraph with no spacing above or below

This is a SmallRightSans para, Alignment: Right | right,
[space: 0, 0, 11.7 | 0, 0, 0.9--base] (no tabs)
[font: 10pt, FreeSans | 0.8333rem, FreeSans-local],
often used as a smaller right-aligned paragraph with no spacing above or below

This is an Indent paragraph for comparison to the following Subbullet paragraphs

T one tab

T two tabs

T three tabs

• This is a Subbullet para, Autonumbered= [\ •\sm]
(Indent: 22.5pt, 45pt, 0 | -1.875rem, 3.75rem, 0)
[space: 7, 0, 15.6 | 0.5834rem, 0, --base] (tab: 67.5pt L, 90pt L)
with text indented to be equivalent to the normal second indent stop
and is used as the default for interior subbulleted paragraphs,
or whenever less than half-space above is desired,

T one tab

T two tabs

• This is a Subbullet1 para, Autonumbered= [\ •\sm]
(Indent: 22.5pt, 45pt, 0 | -1.875rem, 3.75rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (tab: 67.5pt L, 90pt L)
with text indented to be equivalent to the normal second indent stop
used for the first subbulleted para following a heading,
or whenever no space above is desired,
with “Next Paragraph Tag” of Subbullet

T one tab

T two tabs

• This is a SubbulletL para, Autonumbered= [\ •\sm]
(Indent: 22.5pt, 45pt, 0 | -1.875rem, 3.75rem, 0)
[space: 10, 0, 15.6 | 0.8333rem, 0, --base (tab: 67.5pt L, 90pt L)]
with text indented to be equivalent to the normal second indent stop
and is used for first subbulleted para following a heading,
or whenever nearly full space above is desired,
with “Next Paragraph Tag” of Subbullet

T one tab

T two tabs

This is a Body paragraph for comparison to the following Subindent paragraphs

T one tab

T two tabs

This is an Indent paragraph for comparison to the following Subindent paragraphs

T one tab

This is a Subindent para
(Indent: 45pt, 45pt, 0 | 0, 3.75rem, 0)
[space: 7, 0, 15.6 | 0.5834rem, 0, --base] (tab: 67.5pt L, 90pt L)
with text indented to be equivalent to the normal second indent stop,
and is used as the default for interior subindented paragraphs,
or whenever less than half-space above is desired.

T one tab

T two tabs

This is a SubindentSans para
(Indent: 45pt, 45pt, 0 | 0, 3.75rem, 0)
[space: 7, 0, 15.6 | 0.5834rem, 0, --base] (tab: 67.5pt L, 90pt L)
[FreeSans | FreeSans-local] and altered vertical alignment
with “Next Paragraph Tag” of the normal Subindent.
Identical to a Subindent paragraph but with this different font,
with text indented to be equivalent to the normal second indent stop,
and is used for contrasting interior subindented paragraphs,
or within subbulleted or subnumbered lists

T one tab

T two tabs

This is a Subindent1 para
(Indent: 45pt, 45pt, 0 | 0, 3.75rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (tab: 67.5pt L, 90pt L)
with text indented to be equivalent to the normal second indent stop,
used for the first subindented paragraph following a heading, paragraph,
a subbulleted, or subnumbered paragraph,
or whenever no space above is desired,
with “Next Paragraph Tag” of Subindent

T one tab

T two tabs

This is a Subindent1Sans para
(Indent: 45pt, 45pt, 0 | 0, 3.75rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (tab: 67.5pt L, 90pt L)
with altered vertical alignment, with “Next Paragraph Tag” of the normal Subindent.
Identical to a Subindent1 paragraph but with this different font,
with text indented to be equivalent to the normal second indent stop,
and is used for contrasting interior subindented paragraphs,
or within subbulleted or subnumbered lists

T one tab

T two tabs

This is a SubindentFoot para (in the Body)
(Indent: 18.75ptpt, 37.5pt, 18.75pt | -1.5625rem, 3.125rem, 1.4rem),
[space: 0, 0, 11.7 | 0, 0, 0.9--base], (tab: 56.25 L, 75.0 L), [font: 10pt | 0.8333rem]
with both margins indented and left justify
with “Next Paragraph Tag” of IndentFoot.
Since most lines of non-aligned text will not reach the right margin, I find the same margin as the left is too generous in an HTML scrolling table, so have reduced it to 1.4rem.
It’s margins are formatted in both FM and CSS to align with an indented left margin for continuation paragraphs after an IndentFoot paragraph but with an outdent first line at the normal left margin of that IndentFoot paragraph. Thus continuation paragraphs wrap to an indented left margin set the same as one tab in IndentFoot. It is primarily used for a subparagraph of an IndentFoot paragraph which has some outdent leading numbering or text of that subparagraph.
[I have not had a need to define a SubindentFootSans paragraph format as the sans or smSans character overrides should suffice, but if needed its definition would be obvious.}
For examples of horizontal spacing when using text at the beginning of a SubindentFoot paragraph see the section about Manual Spacing for Leading Characters.
This forced continuation line has sufficient text which will now also wrap back to the paragraph’s indented continuation subsequent lines margin
WARNING: multiple leading tabs will display differently in FM and HTML due to the image used for tabs in CSS as explained above.

This is a forced continuation line with one tab

T two tabs

This is an IndentFoot for comparison with sufficient text to wrap back to this IndentFoot paragraph’s fixed subsequent lines left margin without outdent which is the same as its first line

This is a forced IndentFoot continuation line with one tab which begin at the SubindentFoot margin but will continue at its own defined left margin

T with two leading tabs

T with three leading tabs

This is a SubindentL para
(Indent: 45pt, 45pt, 0 | 0, 3.75rem, 0)
[space: 14, 0, 15.6 | 1.1667rem, 0, --base] (tab: 67.5pt L, 90pt L)
with text indented to be equivalent to the normal second indent stop,
used for the first subindented paragraph following a heading, paragraph,
a subbulleted, or subnumbered paragraph,
or whenever some less than full space above is desired,
with “Next Paragraph Tag” of Subindent

T one tab

T two tabs

This is a Body para for comparison to the following Subnumber paragraphs. I have set FM to start the Autonumber of these paragraphs in the first line at the normal first indent stop. While I could define the FM autonumber to end with a tab, and set a tab stop at the left text margin, tabs do not convert well to HTML as discussed above. I choose to follow the FM autonumber and a right paren with a non-breaking space plus an en space, which is directly converted to an HTML &ensp;. The FM left margin is then set in points based on observation of the first character following the en space after a single digit autonumber to line up equivalent to the second indent stop, as is also the case for setting the CSS left margin and the outdent back to the normal first indent stop for these paragraphs. [I have not had a need to define numbered paragraph formats with a default Sans font as the sans or smSans character overrides should suffice, but if needed their definitions would be obvious.}

This is an Indent paragraph for comparison to the numbering indentation of the following Subnumber paragraphs

1) This is a Subnumber1 para, Autonumbered= [b:<n=1>)\sm]
(Indent: 22.5pt, 45pt, 0 | -1.875rem, 3.75rem, 0)
[space: 10, 0, 15.6 | 0.8333rem, 0, --base] (tab: 67.5pt L, 90pt L)
with text indented to be equivalent to the normal second indent stop
used to start numbering with “one” in a subnumbered list and thus usually first in a list,
with some less than full line spacing above
with “Next Paragraph Tag” of Subnumber

T one tab

T two tabs

2) This is a Subnumber para, Autonumbered= [b:<+>)\sm]
(Indent: 22.5pt, 45pt, 0 | -1.875rem, 3.75rem, 0)
[space: 7, 0, 15.6 | 0.5834rem, 0, --base] (tab: 67.5pt L, 90pt L)
indented at the normal second indent stop, CSS outdent set for single digit numbers
used for subsequent incremented less than half-spaced paragraphs in subnumbered lists,
with “Next Paragraph Tag” defaulting to this paragraph and thus will continue incrementing

T one tab

T two tabs

3) This is a SubnumberL para, Autonumbered= [b:<+>)\sm]
(Indent: 22.5pt, 45pt, 0 | -1.875rem, 3.75rem, 0)
[space: 10, 0, 15.6 | 0.8333rem, 0, --base] (tab: 67.5pt L, 90pt L)
indented at the normal second indent stop, CSS outdent set for single digit numbers
used for subsequent incremented some less than full line paragraphs in subnumbered lists,
with “Next Paragraph Tag” defaulting to this paragraph and thus will continue incrementing

T one tab

T two tabs

11) This another a Subnumber para showing that the left indent is what is aligned even for a two-digit or larger number

This is a SubOutdent1 para
(Indent: 22.5pt, 45pt, 0 | -1.875rem, 3.75rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (tab: 67.5pt L, 90pt L)
text indented to be equivalent to the normal second indent stop to match similar paragraphs but has no Autonumber so the first line will be hanging at the normal first indent stop, with no space above, with “Next Paragraph Tag” of Subindent.
See also Outdent paragraphs and Manual Spacing for Leading Characters.

T one tab

T two tabs

This is a Symbol para: [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
[font: Symbola | Noto Emoji-local, Symbola-local, Noto Color Emoji-local]
with no spacing above or below, and reduced line height
(with numerals above using the serif font).

This is an example of consecutive default digits: 0123
┞┭┵╁║╱▆ ▏▐▓▕■□▲▶▷▼◀◆◉

Since the Noto Emoji font characters are defined “slightly” more narrow than the standard Serif font I am using, tabs (which will remain in that font) will not produce “exact” alignment. If such is required simply override the tab characters with the serif character format.

NOTE: Since FM does not define fallback font families, the FM font is only Symbola. While standard text will display in a Symbol paragraph using Symbola’s variable spaced serif font, the primary font in HTML is Noto Emoji as defined above. Both Noto-Emoji fonts contain no standard text characters (although apparently do define the tab character) and thus will fallback to Symbola. But both do define and will display digits as wide block symbols as shown in the example above and will not result in a fallback to the Symbola text font. Thus any use of this or the SymbolCtr paragraph format intending to contain numerals normally should override them with a character format like serif as should be done for tab characters.

This Symbol and the SymbolCtr paragraph formats are intended for displaying symbols and emojis, and uses of these paragraphs usually contain only such special characters. If monospaced alignment of such characters is required see the MonoSans paragraph format which will also display some symbols. [See also the symbol character format defined with this three family font set used within non-Symbol paragraphs for examples of its display of various blocks of Unicode symbols.]

This is a SymbolCtr para, Alignment: Center | center,
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (no tabs)
[font: Symbola | Noto Emoji-local, Symbola-local, Noto Color Emoji-local]
for details see the Symbol paragraph format above
consecutive default digits: 0123
┞┭┵╁║╱▆ ▏▐▓▕■□▲▶▷▼◀◆◉
[See the symbol character format for examples.]

For more about TableFootnotes see above for a discussion of the formatting of footnote markers and footnote paragraphs, and about the HTML conversion of footnotes to Endnotes and the formatting of that separate section.

a. This is a TableFootnote para, (in the body of the text)
Alignment: Left | left, (Indent: 0, 18.75pt, 18.75pt | -1.5625rem, 1.5625rem, 1.5625rem),
[space: 0, 0, 11.7 | 0, 0, 0.9--base] (tab: 37.5 L, 56.25 L, 75 L), [font: 10pt | 0.8333rem]

Although left alighment is my default for paragraphs, it is mentioned here because it is not the normal FM default of “Justified” for footnotes. It has “Next Paragraph Tag” set to IndentFoot. Also note both right and left margins are equally indented and with an outdent first line.
Just as for the Footnote paragraph this FM format has also changed the space after the character/number to an em space. Thus a leading single character with a trailing period and emspace in the font of this TableFootnote paragraph which is directly entered in the Body of the document displays the same in both FM and HTML as it does as an actual footnote except for the font of the character.
For an “actual” Table Footnote see this footnote within a cell of the basicT table, which demonstrates its different placement, and different marker character in FM than a Footnote in the Body. FM assigns the format named “TableFootnote” by default to any footnote inserted in a table. In FM a table footnote is separately output under that table using an automatic alpha numbering. When converted to HTML all table footnotes are combined as endnotes in the order they occur in the text interspersed with all other footnotes, consecutively integer numbered.
See the discussion about tabs explaining the proportionately smaller tab stops due to the smaller font size.
(See also the more complete discussion of the formatting of Footnotes.)

T one tab

T two tabs

T three tabs

1. Compare with this Footnote paragraph in the body

T one tab

T two tabs

T three tabs

Compare with the IndentFoot paragraph in the body

T one tab

T two tabs

T three tabs

This is a Title para, Alignment: Center | center,
[space: 0, 3, 16.38 | 0, 0.25rem, 0.9--base]
(no tabs) [font: 14pt, Noto Sans | 1.1667rem, FreeSans-local]

It uses the constrasting default Sans font as for most headings
and has a small margin below for on top of a table.
This is a built-in paragraph name in Word
and the default FM format for the title of a table
often used with a Bold character format override.

This is a TopCtr para, Alignment: Center | center,
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (no tabs)
for use in ‘T’ table cells with top vertical alignment

This is a TopCtrSans para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(no tabs) [font: FreeSans | FreeSans-local]
with altered vertical alignment.
Equivalent to a TopCtr paragraph but with this different font
for use in ‘T’ table cells with top vertical alignment
and where I wish to be able to apply character formats
to the paragraph character’s Sans-Serif font

This is a Topic para, [space: 14, 0, 15.6 | 1.1667rem, 0, --base]
(no tabs) [font: Italic, Underline | italic, underline]
with “Next Paragraph Tag” of Body1, and “Keep With Next Paragraph”,
and is the Level 3 heading, no tabs since the tab space would be underlined

This is a TopIndent para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
for use in ‘T’ table cells with top vertical alignment
While Indent1 would also work, this with its slightly smaller line height is preferred for use in tables.

This is a TopIndentSans para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
for use in ‘T’ table cells with top vertical alignment
While Indent1Sans would also work, this is preferred for use in tables.

This is a TopLeft para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L)
for use in ‘T’ table cells with top vertical alignment
While Body1 would also work, this or Singleline with its slightly smaller line height is preferred for use in tables.

This is a TopLeftSans para, [space: 0, 0, 14.04 | 0, 0, 0.9--base]
(tab: 22.5pt L, 45pt L, 67.5pt L, 90pt L) [font: FreeSans | FreeSans-local]
for use in ‘T’ table cells with top vertical alignment
While Body1Sans would also work, this is preferred for use in tables

This is a TopRight para, Alignment: Right | right,
[space: 0, 0, 14.04 | 0, 0, 0.9--base] (no tabs)
for use in ‘T’ table cells with top vertical alignment

This is a TopRightSans para, Alignment: Right | right,
[space: 0, 0, 14.04 | 0, 0, 0.9--base]

(no tabs) [font: FreeSans | FreeSans-local]
for use in ‘T’ table cells with top vertical alignment

Character Formats can be used to override some or all of the default font of any paragraph. My FM naming scheme 21 has all character format names begin with a lowercase character to distinguish them from capitalized paragraph format names. The FM character attributes Underline, Overline, and Strikethrough are set as the CSS property text-decoration-line with values of underline, overline, and line-through. In CSS a character format cannot override any such values set by the paragraph, only add attributes. Therefore all FM character formats should have “AsIs’ for these three settings unless specifically setting them. For several formats I wish to adjust the font size smaller or larger than the surrounding text. Since FM has no such feature, the FM format must specify the new font size. However, CSS does have that capability by setting the font size to some multiplier of “em” which is the current paragraph’s font size. Since several of my character formats are expressed in that manner in CSS they can be used for override formats in paragraph formats with different default font sizes. Character overrides will also affect not only the font but the cell height in a table as shown in three example tables below.

I have also defined character formats which are only applied to the FM anchor character inserted when a table is created. These formats are not used to affect font characteristics of text. Instead they are used allow that table’s FM catalog table format ‘name’ to be output in a manner identifiable by the post-processing Perl script which then assigns that format as a CSS class to the table in the HTML output file. To distinguish these character formats from standard character formats all their names begin with the prefix text “Table-”. For details see the table formats below.

My FM Reference Pages set most of these formats so that FM’s conversion will produce HTML “SPAN” statements surrounding the formatted character(s) where the format name will be converted to the CLASS name. Unfortunately the FM conversion automatically also inserts unwanted new-lines at both the beginning and ending of every generated SPAN statement which causes undesired white-space in the HTML output. My post-processing Perl script finds and removes all of these unwanted new-lines.

FM has a feature to assign a named conditional tag to various text throughout the document so that all of this tagged text can be hidden or shown based on the conditional setting of this tag. If the condition is set to show that tag’s conditional text when the document is converted, it will output as part of the HTML conversion. If hidden it will not output in the converted HTML.

Although a condition tag assigned to some text can set a style, color, and/or background visually identifiable as that condition on that text when it is showing, that formatting will have no affect on its HTML output but may obscure the formatting of any actual character tag on any of that text when showing in FM. For that reason I only set a background color for the text of a condition tag so that the normal ‘text’ formatting which would output will still show. While I use this feature in some documents it has not impacted my HTML conversions.

The character format XRef is automatically produced for an FM cross-reference as a Class for an A hyperlink element in the converted HTML file. However FM does not generate a set of parameters for that class in the CSS it produces. At one point I defined this class as a SPAN with the following CSS:

But that caused problems, so instead I now define the cross reference XML element in the Reference Pages HTML Mapping Table to USE XREF FMT. For my uses of cross reference (FM page counts of subordinate web pages in an intro to a collection of documents) this produces actual text. However this Class of hyperlink is not actually used even though the A link is generated. Thus I remove the automatically produced extraneous and unused XRef HTML link codes with the Perl program.

The “[FM | CSS]” respective values to define the desired text decoration are indicated on the line below the example of that format on a full word and internally in a word. The character format examples below are listed by the format name but are grouped by type in the Table of Contents.

I define a full set of character override formats with this custom text color for many documents which need it for special emphasis. See also: lgBlue, lgSansBlue, sansBlue;, smSansBlue. This custom lighter blue is sufficiently light in both FM and HTML to be a contrast to normal black text as opposed to the normal dkBlue color produced by a ‘blue’ color defintion.

This override simply changes the text to output all uppercase letters whatever case it is entered.

[Inconsolata SemiBold, DemiBold, Stretch: 125% | Inconsolata-w-local, 600, Download width: 125%]

This override imposes the monospaced computer font defined above. For FM I can set the font size of computer to “As is” with DemiBold weight. This custom monospaced font is inherently somewhat smaller size than the normal paragraph font, even with its downloaded width of 125%. I use this font style’s monospace width as the standard for all my monospace fonts so they will all align horizontally. (See also the monospace paragraphs discussion.) Thus this character override format can be used in any FM or HTML paragraph format which has any default font size, including the footnote paragraphs, and be somewhat smaller in height.

While different sizes in FM, the computer and smComputer overrides produce the same size in HTML output in the above Small and two footnote paragraphs and in this IndentFoot paragraph. This is because these paragraphs’ common default font sizes are such to cause the “smaller” computer format text to become the same size as the small fixed size of the smComputer format, which is intended.

As noted in the color defintions above, this dark blue uses the default color named ‘blue’ which is nearly black in both FM and HTML. See also the lighter blue for better contrast.

I use this custom dark yellow/tan instead of the system standard yellow as the latter is so very light and disappears against either white or my standard parchment background color. For visual consistency I created and defined this custom color in FM named dkYellow.

All Equation related characters have built-in character formats as they are predefined in the Character Catalog. Each of these are preset as the default format for that portion of a constructed Equation. However, alternate defined character formats can be selected from the Character Catalog for some by the menu item “Insert / Equations” to open the Equations pop up window. Now click the drop down menu “Equations”, and select “Equation Fonts” to open that separate pop up window. Each types of character used in equations has a drop down menu for possible format choices of that type of character.

This is the default format for numbering Equations. While the Autonumber of the Equation paragraph can be set to the character format EqNum, the presence of that character format is not output to HTML and thus is not defined in the CSS. This character format “name” is predefined and hardcoded by FM and thus has an initial uppercase which does not follow my naming convention. In case the format is ever (inappropriately) used directly within a paragraph I have set its HTML conversion as PLAIN TEXT so it does not produce a SPAN during conversion and thus it cannot be linked to CSS declarations. If I desire an equivalent override within a paragraph I probably should instead use either the monoSans, emphasis or italic formats or use either the Equation or EquationVariables formats and not use this character format.

This the default format for text in Equations. It uses the general monospaced Sans-Serif font family like all Equation text. [This character format “name” is predefined and hardcoded by FM and thus has an initial uppercase which does not follow my naming convention.]

This font style is set using a defined character format from the Character Catalog by doing “Insert Equations”, click the drop down menu “Equations”, select “Equation Fonts” It uses the general monospaced Sans-Serif text category like all Equation text. [This character format “name” is predefined and hardcoded by FM and thus has an initial uppercase which does not follow my naming convention.]

The FM text will display Blue and underlined whether there is a hyperlink assigned or not, but has no other affect in FM. Its Reference page conversion to HTML simply uses PLAIN TEXT instead of SPAN so no HTML SPAN elements are created for beginning or end of its formatted text and thus the character format itself causes no HTML style change as is demonstrated in the word “internal” above. [However if assigned to text which (already) has an override format it will revert that text to the default font and thus lose that override format.]

I created this separate format because of the way FM treats hyperlink markers. FM will use the entire span of contiguous text which contains a hyperlink anchor, both the text before and after the anchor, which has a common font style. That font style identifies the span of text which will be bracketed on conversion with the HTML <A></A> hyperlink markers. Thus if the anchor is contained within text with a specific character format override (such as this hyperlink format) the HTML text which becomes clickable is all the contiguous text with this override format. Otherwise it is all the surrounding text not within an override format until an override format is encountered or the end of the entire paragraph (possibly across multiple sentences), whichever comes first. Therefore I use this character format (if the text to be clickable is not already identified with an override text format for highlighting) for the purpose of restricting the span of text which FM’s conversion (and thus HTML) will bracket with <A></A> hyperlink markers.

CSS (and most browsers) by default typically decorate text bracketed by HTML <A></A> hyperlink markers as blue and underlined as shown with the link connected to the example “text” above. Therefore I chose to also define the FM format as blue and underlined so this format provides a similar look in FM and HTML to visually identify the bracked and clickable text. Note that this <A></A> span is also used around footnote markers, so if my custom CSS for only footnote marker spans occurs first in the CSS file the following generic formatting of all hyperlinks will take precedence. I ensure these character stylings are used in most browsers since I set the default CSS for all hyperlink HTML elements as:

For details of the format indexLtr see its section within special formats for an Index. [16pt, Inconsolata SemiBold, DemiBold, underlined, Background: Cyan, Stretch: 125%]

It is identical to and just another name for the character format emphasis which I prefer to use.

FM has no feature to make a font “larger” so for FM purposes I set all these larger than default, either to the fixed size 16pt, or for colored large text to 18pt. [Large color characters are even larger due to how I use them.] To make these character styles more usable for converted HTML, I instead base their CSS statements on a factor of “em”, either 1.25 or 1.6, which increases their size based on the current paragraph’s font size. Thus these character override formats could be used in any paragraph format to be some value larger than that paragraph’s base text in HTML output. A table below demonstrates the impact of this override format on various default paragraph fonts. These ‘larger’ overrides only increase the font size and do not affect the font family or color set from the containing paragraph unless specifically labeled as such so can be used in any paragraph.

I set these extra large character formats which include a color to be even larger than large and lgBold without color as I generally use them for significant contrast. They are seldom used for ordinary text as it greatly increases the font size, affects the line spacing, and uses either a red or light blue color. They are primarily used in special documents. See also blue and red. They are sufficiently large that I move them down somewhat in HTML.

[16pt, Bold, FreeSans | FreeSans-w-local, font-size: 1.25em; font-weight: Bold;]

These “larger” formats set the general Sans-Serif text category for contrast and increase the sizing the same as large and lgBold.

[18pt, Color: Cyan, FreeSans | FreeSans-w-local, font-size: 1.6em; color: #276EFF;]

[18pt, Color: Red, FreeSans | FreeSans-w-local, font-size: 1.6em; color: #FF0000;]

These formats which set the general Sans-Serif text category and a color are set even larger than lgSans and lgSansBold without color as I generally use them for significant contrast. They are seldom used for ordinary text as it greatly increases the font size, affects the line spacing, and uses either a bold or a red or light blue color. They are primarily used in special documents. See also blue and red. They are sufficiently large that I move them down somewhat in HTML.

[16pt, New Century Schoolbook | New Century Schoolbook-local, font-size: 1.25em;]

This “larger” format also sets the general Serif text category for contrast when used in any non-Serif paragraph formats.

For details of the format menuletter see its section within special formats for an Index.

[16pt, Weight: DemiBold, Underline, Background: Cyan, Stretch: 125%, Inconsolata SemiBold]

[Stretch: 104.7%, Noto Sans Mono | Noto Sans Mono-local & FreeMono-local, font-size: 1.0rem;]

This format uses the general MonoSans text category for contrast. Thus it could be used as an override in most any paragraph format. Its separate stretch is set to align with the computer monospace format. (See also the monospace paragraphs discussion.)

This format uses the general MonoSerif text category which provides contrast in a paragraph format whose default font is not Serif. Thus it could be used as an override in most any non-Serif paragraph, such as Sans font headers. Its separate stretch is set to align with the computer monospace format. (See also the monospace paragraphs discussion.) I choose to reserve the different and much more bold computer override style and its similar Computer paragraph format with a different monospace Serif font to identify computer input.

Similar to the hyperlink format with its Blue color, this noWrap format has no impact on the FM text other than its color to make the text assigned this format visible in FM. However also like hyperlink, its HTML conversion does use SPAN which can invoke the specified CSS statement on the enclosed text which prevents line breaks within that text. I have not found a way to get FM’s conversion to produce nested SPANs, so avoid nesting FM character formats in the FM text even if they would appear to work in FM.

This same SPAN CLASS is also used by the Perl script to surround any contiguous text not containing white space but containing the FM produced Unicode non-breaking dash/hyphen character. When enclosing such text within this SPAN the script also converts that Unicode character to an ordinary hyphen. I perform this conversion because the standard Unicode non-breaking hyphen character has undesired characteristics in HTML. HTML permits nested SPANs where for any duplicate attributes the innermost will rule. Since this SPAN’s CSS only sets the white-space attribute, converting the standard non-break characters to be enclosed in this added SPAN can be safely done by the script when they occur within text which has other override formatting without affecting the attributes set by other SPANs. [Obviously the non-breaking FM character should not be used within FM noWrap text as that would be redundant.]

I define a full set of character formats with this text color for all documents for the purposes of special emphasis, often to visually highlight comments to myself in FM where I still need editing. See also: lgRed, lgSansRed, sansRed, smSansRed. In most documents I will also define other equivalent text color overrides, such as blue for my Bridge documents, when colored text has a special use.

This format uses the general Sans text category for contrast. This font displays slightly bigger than the default Serif font, so I separately reduce its font size in CSS. It could be used as an override in most any paragraph format whose default font is not Sans-Serif.

These three formats use the general Sans text category for contrast. This font displays slightly bigger than the default Serif font, so I separately reduce its font size in CSS. It could be used as an override in most any paragraph format whose default font is not Sans-Serif. See also blue, bold and red.

This text uses serif as an override and internal in a BodySans paragraph for contrast.

This format uses the general Serif text category which is the default for all paragraph formats not otherwise assigned a font, with no separate additional character assignments. It is typically used as an override for contrast in any non-Serif paragraph formats.

FM has no feature to make a font “smaller” so for FM purposes I set most of these smaller than default formats (e.g. sm*) to the fixed size 9pt. But to make this character style more usable for converted HTML, I instead use a CSS statement based on “em” which is the current text size, e.g. the paragraph’s font size, and for most of these styles reduce the size by 25%. These ‘smaller’ overrides only decrease the font size and do not affect the font family or color set from the containing paragraph unless specifically labeled as such so can be used in any paragraph. A table below demonstrates the impact of this override format on various default paragraph fonts.

This text uses small as a “smaller” override in a Body1Sans para and internal

This text (entered as lowercase) uses smCaps as a “smaller” override in Body and internal.

I prefer to have the text size of smCaps such that the small capital letters representing lowercase be about the size of the surrounding lowercase letters, so it needs to be smaller than the base paragraph font size. FM has no feature to make a font “smaller” so for FM I set it to the fixed size of 11pt. But like all these “sm*” character styles, for converted HTML I instead base the CSS statement on “em” for this style which reduces the size 20% based on the paragraph’s font size. While its size is fixed in FM this character override format could be used in any paragraph format to be somewhat smaller in HTML output while also always changing the font variant to small caps.

This text uses smComputer as a “smaller” override in a Body para and internal

This smaller format uses the general Computer text category. I choose to have this character format slightly smaller than the computer character format. Since I primarily use it in footnote text, its size must be fixed for FM which at a smaller font size than all the FM footnote paragraphs. In CSS it uses a smaller relative 0.9em font size than the current paragraph font. Thus in any HTML paragraphs, including the footnote paragraphs, text with this format will be smaller than text with the similar computer character format. For examples see the computer format.]

This smaller format uses the general Sans text category for contrast, and is set in FM the same as small, i.e. fixed to 9pt. But to make this character style more usable for converted HTML, I instead use a CSS statement to set the size as the product of 0.75 for the small attribute and 0.97 for the sans font.

This text uses smSansBlue as a “smaller” override in a Body para and internal

[9pt, color: Cyan, FreeSans | FreeSans-local, font-size: 0.7275em; color: #276EFF;]

This text uses smSansBold as a “smaller” override in a Body para and internal

[9pt, Bold, , FreeSans | FreeSans-local, font-size: 0.7275em;, font-weight: Bold;]

This text uses smSansRed as a “smaller” override in a Body para and internal

These three “smaller” formats uses the general Sans text category for contrast and its font is set the same as the smSans format. See also blue, bold and red.

This text uses smSerif as a “smaller” override in a BodySans para and internal

[9pt, New Century Schoolbook | New Century Schoolbook-local, font-size: 0.75em;]

This “smaller” format also uses the general Serif text category for contrast in any non-Serif paragraph formats.

This 🍄⚽xt uses smSymbol as a “smaller” override in a Body para and internal

[9pt, Noto Emoji & Symbola | Noto Emoji-local & Symbola-local, font-size: 0.75em;]

This “smaller” format uses the general Symbols and Emoji text category for displaying such characters in any paragraph format. (See also the symbol format.) This override character format’s font is set the same as small.

FM automatically makes a font override marked with the subscript or superscript attribute a “smaller” font in FM output relative to the current font. FM’s conversion structure cannot specify to use the <sub> or <sup> HTML elements, but instead must define a SPAN to bracket the overridden text which then can use CSS to set their alignment. However by definition these two standard CSS alignment values do not change the font size. Thus to mimic FM’s automatic smaller font behaviour in CSS, for both SPANs I base the font size CSS statements on “em” for these styles which reduces the size based on the current paragraph’s font size similar to a footnote number. I also prevent these formats from affecting the line-height similar to footnote markers.

This character format is included as the one SPAN class when assigning the Symbol/Emoji font families to the two appropriate paragraph formats, with no separate additional character assignments. As mentioned when defining this set of font families, use of a Unicode appended color selector (️) will display a color variation: 🍄️⚽️. Note that if a character is used which is not defined in these font families, the browser is likely to automatically fallback to one of its built-in font families for that character. If this occurs that character is likely to display differently in different browsers due to different fonts being used, which is why I define and provide the font families I use.

See also the Symbol paragraph format above for warnings about including numeral text within this character format: digits 012345 digits

Box drawing, etc. characters in Body paragraphs with fallback to Symbola (some display in FM):

This top-button character format is used only on an early text/word of the document which becomes the label of the top-of-page button and contains a hyperlink to the unique desired named anchor in this text.

[NOTE: Do not place this text in the first “Content modified” paragraph as it will be copied by the cross index to that paragraph from other index files. I choose to set it at the beginning of the “File modified” paragraph.]

I set FM to display this text in Royal Blue color to stand out from normal text as it is similar to the top-of-page button color set by CSS. While this text must be in the document, this text only shows as the label of this button created as part of my custom web features. Its SPAN Class sets it as the default Serif font regardless of the font of the paragraph it is in, and invokes the following CSS to place it and the hyperlink within a button at the bottom left of the browser window. If the text is two words I separate them with the HTML break code (using the HTML syntax characters) to cause them to stack vertically and centered within the button, e.g. oneЄbrЭtwo.

[This is set to the HTML standard White color. In FM I define it with a custom dkYellow color which has a brownish yellow as background for the white characters so that text is visible in the surrounding default FM white background.]

This standard color yellow is so light in FM it disappears against a white background. Also on my web page is has little contrast with my parchment background. I defined this format for completeness, but I generally use my custom dkYellow color instead.

The FM shortcut key(s) for a given character can most easily be found on the Insert main menu, click Symbols > Symbol > More Symbols. The full character set is shown on the “Symbols” tab, where the “Special Characters” is a short list of the most commonly used. Select the desired character in the table and its name and Shortcut Key (if any) will display below. For multiple keys a plus [ + ] means hold the first key down while pressing the second, where a comma [ , ] means that you need to press multiple keys sequentially in order. “Num” in front of one or more characters indicates their entry on the number keypad.

NOTE: In many cases if a Unicode character is entered into a FM document using the Character Palette, it DOES NOT NEED a conversion in the Reference Pages Character Macros to contain that character in the HTML document. A Character Macro is only needed if that character is to be converted to something else, such as an HTML entity name. Some common entity names are preferred by browsers who have less the complete Unicode support, so I do that coversion. However some characters do not have entity names, so those must remain as the Unicode character.

WARNING: While some Unicode characters, especially all those above #xFFFF, “can” be entered into the FM document from the Character Palette, any subsquent attempt to covert the document to HTML will abort the FM program. In these cases they must be entered in FM using their HTML hexadecimal code. Such entry requires using HTML special characters to ensure FM conversion to the actual set of characters the Unicode character code requires (e.g. Ж#x1F3A4; produces 🎤).

As I have written and posted several documents as HTML about the card game of Bridge I found the need to use the special Unicode characters for card suits in those documents. For entry of all of these use the Character Palette. In all cases the Solid character is converted in the FM Reference Pages Character Macros to the HTML entity. The examples are from the default narrative font families, and the Symbol families and text and as emoji. WARNING: If the hearts or diamonds characters are in a normal font but the red color character override format is applied and that character is within active hyperlink text, then the blue hyperlink color will override the character format and the red will not show. Note that if the Color Emoji version is forced with the special HTML suffix the Diamonds and Hearts character symbol itself is colored red so the hyperlink does not override that color. See also the Miscellaneous Symbols characters in the table in my Character Variations document,

Suit	Unicode Character	HTML	Serif/Sans/Text/Emoji
Clubs Typically this is displayed in black, but lately in “four-color suit” card decks it has been colored green. So one could apply the character format dkGreen ♣. I choose to leave this symbol solid black.	Black/Solid Club Suit #x2663	&clubs; #x2663	♣	♣	♣	♣️
White/Outline Club Suit #x2667	♧	♧	♧	♧	♧️
Diamonds Typically this is displayed in color, so one can apply a character format such as the traditional red ♦. However it has also been colored golden yellow-orange (dkYellow) ♦, or more recently in “four-color suit” card decks as blue (dkBlue) ♦. I choose to color this symbol solid red.	Black/Solid Diamond suit #x2666.	&diams; in red #x2666 in red	♦ ♦ ♦ ♦	♦ ♦ ♦ ♦	♦ ♦ ♦ ♦	♦️ ♦️
White/Outline Diamond Suit #x2662 Although outline on the new official ACBL Card I often use solid red.	#x2662; in red	♢ ♢	♢ ♢	♢ ♢	♢️ ♢️
Hearts If colored typically this is always displayed in solid red (red) ♥ which I choose to use.	Black/Solid Heart suit #x2665.	&hearts; in red #x2665 in red	♥ ♥ ♥ ♥	♥ ♥ ♥ ♥	♥ ♥ ♥ ♥	♥️ ♥️
White/Outline Heart Suit #x2661 Although outline on the new official ACBL Card I always use solid red.	#x2661; in red	♡ ♡	♡ ♡	♡ ♡	♡️ ♡️
Spades This is nearly always displayed in solid black, but some German decks occasionally use solid green for spades dkGreen ♠ and solid black clubs. I choose to leave this symbol solid black.	Black/Solid Heart suit ♠ must use Character Palette #x2660. This is nearly always displayed in solid black, but some German decks occasionally use green spades and black clubs. I choose to leave this symbol solid black.	&spades; #x2660	♠ ♠	♠ ♠	♠ ♠	♠️ ♠️
White/Outline Spade Suit #x2664	♤	♤	♤	♤	♤️

In many cases it makes more sense to use special characters rather than some image in HTML to create desired lines. For these purposes I have styled two horizontal lines, and several box drawing characters, in addition to the lines defined around cells of tables.

For some documents I choose to have horizontal rules as separators. The only available way to accomplish this in FM requires an anchored frame containing a graphic image of a horizontal rule of the desired characteristics. An earlier version of my Perl script for post-processing the converted HTML file looked for a converted HTML “<img src=” element which referenced .gif files whose filenames began with the document name and a dash followed by sequential numbers. Such files are automatically produced on conversion for anchored graphics. Thus these elements would exist for however many of these anchored image frames were inserted. The script altered the img text by redirecting the source reference to a common image file of a horizontal line and inserting a string of em dash characters as alt text.

Since my primary purpose for most of these documents is the HTML output, I have since reserved two special characters in an alphabet I am unlikely to use (Љ and Њ). Their Reference Page entries convert to the HTML code for two Classes of horizontal rule <hr> elements as shown in the table below. These two Classes have different CSS style characteristics defined in the custom CSS file which seem to suffice for my uses of horizontal rules. The first is fixed-length, long and thin, left justified. The other is responsively 0.3 times the screen width, short and thick, centered. An <hr> is a block-level HTML element which will automatically begin a new line and end with a new line with top and bottom margins for the newline inherited from the paragraph it is in. This results in an implicit </p> automatically generated first that closes any open <p> elements. Because of that the further following </p> (automatically produced by the end of the FM paragraph) is a warning error and produces an extra line break. To avoid this error and extra line break I ensure these reserved characters are either the only character(s) in a paragraph or the very last character(s) in the paragraph. If placed in this manner, my Perl script will remove the extraneous </p> immediately following the <hr> element. As a result the horizontal rule will fall immediately below the ending paragraph’s bottom margin (which is usually zero), and above the following paragraph’s top margin.

To center the line vertically between two paragraphs place the rule character alone in a paragraph which is defined with no bottom margin and a top margin the same as the following paragraph. Note that if the paragraph ending with the rule character has leading characters as additional content, even just a non-breaking space, there will be a top margin above the contents of this paragraph plus another top margin above the horizontal rule caused by its automatically beginning a new block/line. Horizontial rules may be multiple in a row which is why I give the CSS for the rule itself a top margin equal to its height. The below is the CSS for each followed by an example.

Char	FM Character	HTML
Љ	Must use Character Palette #x0409	<hr CLASS="Thin">
Њ	Must use Character Palette #x040A	<hr CLASS="Thick">

Additional special line characters I have used are the Unicode box drawing characters which require a monospace font to align. These will likely display in HTML using the fallback font of my defined monospaced Sans-Serif pair of font families to ensure these special characters are defined monospaced. Although a few of these special characters have HTML entity names,23 I do not convert them in the Character Macros so they remain those characters in the HTML document. My most common current use is in the leading aligned columns of a table using a blank format to show decendency relationships in a genealogy chart. To ensure they display I only use them with the paragraph format MonoSans, or assign the override character format monoSans in an appropriate table paragraph, as shown in the example table below. For more box drawing characters (e.g. heavy and double lines) see: https://en.wikipedia.org/wiki/Box-drawing_character#Unicode

Character	Unicode	Definition
┌	#x250C &lceil;	Light, down & right (left & ceiling)
│	#x2502	Light, vertical
├	#x251C	Light, vertical & right
└	#x2514 &lfloor;	Light, up & right (left & floor)
─	#x2500	Light, horizontal
┬	#x252C	Light, down & horizontal
┼	#x253C	Light, vertical & horizontal
┴	#x2534	Light, up & horizontal
┐	#x2510 &rceil;	Light, down & left (right & ceiling)
┤	#x2524	Light, vertical & left
┘	#x2518 &rfloor;	Light, up & left (right & floor)

Box drawing characters in a MonoSans paragraph
WWWWWWWWWWW
IIIIIIIIIII
ABCDEFGHIJK
┌│├└─┬┼┴┐┤┘
and complete boxes with Light and Heavy box characters:
┌─┬─┐ ┏━┳━┓
│A│B│ ┃A┃B┃
├─┼─┤ ┣━╋━┫
│C│D│ ┃C┃D┃
└─┴─┘ ┗━┻━┛

I prefer curved (smart) quotes when I am using the normal variable spaced serif font, but prefer vertical (non-smart) quotes when using a monospace font. Each of these eight “standard” characters are able to be entered by an appropriate keyboard shortcut. The keyboard keys most used are: single quote [ ' ], double quote [ " ] (shift quote), and grave [ ` ]. The purpose of the Format / Document / Text Options / Smart Quotes On option is to automatically produce the appropriate different (curved) character when the single or double quote key is used before or after a text character. I find it annoying to turn the Smart Quotes option on and off, especially for only a few characters, so the table shows what keys produce the desired character in FM whatever the current state of that option setting. To search for one of these characters, the keyboard keys will appear in the Find pod “as if” Smart Quotes are off but are required as shown to find that specific character. Finally, the FM Reference Pages Character Macros converts all these characters to the indicated HTML codes when output to HTML.

Character	If OFF	If ON	Always	Find	HTML
Quotation mark-" U+0022 #34	" (dbl quote)	Esc " (dbl quote)	-- N/A, force required quote --	" (dbl quote)	"
Apostrophe-' U+0027 #39			Ctrl+' (quote)	\" (dbl quote)	'
Grave accent-` U+0060 #96			Ctrl+` (grave)	\{ (left brace)	&grave;
Acute accent-´ U+00B4 #180			Ctrl+q + (Shift=)	(copy/paste text)	´
Left single quotation-‘ U+2018 #8216	` (grave)	' (quote at text start)	` (grave)	` (grave)	‘
Right single quotation-’ U+2019 #8217	' (quote)	' (quote within or at text end)	-- ' (quote) except at start of text --	' (quote)	’
Left double quotation-“ U+201C #8220	Alt+Ctrl+` (grave)	" (dbl quote at text start)	Alt+Ctrl+` (grave)	\` (grave)	“
Right double quotation-” U+201D #8221	Alt+Ctrl+' (quote)	" (dbl quote within or at text end)	Alt+Ctrl+' (quote)	\' (quote)	”

Many special characters are recognized by HTML as part of the syntax for HTML commands or HTML entities. In most cases any text entered in an FM document is expected to display as that set of characters following conversion to HTML. Therefore these special characters are normally converted by FM to HTML entity codes to prevent their special HTML interpretation and allow them to display as that character in the text. However there are many cases where I want to embed the text of an actual HTML command or entity so that it will be recognized in the converted HTML file. In these cases some method must be used to produce such special characters in the converted output. To accomplish this I reserve some otherwise unused text characters and use the FM conversion function of the Reference Pages Character Macros to convert each single reserved character to any desired HTML text.

Such otherwise unused reserved Unicode characters can be directly inserted in the FM document, if necessary by using the FM Character Palette. Each single character then can be used as a temporary code to be converted as it is defined in the Reference Pages Character Macros to whatever length HTML text is desired. When entered in FM as simply the reserved character they often only display as a question mark. Since they will be converted they can be placed in any paragraph with any font as they will not appear in the HTML page. However if one of those reserved characters is desired for output, such as the examples in the tables below, the HTML hexadecimal code (&#xnnnn;) for that character can be directly entered in FM as shown below to actually display it.

The following table identifies the common characters recognized by HTML which will be converted, and the reserved special character I defined to be converted to the character required for HTML commands or HTML entities. For my convenience I chose to reserve characters whose shape reminded me of the intended character.

Unicode	Character	Conversion	Purpose
#x0022	"	"	Avoids true double quote in HTML file (to enter see above)
#x0439	й	"	Forces true double quote in HTML file
#x0026	&	&	Avoids true ampersand in HTML file
#x0416;	Ж	&	Forces true ampersand in HTML file
#x003C	<	<	Avoids true less-than in HTML file
#x0404	Є	<	Forces true less-than in HTML file
#x003E	>	>	Avoids true greater-than in HTML file
#x042D	Э	>	Forces true greater-than in HTML file

In addition to converting single HTML syntax characters, I use the Reference Pages Character Macros to produce actual HTML text for several other purposes. A Macro could just convert a reserved character to a complete HTML command stored in the Reference Pages Character Macro, such as a horizontal rule command, or an IMG command to display an inline image complete with all the necessary sizing and positioning parameters.

The reserved Ж character mentioned above can force an actual apersand as the first character of the text of an HTML hexadecimal character code entered in the FM document. Such codes can be used to output any Unicode character in the converted HTML, but especially those which cannot or should not be entered directly into the FM document as that character. This especially includes symbol and emoji characters whose Unicode value is above #xFFFF. Entering them directly into the FM document, even using FM’s own Character Palette, will likely abort the FM program when the HTML conversion is attempted. This code for a character in the document can either be to actually output it such as for a symbol/emoji character (e.g. Ж#x1F3A4; produces 🎤), or to insert this unique character in the converted file for the post-processing Perl script to recognize it and replace it with multiple HTML or Javascript commands desired at that point in the file.

Unicode	Char	Letter	Purpose
#x0401	Ё	Cyrillic uppercase letter IO	Perl inserts standard SPAN and other required HTML code in standard documents to invoke onClick Javascript to compose email to me
#x0409	Љ	Cyrillic uppercase letter LJE	Converts to the HTML horizontal rule code with CLASS="Thin"
#x040A	Њ	Cyrillic uppercase letter NJE	Converts to the HTML horizontal rule code with CLASS="Thick"
#x0451	ё	Cyrillic lowercase letter IO	Perl inserts special SPAN and other required HTML code for master documents to invoke onClick Javascript to compose email to me. Required since such special documents will also include the uppercase version in their text and their Perl script needs to ignore them and use this.
#x0100, #x0104, #x0106, #x010A, #x010E, #x0110, #x0112, #x011C, #x0124	Ā, Ą, Ć, Ċ, Ď, Đ, Ē, Ĝ, Ĥ	Latin uppercase letters with diacritics	Examples of reserved letters I have used to convert to complete IMG commands to insert images.

The table below lists some FM special characters which I commonly use as well as the multiple kinds of space 24 and dash characters available in FM. I have defined FM Reference Pages Character Macros to convert from the FM character or code to an appropriate Unicode character, HTML entity or HTML element which will produce the same output in the web page. For example both FM and HTML have codes, but different codes, to insert various space characters in output which can be especially useful for some formatting needs. Conversions are required since otherwise HTML will treat FM whitespace characters which are unconverted (spaces, tabs, and newlines) differently from ordinary characters. In general, single whitespace text characters—including newlines (as opposed to end-of-paragraph)—or a consecutive sequence of whitespace text characters are treated by HTML as if a single space and any leading/trailing whitespace is eliminated. The increasing sizes of single space characters are:

Width	Name	FM Shortcut	Text	HTML
~0.3-0.5em	space	(space)	' '	(space)
~0.167em	true thin space	must use hex code	' '
~0.3-0.5em	non-breaking	Esc (space) h	' '
0.5em	en space	Esc (space) n	' '	&ensp;
1.0em	em space	Esc (space) m	' '	&emsp;

In addition to the various kinds of spaces and dashes, I choose to convert newline and tab characters. I often want a newline character to produce its intended line break. Further I usually desire a tab character to cause “some” spacing more than being collapsed within a single space. For these reasons I have defined FM Reference Pages Character Macros to convert both of these text characters for HTML output. Any newline character in FM is converted to the standard HTML new line element (<br>). Conversion of tab characters is treated as a very special case as described in some detail above. Each tab becomes a hidden image of width 1.875em. All conversions to HTML entities which represent some form of space produces relative spacing based on the width of the paragraph’s font.

Unicode	HTML	FM Shortcut	Find	Description
#x08	image width: 1.875em	(Tab)	\t	Horizontal tab. Since HTML/CSS has no tab stops, I convert this character to fixed width hidden image. See the separate discussion of the horizontal alignment of tabs.
#x0020	(space)	(space)	(space)	Normal breaking space character. In variable spaced fonts its width varies according to the font, commonly about 0.3em, but typically less than one en and anywhere from 0.2em to 0.5em. In fixed width fonts it is one full normal character width. Note that HTML collapses multiple breaking white space to one normal space.
#x2423	&blank;	Palette #x2423		Open box character ‘␣’ used to visually represent a space.
#x00A0		Esc (space) h	\ (space)	Non-breaking space. Exactly the same width as the width of a normal space. Thus in variable spaced fonts its displayed width is also typically less than one en. In fixed width fonts it is one full normal character width. Fortunately this HTML entity code will be rendered as an actual space for Find or Copy from the HTML output, and not a Unicode character.
#x2002	&ensp;	Esc (space) n	\sn	En Space. Also known as "nut". Width of one en, or exactly 0.5em. In variable spaced fonts it is typically some wider than a normal space. In fixed width fonts it is one full normal character width. Unfortunately even though there is an entity name it is not rendered as a space in HTML for either Find or Copy but remains the Unicode character, so I seldom use it.
#x2003	&emsp;	Esc (space) m	\sm	Em Space, a full character width 1.0em. Also known as "mutton". Width of one em, at least the width of a capital M in the current font. In variable spaced fonts it is exactly 2.0en which is typically clearly wider than two normal spaces. In fixed width fonts in FM it is almost as wide as two normal spaces, but in HTML it is one full normal character width. Unfortunately even though there is an entity name it is not rendered as a space in HTML for either Find or Copy but remains the Unicode character, so I seldom use it.
#x2007	ߗ	Esc (space) 1	\#, or \s#	Numeric or Figure Space. Width of the font’s zero character, used to align numbers. Some wider than a normal space. In fixed width fonts it is one full normal character width. Since there is no entity name it is not rendered as a space for either Find or Copy but remains the Unicode character, so I seldom use it.
#x2008	ߘ	Palette #x2008		Punctuation Space. Supposedly width of a period ‘.’. In both FM and HTML fixed and variable width fonts it is rendered as one full normal character width, thus I choose not to use it.
#x2009	<wbr>	Esc (space) t	\st	Thin Space, from 0.125em to 0.2em but typically 0.167em. I override the default FM conversion to the HTML   code (also  ) to use the HTML discretionary word break element so that no actual space will show or copy in the HTML output if the word is not broken. In FM it shows thin, but in HTML the <wbr> code is rendered as nothing. However unlike the discretionary hyphen (#x00AD) below, when broken there now is no hyphen.
#x200A	&hairsp;	Palette #x200A		Very thin space, or hair space (also &VeryThinSpace;). Thinner than a thin space, 1/18 em (0.056em). In both FM and HTML it shows thin in variable width fonts, but in fixed width as a normal space. Unfortunately even though there is an entity name it is not rendered as a space in HTML for either Find or Copy but remains the Unicode character, and is not universally supported, so I seldom use it.
#x202F		Palette #x202F		Narrow nobreak space. Was &Nnbsp; but entity name is no longer recognized. Should be same width as Thin Space, from 0.125em to 0.2em but typically 0.167em. However, not easy to tell in FM as it displays as the ‘?’ unrecognized character. In HTML in variable width it is slightly less width than a normal space, where in fixed width fonts it is one full normal character width but remains nonbreaking. However, since there is no longer an entity name it is not rendered in HTML as a space for either Find or Copy but remains the Unicode character, so I seldom use it. If a narrow non-breaking space is needed, I can bracket the standard non-breaking space with the “small” character format. Otherwise I could do something equivalent to the conversion of the non-breaking dash/hyphen Unicode character by assigning a class to a true space in the post-processing script which has both nowrap and a reduced font size.
#x09	<br>	Shift+Return	\r	Line break, as opposed to end-of-paragraph.
#x0A	</p><p>	Return	\p	End-of-paragraph break.
#x2D	-	- (hyphen or minus)		Standard hyphen or minus character.
#x2011	‑ then postprocess to a noWrap character format	Esc - h	\+	Non-breaking dash/hyphen: -. WARNING: This Unicode character produced by the FM shortcut will not be found in HTML by searching for a hyphen, and if the HTML text is included in copy/paste will not result in a hyphen but will remain this Unicode character. In contrast the non-breaking HTML space entity produces a searchable and copyable space. Thus I choose to have a Reference Pages character macro temporarily convert this single character to the equivalent HTML entity “‑” character string for this Unicode non-breaking hyphen. I then use my Perl script to search for that entity string, and surround any contiguous text not containing white space but containing this special entity with a SPAN which sets the nowrap attribute. (See also the noWrap character format.) The script then also converts the HTML entity character string back to a single but now normal dash character. This ensures the behaviour of that normal dash in HTML as non-breaking, but still lets that dash behave as a normal dash in HTML so copy/paste and search find a normal dash.
#x00AD		Esc - D	\-	Discretionary hyphen. WARNING: This HTML entity code will not be found by searching for a hyphen even if the discretionary hypen is being displayed. However if this HTML text is included in copy/paste, even when not displayed, the copied text will include this discretionary hyphen Unicode character. While displaying the hyphen character would be convenient when the word is broken, I do not use this character in FM. Instead I choose to use the thin space character (#x2009) above in FM which the macro converts to the HTML discretionary word break so that no actual hyphen will copy in the HTML output whether or not the word is broken. While the word “may” break at this point, when broken there now is no hyphen displayed.
#x2013	–	Control+q Shift+p	\=	En dash: –, longer than the hyphen.
#x2014	—	Control+q Shift+q	\m	Em dash: —, longer than the en dash.
#x2261	&equiv;	Palette #x2261		Identical To: ≡. Triple line equal.
#x2264	≤		\u2264	Less than or equal to: ≤. Symbol character set.
#x2265	≥		\u2265	Greater than or equal to: ≥. Symbol character set.
#x2022	•	Control+q %	\b	Bullet symbol: •
#x2026	…	Control+q Shift+i	\e	Ellipsis: …
#x2122	™	Control+q *	\TM	trademarkserif: ™
#x00A8	®	Control+q (	®	registerserif: ®
#x00A9	©	Control+q )	©	copyrightserif: ©

The following are Unicode characters which I have only used in a few various documents and must be entered by the FM Character Palette or by a Unicode character code. Further whether they will display as the indicated description depends upon the font family used, as demonstrated below. They are not converted in the Reference Pages Character Macros and remain as Unicode or the character code in the HTML document. (One of the examples below does have an HTML entity name. If a character is included in the Character Macros it will be converted to the HTML hex code or entity name specified in the macro and not remain the actual Unicode character in the converted HTML file.)

NOTE: In most cases these Unicode characters only display as a question mark in FM, either on the screen or in print output. To print, one could save as Microsoft RTF then print from Word which might recognize these characters depending upon the font used, or copy the text to Notebook which is likely to find a built-in font to display them, and print it. Conveniently if the Unicode character is copied, possibly from this HTML document in a browser window, it will introduce that character into FM without need to do an Insert from the Character Palette. And if copied into the Find fields they often will show as their appropriate Unicode character, and the Find will locate them.

The Serif column examples all use the default Serif font families, which includes the Symbola font as a fallback to display many special characters not in the basic Serif font. Those families are defined for the TopCtr paragraph format used for that column in the table. In most cases if intending to display symbols or emoji the Symbols and Emoji font families should be used and those families are defined for the SymbolCtr paragraph format used in those columns in the table.

As can be seen in the table many characters are different in the two font families. Many symbol and emoji characters have both a “text” variation and an “emoji” variation. Due to the particular families defined, and the specific heirarchy of fallback fonts within the families, text variation is what will show by default using both the Serif families and the Symbol/Emoji families, but can be forced by appending the Unicode character ︎ to the character if necessary. To force the emoji variation, only available in the Symbol/Emoji families, requires the appended Unicode character ️, and is shown in the Emoji column whenever a different character exists from the text variation. For the ordinal numbers note that the digits themselves are block symbols in the Symbol family, but can be made normal text characters in this SymbolCtr paragraph with the serif override character format as shown.

Unicode	Serif	Sans	Symbol	Emoji	Description
	1ST	1ST	1ST 1ST		(No uppercase S modifier letter defined, use superscripts within an appropriate font family paragraph)
#x02B3 #x1D48	3ʳᵈ	3ʳᵈ	3ʳᵈ 3ʳᵈ		Modifier lowercase ‘rd’ characters for ordinal numbers.
#x02E2 #x1D57	1ˢᵗ	1ˢᵗ	1ˢᵗ 1ˢᵗ		Modifier lowercase ‘st’ characters for ordinal numbers.
#x1D3A #x1D30	2ᴺᴰ	2ᴺᴰ	2ᴺᴰ 2ᴺᴰ		Modifier uppercase ‘ND’ characters for ordinal numbers.
#x1D3F #x1D30	3ᴿᴰ	3ᴿᴰ	3ᴿᴰ 3ᴿᴰ		Modifier uppercase ‘RD’ characters for ordinal numbers.
#x1D40 #x1D34	4ᵀᴴ	4ᵀᴴ	4ᵀᴴ 4ᵀᴴ		Modifier uppercase ‘TH’ characters for ordinal numbers.
#x1D57 #x02B0	4ᵗʰ	4ᵗʰ	4ᵗʰ 4ᵗʰ		Modifier lowercase ‘th’ characters for ordinal numbers.
#x1DAF #x1D48	2ᶯᵈ	2ᶯᵈ	2ᶯᵈ 2ᶯᵈ		Modifier lowercase ‘nd’ characters for ordinal numbers.
#x21B6	↶	↶	↶		Anticlockwise top semicircle arrow.
#x21B7	↷	↷	↷		Clockwise top semicircle arrow.
#x21E4	⇤	⇤	⇤		Leftwards arrow to bar (left tab).
#x21E5	⇥	⇥	⇥		Rightwards arrow to bar (right tab).
#x2327	⌧	⌧	⌧		Darker small crossed box. Used for Bridge card.
#x2395	⎕	⎕	⎕		Narrow box.
#x23E9	⏩︎	⏩︎	⏩︎		Black right-pointing double triangle (fast forward).
#x23EA	⏪︎	⏪︎	⏪︎		Black left-pointing double triangle (rewind, fast backwards).
#x23F8	⏸︎	⏸︎	⏸︎		Double vertical bar (pause).
#x23F9	⏹	⏹	⏹		Black square (stop).
#x2503 #x2503	┃┃	┃┃	┃┃		Box drawing heavy single verticals. See also box drawing.
#x2551	║	║	║		Box drawing double vertical
#x2586	▆	▆	▆		Lower three quarters block.
#x2587	▇	▇	▇		Lower seven eighths block.
#x258D	▍	▍	▍		Left three eighths block
#x2593	▓	▓	▓		Dark shade.
#x25A0	■	■	■		Black square (moding mark).
#x25A2	▢	▢	▢		Rounded box.
#x25AE	▯	▯	▯		Tall/narrow box.
#x25B2	▲	▲	▲		Black up-pointing triangle.
#x25B6	►	►	►		Black right-pointing triangle.
#x25B7	▷	▷	▷		White right-pointing triangle (z notation range restriction).
#x25BC	▼	▼	▼		Black down-pointing triangle.
#x25C0	◄	◄	◄		Black left-pointing triangle.
#x25C6	◆	◆	◆		Black diamond.
#x25CF	●	●	●		Black circle.
#x2605	★	★	★		Black star.
#x2610	☐	☐	☐		Ballot box. Used for Bridge card.
#x2611	☑	☑	☑	☑️	Checked box.
#x2612	☒	☒	☒		Crossed box.
#x2630	☰	☰	☰		Trigram for heaven (qian2).
#x2637	☷	☷	☷		Trigram for earth (kun1).
#x26BD	⚽	⚽	⚽	⚽️	Soccer ball.
#x26DD	⌧	⌧	⌧		Large dark crossed box.
#x26EF	⛯	⛯	⛯		Map symbol for lighthouse.
#x2713	✓	✓	✓		Checkmark. &check;
#x2714	✔	✔	✔	✔️	Heavy Checkmark.
#x2715	✕	✕	✕		Cross mark.
#x2716	✖	✖	✖	✖️	Heavy Cross mark.
#x2717	✗	✗	✗		Script Cross mark.
#x2718	✘	✘	✘		Heavy Script Cross mark.
#x274E	❎	❎	❎	❎️	Green filled crossed box.
#x2795	➕	➕	➕	➕️	Heavy plus sign
#x27F2	⟲	⟲	⟲		Anticlockwise gapped circle arrow.
#x29BF	⦿	⦿	⦿		Circled bullet.
#x29C9	⧉	⧉	⧉		Two joined squares.
#x2B1C	⬜	⬜	⬜	⬜️	White filled box.
#x2B24	⬤	⬤	⬤		Black large circle.
#x2B70	⭰	⭰	⭰		Leftwards triangle-headed arrow to bar (left tab).
#x2B72	⭲	⭲	⭲		Rightwards triangle-headed arrow to bar (right tab).
#x2BAA	⮪	⮪	⮪		Black curved upwards and leftwards arrow.
#x2C77 #x033A	ⱷ̺	ⱷ̺	ⱷ̺		Latin small letter tailless phi, with combining inverted bridge below
#x1F3E0	🏠	🏠	🏠	🏠️	House building (home).
#x1F3A4	🎤	🎤	🎤	🎤️	Microphone (karaoke).
#x1F4BB	💻	💻	💻	💻️	Personal computer.
#x1F507	🔇	🔇	🔇	🔇️	Speaker with cancellation stroke (mute).
#x1F50A	🔊	🔊	🔊	🔊️	Speaker with three sound waves (sound).
#x1F50C	🔌	🔌	🔌	🔌️	Electric plug.
#x1F50D	🔍	🔍	🔍	🔍️	Left-pointing magnifying glass (search).
#x1F6C8	🛈	🛈	🛈		Circled information source (information).

As noted in the above discussion of paragraphs and tables, the main aspect of tables is that FM paragraph formats cannot override the vertical position of the paragraphs within the HTML table cells. Since my preferred output is web pages, I have chosen table format names which are designed to reflect and remind me of the HTML table’s vertical positioning of paragraphs and other HTML features. As mentioned in the description of Table Formatting, by default the table format name and information is not transferred from the FM document when it is converted to HTML. To accomplish this transfer the naming scheme of a character format which I assign only to the table anchor character is “Table-formatname” or “Table-formatnameScroll” to match the table’s format naming scheme of “T-formatname”. The post-processing Perl script will truncate the table Class names which are created upon conversion to HTML to only use the formatname text without a prefix or suffix, which is the Class name used in the CSS file.

All “T-basic*” tables have basic formatting and are aligned left, with the exception of “T-basicCtrB” whose name indicates it is aligned center. All “T-Format*” tables have more decorated formatting and are all aligned to the center. The trailing character on the table names indicate their CSS vertical paragraph alignments: B = bottom, M = middle, and T = top which is imposed within the table regardless of the FM paragraph formats within the cells. Character format naming of the table anchor and a post-processing Perl script to convert the names to CSS Class names for the table is required as there is no other way to communicate this paragraph format name to the HTML and CSS. Fortunately the horizontal position of text within the cells is able to be controlled in FM by the choice of paragraph format. I have chosen to have all the table formats currently defined to impose the position of the paragraphs within headers and footers (CSS element th) to be vertically in the middle, again regardless of the FM paragraph format. FM’s default template documents have always had predefined formats named “Format A” and “Format B”. However, a CSS Class name cannot have an internal space, so I do not use those names for any of my table definitions.

As mentioned in the discussion of vertical alignment, the main issue with FM paragraphs giving a different look in HTML is when the paragraph has defined spacing “above” (or below). This will look different if the paragraph is used first in a table cell with vertical alignment of either top or middle. This extra space will show in HTML but not FM. These paragraphs are:

Body, BodySans, Bullet, BulletL, DefHead, Equation, Halfline, Indent, IndentSans, IndentL, Major, Minor, Number, Number1, NumberL, Quotation, Quote, Subbullet, SubbulletL, Subindent, SubindentSans, SubindentL, Subnumber, Subnumber1, SubnumberL, Topic.

These paragraphs with space below should not be used last in a cell if its vertical alignment is bottom:

Also to be sure not to end the last paragraph with a CR if the cell’s vertical alignment is bottom or middle since line spacing caused by that additional final text line will keep it from being at the bottom of the cell or cause it to be up from the middle.

The following format produces an FM table similar to the default in FireFox and most browsers. The table anchor for a table with this format should not have a Character Format to link it to any CSS code. This table in Firefox is aligned left and single spaced above and below, all borders including headers and footers are double lines, and the paragraphs aligned vertically in the middle in all cells. Therefore to have this table’s FM “look” match the Firefox default vertical alignment, the FM paragraphs should be a ‘Mid*’ format. This FM table’s paragraph formats default to Title (if included), HeadFoot (if headers/footers included), and MidLeft for the data cells, which should approximate most browsers defaults.

default table title
HeadFoot/bold	HeadFoot	HeadFoot
TopLeft	MidLeft MidLeft MidLeft	MidLeft
MidLeft Body	TopCtr	BotRight
Body1 Body	MidCtr	BotLeft
Body1 Body	BotCtr	TopLeft
Body1 Body	TopLeft TopIndent	TopRight
Body1 Body	Body, top margin down from center	MidLeft
Body1 Body	MidLeft	MidRight
MidLeft MidIndent MidLeft MidIndent MidLeft MidLeft	Body1 Body only works if vertically fills the cell	MidCtr MidLeft MidLeft longer text line
HeadFoot	HeadFoot/bold	HeadFoot
SecondFoot	Foot	Foot

The custom CSS file only has statements which set table features for tables with a Class name to ensure the browser default will be produced when a table has no character format on the table anchor. Thus such a table should be displayed with the style that is “default” for the current browser. Further since I do not assign a Character Format to a table anchor with the default format, it cannot pass a format name with a suffix of “Scroll” to the Perl script to cause it to scroll.

The following two formats are intended to be able to align text in columns and rows without any decoration of these columns or rows, and defaulting to no Title or headers/footers (which could be overridden). “blank” provides the text completely without decoration, where the only difference of “blankBorder” is that it provides a border framing the entire table. I primarily use these to align columns since HTML does not have a mechanism to cause alignment to tab stops based on the tab character, especially with variable width fonts. (See also tabs.) Thus this table can be used more reliably for general purpose left-or right-alignment of columns of text. (See also the List paragraphs.) The reduced min-width and lack of padding causes each row to appear as if a normal next line in a paragraph. The table itself is aligned left by default with no spacing above and below which can be enhanced with empty paragraphs but standard top/bottom margins so looks like a separate paragraph. For the FM table to match the imposed CSS table code of top for paragraph alignment, this FM table’s paragraph formats default to Title (if included), HeadFoot (if headers/footers included), and table cells as TopLeft to have reduced top margin. I do assign the appropriate Character Format to either blank table anchor to invoke its specific CSS. However, I do not also use a format name ending in “…Scroll” so the Perl script cannot provide scrolling for such tables. I sometimes use such tables enclosed in Flex paragraphs.

blankBorder table title
HeadFoot	HeadFoot	HeadFoot
TopLeft TopIndent TopLeft	TopLeft	TopLeft
TopLeft Body	TopCtr	TopRight
TopLeft Body	TopLeft TopIndent TopLeft	TopCtr
Body1 Body1 TopLeft TopLeft Body1 Body1	TopCtr Body	TopCtr TopLeft
HeadFoot	HeadFoot	HeadFoot

blank table title
HeadFoot	HeadFoot	HeadFoot
TopLeft TopLeft TopLeft	TopLeft	TopLeft
TopLeft Body	TopCtr	TopRight
TopLeft Body	TopLeft TopLeft TopLeft	TopCtr
Body1 Body1 Body1 Body1 Body1 Body1	TopCtr Body	TopCtr TopLeft
HeadFoot	HeadFoot	HeadFoot

The following table with blank format uses box drawing characters and text aligned in columns. All the cells which contain nothing but box drawing characters use the MonoSans paragraph format.

The following six formats produce very basic tables, with the minimum of decoration, even defaulting to no Title and no headers/footers (which could be overridden). Three of the formats align the table itself to the left, and the three whose names contain “Ctr” center the entire table. All have no spacing above and below which could be provided with empty paragraphs, and all borders except the header/footer separators are thin lines.

The trailing character on the names indicate their imposed CSS vertical paragraph alignments: B = bottom, M = middle, and T = top. All these FM tables’ paragraph formats default to Title (if a title is included), HeadFoot (if headers/footers included). Finally the default cell paragraphs are those formats with specific FM vertical alignments to match that of the CSS table formatting, B = BotLeft, M = MidLeft or T = Body1, although TopLeft may work better with its reduced top margin. These tables are primarily intended for limited narrative text in the cells.

For these two basicB tables CSS will impose bottom paragraph alignment. Be sure not to end the last paragraph with a CR when the vertical alignment is bottom since line spacing will keep it from being at the bottom of the cell. An example of the basicCtrB table is demonstrated later with all the basicCtr* centered tables.

basicB table
Head row one	Head
BotLeft BotLeft BotLeft	BotLeft with trailing CR
BotLeft to get the row to expand	BotLeft
BotCtrSans BotLeft BotIndent BotLeft	BotCtr BotLeftSans
BotLeft BotLeft BotLeft	BotRight BotIndent
HeadFoot	HeadFoot/bold
HeadFoot	HeadFoot/bold

The basicM and basicCtrM table CSS should result in the normal default of middle paragraph alignment without override settings, but I include them just to be certain. Be sure not to end the last paragraph with a CR when the vertical alignment is middle since that line spacing will raise the lines up from the middle of the cell. An example of the basicCtrM table is demonstrated later with all basicCtr* centered tables.

basicM table
HeadFoot	HeadFoot/bold
MidLeft MidLeft Body1	MidCtr
MidLeft MidIndent Really long line to show indentation when the line wraps to the next line due to it being a long line to show indentation Body1	MidCtr with trailing CR
Long MidRight Longer MidRight Really long line with forced CR line breaks to show the next line is right justified	MidLeft
MidLeft	MidCtr

The basicT table CSS will impose top paragraph alignment, with default of Body1 although TopLeft may work better with its reduced top margin. An example of the basicCtrT table is demonstrated later with all basicCtr* centered tables.

HeadFoot/bold	HeadFoot
Body1 Body 25 with a TableFootnote	Body1 Indent subindent
singleline singleline singleline singleline	TopCtr
• bullet • subbullet	TopRight Body1
e-mail	TopRight TopCtr
TopLeft Body	Body1 Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight Body1
TopLeft Body Body	Body1 Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
HeadFoot	HeadFoot/bold

Title of basicT
HeadFoot/bold	HeadFoot
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
e-mail	TopRight TopCtr
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight Body1
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
HeadFoot	HeadFoot/bold

The three following basicT tables are used to demonstrate the automatic sizing of the height of table cells as a function of the “maximum” height of the contents of the cell which is affected by character overrides.

Test font overrides of font size & cell height —
“small” format: 9pt | (smaller) 0.75rem

Test font overrides of font size & cell height —
“large” format: 16pt | (larger) 1.25em

To provide for all options I have come to desire, these three separate table formats which are based on their companion “basic” formats have the table aligned center. Their CSS is the same as above for the three vertical alignments, but adds the CSS to center the table. Since the tables are to be centered, the additional HTML div container also will be inserted if the table is to be scrolled. These three table format are designed to have the paragraph formats with the matching FM paragraph vertical alignments. One special use of a T-basicCtrB table with a data cell paragraph format of BotRight is to produce a table of right-aligned numbers with possibly some right-aligned total in a footer, so that paragraph format is the default for that table’s data cells.

basicCtrB table
BotRight BotRight BotRight	1,473
BotRight to get the row to expand. enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand.	262
enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand.	3,014
enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand.	507
HeadFoot for description or BotRight for total	5,256

basicCtrM table
HeadFoot	HeadFoot/bold
MidLeft MidLeft Body1	MidCtr
Long MidRight Longer MidRight	MidLeft
MidLeft	MidCtr

basicCtrT table
HeadFoot/bold	HeadFoot
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
e-mail	TopRight TopCtr
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight Body1
HeadFoot	HeadFoot/bold

basicCtrT scroll table title
HeadFoot/bold	HeadFoot
Second Head	Head
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
e-mail	TopRight TopCtr
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight Body1
TopLeft Body	TopLeft Indent subindent
singleline singleline	TopCtr
• bullet • subbullet	TopRight TopLeft
HeadFoot	HeadFoot/bold

I have defined three similar fully decorated table formats (T-FormatB, T-FormatM, and T-FormatT) which provide the three vertical alignments of paragraphs in the data cells: Bottom, Middle, Top. All three are designed to have a “formal” publishable look, all will center if the total width is less than the screen. Since the table is to be centered, the additional HTML div container will be inserted if identified to be scrolled. All default to having a title with a header and footer row, with solid black borders and double lines for header/footer separators. As such they share considerable FM and CSS settings, but differ as appropriate with their different vertical paragraph alignments.

This is the first of the three similar fully decorated table formats. The FormatB table’s CSS will impose bottom paragraph alignment. This FM table’s paragraph formats default to Title, HeadFoot, BotLeft, and HeadFoot. Depending upon the data entered in the data cells of a specific table, BotRight or BotCtr paragraphs may be used. If more than one paragraph is entered in a cell, blank paragraphs may be desired in front of the second and subsequent paragraphs for spacing. Be sure not to end the last paragraph with a CR when the vertical alignment is bottom since line spacing will keep it from being at the bottom of the cell.

FormatB table title
MidLeft/bold	HeadFoot
BotLeft BotLeft BotLeft	BotRight
BotLeft to get the row to expand. enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand.	BotLeft
enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand.	BotCtr
enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand. enough text to get the row to expand.	BotRight with CR
HeadFoot HeadFoot HeadFoot	HeadFoot/bold

This is the second of the three similar fully decorated table formats. The FormatM table’s CSS will impose middle paragraph alignment. This FM table’s paragraph formats default to Title, HeadFoot, MidLeft, and HeadFoot. Depending upon the data entered in the data cells of a specific table, MidRight or MidCtr paragraphs may be used. If more than one paragraph is entered in a cell, blank paragraphs may be desired in front of the second and subsequent paragraphs for spacing. Be sure not to end the last paragraph with a CR when the vertical alignment is middle since that line spacing will raise the lines up from the middle of the cell.

The FormatM table will simply use the default of middle paragraph alignment, so no override required.

FormatM table
HeadFoot	HeadFoot HeadFoot HeadFoot	HeadFoot/bold
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft with CR
MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
HeadFoot HeadFoot HeadFoot	HeadFoot/bold	HeadFoot

FormatM scroll table title
HeadFoot	HeadFoot HeadFoot HeadFoot	HeadFoot/bold
HeadFoot	HeadFoot	HeadFoot/bold
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft with CR
MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
MidLeft MidLeft Body1	MidCtr	MidLeft
Long MidRight	MidLeft	MidRight
MidLeft	MidCtr	MidCtr
HeadFoot HeadFoot HeadFoot	HeadFoot/bold	HeadFoot

This is the third of the three similar fully decorated table formats. The FormatT table’s CSS will impose top paragraph alignment. This FM table’s paragraph formats default to Title, HeadFoot, Body1, and HeadFoot, although TopLeft for the table cells may work better with its reduced top margin. If more than one paragraph is entered in a cell, the subsequent paragraphs will default to the Body format. Depending upon the data entered in the data cells of a specific table, TopCtr or TopRight paragraphs may be used. If more than one paragraph is entered in a cell using those formats, blank paragraphs may be desired in front of the second and subsequent paragraphs for spacing.

FormatT table
HeadFoot HeadFoot HeadFoot	HeadFoot/bold
TopLeft Body	TopLeft
singleline small	1. number1 doesn’t work with its spacing above 2. number
• bullet1 • subbullet1	indent1 1) subnumber1
Topic doesn’t work TopLeft	TopRight TopCtr
HeadFoot	HeadFoot HeadFoot HeadFoot

For a collection of web pages all on the same topic, such as my TMG book, I often find it useful to create a single separate web page which is an Index to the entire collection of web pages on this topic. Such index HTML web pages are the only places I use the special custom paragraph and character formats described below. I make the index entries in this single page to be hyperlinks to all the topics across all the web pages in the collection. I also use separate hyperlink “targets” for the Index page versus the collection’s content pages so that the Index will remain open as a separate browser tab from the tab displaying a content page.

I choose to use what is known as the “Indent” or “Stacked” style of an index, which is generally preferred for reference works, and basically follow the indexing rules from the Chicago Manual Of Style 26 (referred to below as the Manual). Rather than including page numbers (which typically don’t exist within a web document), an electronic Index can make the text itself of each index entry for a referenced heading or subheading be a direct hyperlink to the beginning of that subject within the appropriate content web page. The overall format of my Index page consists of three major parts:

• Letters in an alphabet jumpbar with responsive code which always keeps it visible on the screen. Each letter links to the top of the entries within this Index beginning with that letter of the alphabet.

• Topic index entries which consist of Main entries and up to three levels of Subheading entries. Each entry links to the location within a content web page of the discussion of that main or subheading topic.

The entries in the Index are sorted alphabetically by only the Main entries, with its Subheadings grouped under each Main entry. By using special custom FM formats, special HTML inserted by my custom Perl program, and custom CSS for these inserted HTML elements, an “alphabet jumpbar” has been created of the letters of the alphabet. While complex to figure out how to accomplish this, it has been a great aid in finding entries in the Index.

In FM the jumpbar is inserted first by including a single separate Navigate paragraph. This paragraph is placed after the overall introduction and heading paragraphs in the Index document. All the paragraphs of the individual index entries, including the index letter separators, are then placed after this Navigate paragraph. The Reference Pages HTML Mapping Table sets the XML Element of this paragraph format to the custom name NAV instead of a P for paragraph. Thus the FM conversion brackets this paragraph’s text with the HTML element <NAV CLASS="Navigate">…</NAV> which can be uniquely recognized in the Perl post-processing script.

The Navigate paragraph only contains each uppercase letter of the alphabet, where each letter is followed by a single separator space. Each letter (but not the space) has the override character format menuletter. The character format is required not only to style each letter as a button, but also to restrict a separate hyperlink (placed within this letter’s override character format) to each letter which links to that letter’s separator paragraph within the following list of index entries. With a lack of imagination the “names” of these hyperlinks are simply that uppercase letter of the alphabet.

Finally in FM a separate IndexLetter separator paragraph for each letter of the alphabet is placed before the paragraph of the first Main entry which begins with that letter. (Even if there are no Main entries for that letter I create a separator paragraph for every letter.) This IndexLetter paragraph only contains that uppercase letter of the alphabet followed by a space. That letter (but not the space) has the override character format indexLtr. The character format is required to style this letter to look similar to that letter’s jumpbar button. The paragraph begins with a named destination hyperlink which is the target of that letter’s jumpbar button link.

With the custom FM formats, the post-processing Perl script identifies the presence and location of the Navigate paragraph. It can then add HTML elements before that paragraph, between that paragraph and the index entry paragraphs, and after the last entry paragraph. These elements identify what is the jumpbar, and what constitutes the scrolled entries. The overall structure of the HTML thus conceptually becomes:

These consist of a Main entry and up to three levels of Subheading entries. These will use the paragraph formats with the imaginative names: IndexMain, IndexSub1, IndexSub2, and IndexSub3. The Main entry is usually a broad topic with a single link to the beginning of that discussion. A Subentry will often have multiple headings each linked to their separate subtopic. There can be further subordinate entries if a given subtopic is discussed in sufficient detail to have futher subdivisions. The Manual suggests “The first word of a main heading is normally capitalized only if capitalized in text”. As they are usually capitalized section headings I generally choose to capitalize Main headings. The Manual also suggests “Subentries are always lowercased”. I again may choose to capitalize them if they are a capitalized topic heading, but if it is a specific term I enter it however it is typically used.

For an entry with many Subordinate entries, the identifying higher level entries may have scrolled off the browser page. For this reason I have chosen Subordinate entry paragraph styles which visually indicate their subordinate level. Subenties are successively more indented and begin with a special character indicating their level (first level: a single dot ‘•’, second level: a double arrow ‘»’, third level: a triple line ‘≡’) . All four levels are in different fonts (Main: Sans-Serif bold, first: Serif bold, second: Sans-Serif regular, third: Serif regular) as shown below:

For a given topic entry within the index, whether Main or Subordinate, the Manual recommends there be at most one each of these two types of cross-reference entries associated with a given topic, and entered in the order of “See” then “See also”. Both of these types of entries provide links within this index to one or more index entries which are different than their parent topic or subtopic of this cross-reference. These do not link to a place within any content page. The Manual suggests that styling of (only) the text “See” and “See also” should be a different font than the following referenced index entry, usually italic versus roman. Thus all cross-reference paragraphs use Serif regular as their font, and I manually apply italics and any other necessary font styling. The Manual only suggests enclosing a cross-reference entry in parentheses if it is under a subordinate entry, but due to this Indent style where they all are indented subordinate to their main entry, I choose to enclose all cross-reference entries in parentheses. Both these types of cross-reference entries should be subordinate to and follow the associated actual topic entry link(s), whether Main or Subordinate. But they should come before any subsquent Subordinate topic entry link(s). Therefore I use the similarly named See paragraph style to immediately follow the associated Index entry paragraph being cross-referenced. Any Subordinate topic index links will then follow using the next level IndexSub paragraph format possibly followed by its cross-reference entries. [See also the similar structure of the DefTerm, DefTermSee, Definition, DefinitionSee set of paragraphs.]

For both of these types of cross-reference entries the text of the referenced index entry must be identical to how its linked-to text appears at its alphabetical place within this index. While referencing a Main topic is clear, there are several alternative styles to reference a Subtopic. I choose to enter not only the text of the Subtopic but also the text of all higher levels. The text of each level is entered starting with the Main topic, then each Subtopic, separated by colons.

The one “See” cross-reference for an entry usually links to only one different index entry which has my choice of the preferred phrasing of this topic, and is where the actual entries with link(s) to the content for this topic will be found. Styling indicates an exception should be made if that preferred entry has few links or subordinate topics. In this exception a “See” entry should not be used. Instead in this minimalist case this alternate phrase should be an actual index entry, but the (exact) text of the preferred index entry should appear in parentheses following this entry’s phrase, and any link(s) duplicated. I do not always follow this suggestion since if the entries would be identical I choose to have only the preferred entry have any link(s).

Unlike the “See” entry, the one “See also” entry can link to one or more index entries similar to this topic which may also be of interest. These links are entered one after another, separated by semicolons, and usually alphabetically which I tend to use, but “could” be in the order of most to least similar.

Since the IndexSub paragraphs will have an outdent, the widths of the outdent and the subsequent margins must be determined by a process similar to that for the Bullet and Number paragraphs described above. Since the IndexSub1 paragraph begins at the left margin its process will be similar to those two main paragraphs, except that characters in the outdent are different. I do not precede the bullet with a space, and I follow the bullet with the smaller enspace as part of making all Index indents smaller.

• Create a multiline IndexSub1 FM paragraph and convert it to HTML to view in my browser.

• Manually make the negative CSS text-indent the same value as the positive margin-left value in rem units to keep the zero left margin. Now adjust that common value to make the text following the bullet visually match where the text on the following line begins.

Since both IndexSub2 and IndexSub3 use different outdent marker characters than IndexSub1 their outdent widths are a bit different. Thus their outdent widths must be separately determined. Values should be used to cause their first line left margin to match the margin-left value of the parent index level. This is accomplished by choosing trial values which make of the sum of the actual values of this paragraph’s text-indent and margin-left (i.e. margin minus indent) equal to the value of the parent’s margin-left.

• With these trial values, now manually adjust these two CSS rem values to make the text following the bullet match where the text on the following line begins, while keeping the sum of the actual values the same. This is accomplished by adding or subtracting the same absolute value from each parameter.

• Next use all the above determined rem values of these three IndexSub paragraphs to compute their equivalent pt values needed to set all their First and Left Indents in FM.

Finally each See paragraph’s left margin should be set the same as the left margin of the text (not the outdent) of its parent Index entry. As these have no outdent all their text-indent values will be zero. Thus for CSS their margin-left value will be the same as that of their parent, and their FM First and Left values will be that same value in pt.

Note that for regular paragraphs I have set FM to convert a tab character to a hidden image of fixed width which will not produce the (smaller) outdent width of these Index paragraphs. Therefore none of these FM paragraphs define tab stops as a reminder not to use tabs with them. Since a “See” paragraph left-aligns with the text of its parent Index paragraph, if continuation paragraphs of matching text indent are desired these should be used while adjusting any font as needed.

The following describes all the paragraph formats used in an Index using the standard parameter templates described above.

This is an IndexLetter para
[space: 5, 0, 15.6 | 0.4rem, 0, --base] (no tabs)
[font: 16pt, Inconsolata Semi, DemiBold, Stretch: 125% | 1.3333rem, Inconsolata-w-local, 600]
with “Next Paragraph Tag” of IndexMain

It is used solely for each single letter of the alphabet as a separator/divider placed before the first internal main entry within an Index that begins with that letter. It expects its only content to be a single letter using the indexLtr character format followed by a space.

This is an IndexMain para [space: 5, 0, 15.6 | 0.4rem, 0, --base] (no tabs)
[font: FreeSans, DemiBold | FreeSans-local, bold]
with “Next Paragraph Tag” of IndexSub1

This is an (IndexMainSee in parens with only one link)
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)
with “Next Paragraph Tag” of IndexMain and “Keep With Previous Paragraph”

• This is an IndexSub1 para, Autonumbered=[•\sn]
(Indent: 0, 14.16pt, 0 | -1.18rem, 1.18rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)
[font: SemiBold | bold]

This is an (IndexSub1See in parens with one or more links)
(Indent: 14.16pt, 14.16pt, 0 | 0, 1.18rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)
with “Next Paragraph Tag” of IndexSub1 and “Keep With Previous Paragraph”

» This is an IndexSub2 para, Autonumbered=[»\sn]
(Indent: 14.16pt, 25.98pt | -0.985rem, 2.165rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)
[font: 12pt, FreeSans | FreeSans-local]
and altered vertical alignment with “Next Paragraph Tag” of IndexSub3

This is an (IndexSub2See in parens with one or more links)
(Indent: 25.98pt, 25.98pt | 0, 2.165rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)
with “Next Paragraph Tag” of IndexSub2 and “Keep With Previous Paragraph

≡ This is an IndexSub3 para, Autonumbered=[≡\sn]
(Indent: 25.98pt, 44.625pt | -1.556rem, 3.721rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)

This is an (IndexSub3See in parens with one or more links)
(Indent: 44.625pt, 44.625pt | 0, 3.721rem, 0)
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)
with “Next Paragraph Tag” of IndexSub3 and “Keep With Previous Paragraph

As mentioned above, the Navigate “paragraph” defines the alphabet jumpbar, and its unique XML Element on HTML conversion is used by the Perl script to insert HTML div elements required for this special construct. For FM purposes this placeholder paragraph is simply formatted
[space: 0, 0, 15.6 | 0, 0, --base] (no tabs)

The major characteristic of the jumpbar produced by the presence of the Navigate element is that it is fixed horizontally at the top of a sufficiently wide browser window, such as most monitors or tablets. The Index content then scrolls full width below this fixed jumpbar. This is accomplished using the CSS below for the Navigate element and those div elements inserted.

If CSS recognizes that the window gets too narrow (max width 630px = 39.375rem, e.g. a smart phone in portrait mode), conditional CSS @media code will instead fix the jumpbar vertically at the left side of the window with the content scrolling the full height on the right, using the following CSS.

The indexLtr character format settings in FM are:
[font: 16pt, Inconsolata SemiBold, DemiBold, Background: Cyan, Stretch: 125%]
As mentioned above, this format is only ever set on the single letter of the alphabet within the IndexLetter paragraph. [While set to a fixed size of 16pt in FM, by using rem the CSS will set the font size depending upon the default font size of the browser.] The format is placed on both the prefixed hypertext link anchor and the letter, and is followed by a space in the default font. To provide some visual similarity to the CSS settings the FM format sets the Background to Cyan. Its equivalent CSS is below, and the extra CSS places it in a colored button (defined blue by the CSS variable --button-color) identical to the letters in the Jumpbar.

As further described above, these examples show each indexLtr character format in their IndexLetter paragraph placed at the head of those index Main entries which begin with that letter of the alphabet.

The above letters use menuletter character format settings in FM are:
[font: 16pt, Inconsolata SemiBold, DemiBold, underlined, Background: Cyan, Stretch: 125%]
As mentioned above, the format is applied as an override separately on each letter and its prefixed hyperlink, but not the following separating space. [While set to a fixed size of 16pt in FM, by using rem the CSS will set the font size depending upon the default font size of the browser.] This format is only ever used for the complete set of the letters of the alphabet in the sole Navigate paragraph in an Index document which forms the Index alphabet jumpbar. (For the purposes of displaying this example they are in a special test “Navigate-like” paragraph.) Each letter’s hyperlink is to its companion letter in its IndexLetter paragraph. To provide some visual similarity to the CSS settings the FM format sets the Background to Cyan and is underlined like a hyperlink. Its equivalent CSS is below. Extra CSS is assigned to the hyperlink anchor which places each jumpbar letter within a clickable colored button (defined blue by the CSS variable --button-color).

Endnotes
1. For more information about the Perl© programming language see the Perl.org website https://www.perl.org/. Throughout the rest of this document for formatting convenience I do not append the copyright symbol. 2. The exact case-sensitive filename and extension “index.html” is the standard default document a web server will open if a URL is just to a directory, such as to the top of a site or to a folder on that site. What special document name will be served is configurable in the web server, but my site’s server uses this standard default name. 3. My comments about fonts in this document are focused on HTML display in a web page. Thus I try to have these pages link to the .woff2 version of the fonts for HTML display. Fonts defined for display on a desktop, laptop, tablet, or phone or to be printed to a given brand of printer are a completely separate issue and are likely to be limited by that device or brand. For example while the modern .otf version of the FreeSans family can be installed in Windows, only the older .ttf version will print on my HP Color printer so I had to install that version instead on Windows for use by FM. 4. The New Century Schoolbook, version C059, set of otf and ttf files was downloaded in 2023 as part of the URW++ Core 35 fonts, Version 2.0 using the URL https://www.freefonts.io/wp-content/uploads/2020/07/new-century-schoolbook.zip. 5. The FreeSans, version 20120503, is available from the GNU FreeFont project with a home page at https://savannah.gnu.org/projects/freefont/. Its sets of file types of woff, otf and ttf were downloaded in 2023 using the URL http://ftp.gnu.org/gnu/freefont/. This font family’s files were contained within the respective .zip or .tar.gz packages for each file type, 6. The Inconsolata, version v31, set of font-face files was downloaded in 2023 with a forced font-width of 125% using the URL https://fonts.googleapis.com/css2?family=Inconsolata:wdth,wght@125,400..900 which in turn contained the URLs of the woff2 files to download. 7. The Courier Prime, version v7, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Courier+Prime:ital,wght@0,400;0,700;1,400;1,700 which in turn contained the URLs of the woff2 files to download. 8. The Noto Sans Mono, version v21, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Noto+Sans+Mono:wght@100..900 which in turn contained the URLs of the woff2 files to download. 9. The Symbola, version 13, single otf file was downloaded in 2023 using the URL https://github.com/ChiefMikeK/ttf-symbola/blob/master/Symbola-13.otf. 10. The FreeMono, version 20120503, is available from the GNU FreeFont project with a home page at https://savannah.gnu.org/projects/freefont/. Its sets of file types of woff, otf and ttf were downloaded in 2023 using the URL http://ftp.gnu.org/gnu/freefont/. This font family’s files were contained within the respective .zip or .tar.gz packages for each file type, 11. The Noto Emoji, version 34, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Noto+Emoji:wght@300..700 which in turn contained the URLs of the woff2 files to download. 12. The Noto Color Emoji, version 24, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Noto+Color+Emoji which in turn contained the URLs of the woff2 files to download. 13. This altered vertical alignment only seems to appear in HTML and not in FM, so I only modify the CSS. 14. While an HTML or CSS file can override the brower’s default rem value, doing so is discouraged so that the font size set in the browser by the user remains the base default. All my HTML and CSS files ensure using that default for this variable. This is a following paragraph of IndentFoot. 15. I currently don’t define an indented paragraph with a margin at this fourth indent. However if I have a rare case which needs it, I can cause this indent by using leading tabs on any paragraph with 12pt font. Therefore in FM I do set a tab stop at this value. 16. This is another actual footnote to test the Footnote paragraph left margin alignment. I make the paragraph long enough so that I am sure that it extends to a second line and thus shows the left margin alignment to the outdented footnote number. This is the continuation IndentFoot paragraph which aligns at the same left margin as the Footnote paragraph’s indented text. 17. While an HTML or CSS file can override the brower’s default rem value, doing so is discouraged so that the font size set in the browser by the user remains the base default. All my HTML and CSS files ensure using the browser setting for this variable. 18. Since MS Word combines both paragraph and character format names into a single catalog, I now use this naming scheme of initial uppercase for paragraph formats and initial lowercase for character formats to clearly distinguish between these two types of formats in both programs. 19. This is a footnote on internal page one. 20. This is an actual footnote to test the Footnote paragraph left margin alignment. I make the paragraph long enough so that I am sure that it extends to a second line. This is the continuation IndentFoot paragraph which aligns at the same left margin as the Footnote paragraph’s indented text. 21. Since MS Word combines both paragraph and character format names into a single catalog, I now use this naming scheme of initial uppercase for paragraph formats and initial lowercase for character formats to distinguish between these two types of formats in both programs. 22. This is a footnote on the internal text for the bold character format. 23. While the definitions use the term “right” to indicate a stroke on the right side of the character, the HTML entity name used “right” to indicate a character bounding the right side of a box. 24. For a useful table of various space characters see: https://jkorpela.fi/chars/spaces.html 25. This is a TableFootnote in a BasicT table to test the paragraph’s left margin alignment. Note that in FM the right margin is an indent from the right edge of its table, rather than the overall right text boundary. I make the paragraph long enough so that I am sure that it extends to a second line. Since it is late in the list of endnotes with a double digit number it also demonstrates that the space between the footnote number and first line text is fixed. Therefore the beginning of the text of that first line does not line up with the left margin of the subsequent text. This is the continuation IndentFoot paragraph which aligns to the TableFootnote at the same text left and right margins. 26. I used The Chicago Manual of Style, 15th Edition. Chicago and London: The University of Chicago Press, 2003. Chapter 18, Indexes. See also Chapter 15, Indexes in the latest edition available on-line: https://www.chicagomanualofstyle.org

Endnotes

1. For more information about the Perl© programming language see the Perl.org website https://www.perl.org/. Throughout the rest of this document for formatting convenience I do not append the copyright symbol.

2. The exact case-sensitive filename and extension “index.html” is the standard default document a web server will open if a URL is just to a directory, such as to the top of a site or to a folder on that site. What special document name will be served is configurable in the web server, but my site’s server uses this standard default name.

3. My comments about fonts in this document are focused on HTML display in a web page. Thus I try to have these pages link to the .woff2 version of the fonts for HTML display. Fonts defined for display on a desktop, laptop, tablet, or phone or to be printed to a given brand of printer are a completely separate issue and are likely to be limited by that device or brand. For example while the modern .otf version of the FreeSans family can be installed in Windows, only the older .ttf version will print on my HP Color printer so I had to install that version instead on Windows for use by FM.

4. The New Century Schoolbook, version C059, set of otf and ttf files was downloaded in 2023 as part of the URW++ Core 35 fonts, Version 2.0 using the URL https://www.freefonts.io/wp-content/uploads/2020/07/new-century-schoolbook.zip.

5. The FreeSans, version 20120503, is available from the GNU FreeFont project with a home page at https://savannah.gnu.org/projects/freefont/. Its sets of file types of woff, otf and ttf were downloaded in 2023 using the URL http://ftp.gnu.org/gnu/freefont/. This font family’s files were contained within the respective .zip or .tar.gz packages for each file type,

6. The Inconsolata, version v31, set of font-face files was downloaded in 2023 with a forced font-width of 125% using the URL https://fonts.googleapis.com/css2?family=Inconsolata:wdth,wght@125,400..900 which in turn contained the URLs of the woff2 files to download.

7. The Courier Prime, version v7, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Courier+Prime:ital,wght@0,400;0,700;1,400;1,700 which in turn contained the URLs of the woff2 files to download.

8. The Noto Sans Mono, version v21, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Noto+Sans+Mono:wght@100..900 which in turn contained the URLs of the woff2 files to download.

9. The Symbola, version 13, single otf file was downloaded in 2023 using the URL https://github.com/ChiefMikeK/ttf-symbola/blob/master/Symbola-13.otf.

10. The FreeMono, version 20120503, is available from the GNU FreeFont project with a home page at https://savannah.gnu.org/projects/freefont/. Its sets of file types of woff, otf and ttf were downloaded in 2023 using the URL http://ftp.gnu.org/gnu/freefont/. This font family’s files were contained within the respective .zip or .tar.gz packages for each file type,

11. The Noto Emoji, version 34, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Noto+Emoji:wght@300..700 which in turn contained the URLs of the woff2 files to download.

12. The Noto Color Emoji, version 24, set of font-face files was downloaded in 2023 using the URL https://fonts.googleapis.com/css2?family=Noto+Color+Emoji which in turn contained the URLs of the woff2 files to download.

13. This altered vertical alignment only seems to appear in HTML and not in FM, so I only modify the CSS.

14. While an HTML or CSS file can override the brower’s default rem value, doing so is discouraged so that the font size set in the browser by the user remains the base default. All my HTML and CSS files ensure using that default for this variable.

This is a following paragraph of IndentFoot.

15. I currently don’t define an indented paragraph with a margin at this fourth indent. However if I have a rare case which needs it, I can cause this indent by using leading tabs on any paragraph with 12pt font. Therefore in FM I do set a tab stop at this value.

16. This is another actual footnote to test the Footnote paragraph left margin alignment. I make the paragraph long enough so that I am sure that it extends to a second line and thus shows the left margin alignment to the outdented footnote number.

This is the continuation IndentFoot paragraph which aligns at the same left margin as the Footnote paragraph’s indented text.

17. While an HTML or CSS file can override the brower’s default rem value, doing so is discouraged so that the font size set in the browser by the user remains the base default. All my HTML and CSS files ensure using the browser setting for this variable.

18. Since MS Word combines both paragraph and character format names into a single catalog, I now use this naming scheme of initial uppercase for paragraph formats and initial lowercase for character formats to clearly distinguish between these two types of formats in both programs.

19. This is a footnote on internal page one.

20. This is an actual footnote to test the Footnote paragraph left margin alignment. I make the paragraph long enough so that I am sure that it extends to a second line.

This is the continuation IndentFoot paragraph which aligns at the same left margin as the Footnote paragraph’s indented text.

21. Since MS Word combines both paragraph and character format names into a single catalog, I now use this naming scheme of initial uppercase for paragraph formats and initial lowercase for character formats to distinguish between these two types of formats in both programs.

22. This is a footnote on the internal text for the bold character format.

23. While the definitions use the term “right” to indicate a stroke on the right side of the character, the HTML entity name used “right” to indicate a character bounding the right side of a box.

24. For a useful table of various space characters see: https://jkorpela.fi/chars/spaces.html

25. This is a TableFootnote in a BasicT table to test the paragraph’s left margin alignment. Note that in FM the right margin is an indent from the right edge of its table, rather than the overall right text boundary. I make the paragraph long enough so that I am sure that it extends to a second line. Since it is late in the list of endnotes with a double digit number it also demonstrates that the space between the footnote number and first line text is fixed. Therefore the beginning of the text of that first line does not line up with the left margin of the subsequent text.

This is the continuation IndentFoot paragraph which aligns to the TableFootnote at the same text left and right margins.

26. I used The Chicago Manual of Style, 15th Edition. Chicago and London: The University of Chicago Press, 2003. Chapter 18, Indexes. See also Chapter 15, Indexes in the latest edition available on-line: https://www.chicagomanualofstyle.org

I do not warrant in any way that this document is accurate or useful, and any use of it is at the user’s own risk.

As described in this document, it was composed with Adobe® FrameMaker 2019®, converted using its hyperlink and "Save as HTML" features, post-processed with my custom Perl© script, linked to my Responsive CSS file, and the HTML and CSS are W3C validated.

Book All: Types
├──	Book Multi: All entities
│	├──	Book *Multi: IN
│	│	+Indiana (Src/NC Link)
│	│	├──	Book *Multi: IN Adams&Wells 1887
│	│	│	└──	Book Multi: IN Adams&Wells 1887; Wells
│	│	│		+Wells County, Indiana (Src/NC Link)
│	│	│		└──	Book *Multi: IN Adams & Wells 1887; Wells, Biog
│	│	│			└──	Gabriel Markley (b1758, Book Biog)
│	│	└──	Book *Multi: IN Adams&Wells 1918 0928360
│	│		└──	Book Multi: IN Adams & Wells 1918; Wells
│	│			+Wells County, Indiana (Src/NC Link)
│	│			└──	Book *Multi: IN Adams & Wells 1918; Wells, Biog
│	│				├──	William Henry Thompson (b1853, Book Biog)
│	│				├──	Thomas Josiah Settle (b1878, Book Biog)
│	│				└──	Dennis Alberson (b1864, Book Biog)
│	└──	Book *Multi: OH
│		+Ohio (Src/NC Link)
└──	Book Biog: *All entities

Head row one	Head
Head row two	Head
BotLeft BotLeft BotLeft	BotLeft with trailing CR
BotLeft to get the row to expand	BotLeft
BotCtrSans BotLeft BotIndent BotLeft	BotCtr BotLeftSans
BotLeft BotLeft BotLeft	BotRight BotIndent
HeadFoot	HeadFoot/bold
HeadFoot	HeadFoot/bold

Body1 = 12pt	Body1 = 1.0rem
Body1	Body1
Title = 14pt	Title = 1.667rem
Title	Title
Singleline = 12pt	Singleline font = 1.0rem
Singleline	Singleline
Major = 18pt	Major = 1.5rem
Major	Major
Halfline = 12pt	Halfline = 1.0rem
Halfline	Halfline
Computer = 12pt	Computer = 1.0rem
Computer	Computer
Footnote = 10pt	Footnote = 0.8333rem
Footnote	Footnote
Small = 10pt	Small = 0.8333rem
Small	Small