bugGNU roff - Bugs: bug #42473, \(sq is historically a filled...


bug #42473: \(sq is historically a filled square if the font is bold

Submitter:  Ralph Corderoy <ralph>
Submitted:  Sat 31 May 2014 11:37:23 AM UTC
Category:  Font devps Severity:  2 - Minor
Item Group:  Incorrect behaviour Status:  Rejected
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Tue 07 Jun 2022 11:46:09 PM UTC, comment #8: 

Commit f15ea35c further refined the documentation about this.

Dave <barx>
Group Member
Mon 06 Jun 2022 07:24:17 AM UTC, comment #7: 

I keep finding things.  (I should probably stop and take a breath but this document dump of the "Unix 4.0" manuals is like a kid's Christmas for me.)
I now think the filled-ness of the \(sq glyph in boldface was device-dependent.

Why?  See the annotated table of contents for the aforementioned manuals.


I'll "quote" it with another attachment.

For those without image support, it appears these manuals were typeset with the Autologic APS-5, one of the first targets for device-independent troff (after the C/A/T).

This also explains the addition of the word "original" before "Special Mathematical Font" in the explanatory paragraph for Table 1 in comment #4.  Contrast with the same paragraph in comment #3.

This is also consistent with the Murray Hill Bell Labs folks being so keen to reverse engineer the font data format as documented in the famous, and for a long time samizdat, paper "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" by Condon, Kernighan, and Thompson.  Why pay a foundry exorbitant prices to code you a bespoke typeface when you can do it yourself?


G. Branden Robinson <gbranden>
Group administrator
Mon 06 Jun 2022 07:07:40 AM UTC, comment #6: 

Changing Status to "Wont Fix" as the original report was not, in fact, invalid as I suspected it to be.

Instead, my decision is to cravenly genuflect at the altar of Unicode and its distinction between U+25A0 and U+25A1.

A recipe for redefining a special character on a style-specific basis would be a good thing to have in our Texinfo manual.

G. Branden Robinson <gbranden>
Group administrator
Mon 06 Jun 2022 07:03:05 AM UTC, comment #5: 


I didn't even look carefully at my own exhibit!

This is fascinating.  We may have found the very point at which that bold square did become bold...with device-independent troff!

It doesn't change my mind, but it vindicates the original commentary.

G. Branden Robinson <gbranden>
Group administrator
Mon 06 Jun 2022 07:00:45 AM UTC, comment #4: 

Now we have a 1981 version of the Nroff/Troff User's Manual as further attestation that the Times bold square was not filled.

The Unix Historical Society (TUHS) helpfully has a copy available.


It's worth noting that Ossanna's text was updated, possibly by Kernighan, even though the document date was left the same (11 October '76).  Compared to the other version I attached, which was published later but documented an earlier version of the Unix system, we can see that Wang Laboratories' acquisition of Graphic Systems's phototypesetting business was recognized.

See attachments, or the link above.  Closing as invalid.

G. Branden Robinson <gbranden>
Group administrator
Mon 23 May 2022 01:14:01 AM UTC, comment #3: 

I question the provenance of the troff used in the original report to the mailing list.

It appears that V7 troff did not behave this way, if we go by ISBN 0-03-061743-X.

> Apparently, \(sq is normally an empty square, as shown in CSTR 54, but filled if the font is bold.  That's with 7th Edition troff

I'd like to know how the above claim was substantiated without access to the C/A/T's photographic plate for the Times Bold face, or to camera-ready copy from same--however the latter is precisely what we appear to have in the form of Volume 2 of the Seventh Edition Unix manuals, and that evidence directly contradicts the claim.

See attachment.

There is a re-typeset version of V7 Volume 2 floating around on the Internet.  It is wrong.  The little rectangles indicating unavailable glyphs betray its inauthentic origin.  Recent versions of the groff_char(7) man page warn about this.

Considering history since 1991, Unicode doesn't unify outlined and filled squares, and I think that should factor into how we define '\(sq' for groff.

Setting Status to "Need Info".  I intend to close this ticket as invalid if compelling information is not brought to light.

G. Branden Robinson <gbranden>
Group administrator
Fri 18 Mar 2022 06:06:29 PM UTC, comment #2: 

This text now hedges.  Commit db02fba9 added "according to some sources" to that last sentence.  A potentially opposing source is cited in a source-code comment.

Dave <barx>
Group Member
Sat 26 Feb 2022 05:08:19 PM UTC, comment #1: 

Some of the "History" section added to groff_char(7) in commit 03ed6b71 may be relevant to this.  It reads, in part:

"A consideration of the typefaces originally available to AT&T nroff and troff illuminates many conventions that one might regard as idiosyncratic fifty years afterward. ... A representation of the coverage of the C/A/T's text fonts follows. ... In bold, the square became filled."

Dave <barx>
Group Member
Sat 31 May 2014 11:37:23 AM UTC, original submission:  

Carsten Kunze reported an issue with \(sq to the list:  http://lists.gnu.org/archive/html/groff/2014-05/msg00042.html

Apparently, \(sq is normally an empty square, as shown in CSTR 54, but filled if the font is bold.  That's with 7th Edition troff and Heirloom troff.  The latter does this for PostScript output using the PostScript in troff/troff.d/font/devpost/charlib/sq which checks for Bold/Heavy/Ultra fonts.  I don't think it does it for UTF-8 terminal output.

More research into 7th Ed./Plan 9's behaviour is needed to determine it's a deliberate effect and reproduce it across output devices.

Ralph Corderoy <ralph>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by barx (originally raised the issue on the email list)
  • -email is unavailable- added by schwarze (Updated the item)
  • -email is unavailable- added by ralph (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-06-06 gbranden Attached File- Added unix_4.0_annotated_toc_typesetting.png, #53282
    2022-06-06 gbranden StatusInvalid Rejected
    2022-06-06 gbranden Attached File- Added nroff_troff_1981_table_1a.png, #53280
        Attached File- Added nroff_troff_1981_table_1b.png, #53281
        StatusNeed Info Invalid
        Open/ClosedOpen Closed
    2022-05-23 gbranden Attached File- Added CSTR_54_1976_Table_2_HRW_1983.png, #53243
        StatusConfirmed Need Info
        Assigned toNone gbranden
    2022-02-26 barx Carbon-Copy- Added carstenkunze
    2021-05-14 barx Carbon-CopyRemoved 93119 -
    2021-05-14 barx CategoryNone Font devps
    2018-02-16 schwarze Severity3 - Normal 2 - Minor
        Item GroupNone Incorrect behaviour
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-12ab.
    Corresponding source code