Talk:Mac OS Roman

Image copyright problem with File:Apple.svg

The image File:Apple.svg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

• That there is a non-free use rationale on the image's description page for the use in this article.
• That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --12:10, 2 January 2009 (UTC)

Table

Unlike the chset template, the table entries are showing the hex value of the table location, rather than the Unicode equivalent value. The intention of the hex number is to show the Unicode equivalent. The hex value of the code in the set can be trivially figured out by using the row and column headers. This should get fixed. I searched the history but it appears the Unicode equivalents were never in there...Spitzak (talk) 10:15, 17 August 2010 (UTC)

Chicago & Charcoal

These system fonts use codepoint 6 for a Ctrl symbol (like an inverted, flattened V). Should this be mentioned?

Paul Magnussen (talk) 15:10, 1 January 2013 (UTC)

This is mentioned in a footnote to the table, but it indicates points 17,18,19,20 are used for this and the command, shift, and option keys. However it does not indicate which is which and the symbols are not in the table, and maybe has the wrong indexes, so your claim of it being on 6 is possible. Can anybody fix this?Spitzak (talk) 06:36, 2 January 2013 (UTC)

How can be dotless i punctuation?

Dotless i is marked blue (punctuation,) but according to wikipedia page on ı, it is international. 109.243.157.194 (talk) 08:24, 20 March 2015 (UTC)

Colors

I reverted an edit because the Unicode class for some of the combining marks start with "Letter" so it seems these should be colored like letters. However further investigation shows that many other combining marks (such as shown here) are classified as "symbol modifier". But a few non-combining ones (such as tilde) are also classified this way, the only difference I see in the Unicode reference is that those "decompose" into space+modifier. Weird. I see the green color as being "weird behavior", basically where the glyph does not place the next glyph some width to the right. It is possible all the modifiers should be colored this way, and the white and yellow reserved for characters that print normally. The tilde and so on should be colored normally due to the space+modifier decomposition. This would require changing a lot of these tables.Spitzak (talk) 20:26, 21 November 2019 (UTC)

C0 replacement graphics for keyboard symbols

Although 0x11 having a U+2318 glyph seems to be uncontroversial, the other exact mappings currently shown seem questionable upon my attempts to verify them. It is possible that others have access to sources I have not, so paging @Spitzak and DOSGuy:. The sources I've been able to track down are summarised below.

IBM's chart for MacRoman lists the following C0 replacement graphics over the device control codes:

• SS300000 = U+2318 (⌘) at 0x11
• SV010000 = U+2713 (✓) at 0x12
• SS030000 = U+2666 (♦) at 0x13
• SV640000 = U+F8FF (duplicate Apple logo) at 0x14

So, I think, how might I verify this? Well… the ROMAN.TXT blurb doesn't list the exact mappings or identities, merely indicating that they are used for keyboard symbols and that the device controls are involved, but it lists the Chicago font as a font which included it. Googling for the Chicago font readily revealed a ChicagoFLF.ttf timestamped 2004 and marked "4.1 (c)1990-92 by Richard A. Ware." which… despite being visually still the Chicago typeface, was not the right one (its C0 replacements are diacritics, ligatures, additional letters and a fraction slash—interesting, certainly, but not the keyboard symbols and not including the device controls in any case).

So I pulled up an FTP indexing service and tracked down another version, filenamed Chicago.ttf, this time with the copyright field "(c) 1990-91 Apple Computer Inc. (c) 1990-91 Type Solutions Inc. (c) 1990-91 The Font Bureau Inc.". This seemed to be the correct version of the font (I'd put a link here, but I'm not sure of the policy or legality surrounding doing so). The C0 replacements seem to match those listed for MacRoman by IBM, but with more:

• ⌥ (glyph name "option") at 0x01
• ⌃ (glyph name "control") at 0x02
• ⌤ (glyph name "enter") at 0x03
• ⇧ (glyph name "shift") at 0x04
• ⇪ (glyph name "capslock") at 0x05
• ⎋ (glyph name "escape") at 0x06
• ␣ (glyph name "markingspace") at 0x07
• ⌫ (glyph name "markingdeleteltor") at 0x08
• ⭲ (glyph name "markingtabltor") at 0x0A
• ⮒ (glyph name "linebreakltor") at 0x0B
• A page icon with a down arrow on it (glyph name "newpage") at 0x0C
• ⮐ (glyph name "parbreakltor") at 0x0E
• ⍽ (glyph name "markingnobreakspace") at 0x0F
• An outline of an Apple logo (glyph name "appleoutline") at 0x10
• ⌘ (glyph name "propeller") at 0x11, matching IBM's chart
• ✓ (glyph name "checkmark") at 0x12, matching IBM's chart
• ♦ (glyph name "diamond") at 0x13, matching IBM's chart
• A duplicate (filled) Apple logo (glyph name "apple") at 0x14
• ⌦ (glyph name "markingdeletertol") at 0x15
• ⭰ (glyph name "markingtabrtol") at 0x16
• ⮑ (glyph name "parbreakrtol") at 0x17
• ⮓ (glyph name "linebreakrtol") at 0x18

Hence, while the listed mapping of U+2318 to 0x11 seems to check out on all counts, the listed mappings of U+21E7 to 0x12 (not U+2713 to 0x12 and U+21E7 to 0x04), U+2325 to 0x13 (not U+2666 to 0x13 and U+2325 to 0x01) and U+2303 to 0x14 (not U+F8FF to 0x14 as well as 0xF0, and U+2303 to 0x02) seems dubious. But maybe one of you has a source (or e.g. another font file) you're referencing for the mappings currently shown?

(The code point for code point mapping currently shown seems to have been added to the chart in this revision, but first alluded to in a footnote in this revision. It was also added to the Zapf Dingbats mapping in this revision.)

--HarJIT (talk) 20:30, 22 August 2020 (UTC)

I just found the Unicode characters, I was assuming the footnote describing the range of points was correct. Apparently not.Spitzak (talk) 00:50, 23 August 2020 (UTC)

I assume that you're referring to this blurb from ROMAN.TXT: "In all Mac OS encodings, fonts such as Chicago which are used as "system" fonts (for menus, dialogs, etc.) have four glyphs at code points 0x11-0x14 for transient use by the Menu Manager. These glyphs are not intended as characters for use in normal text, and the associated code points are not generally interpreted as associated with these glyphs; they are usually interpreted (if at all) as the control codes DC1-DC4." Unhelpfully, it doesn't indicate the nature of those glyphs because, as it stated earlier, "Control character mappings are not shown in this table" because "the Mac OS Roman character set uses the standard control characters at 0x00-0x1F and 0x7F." Every other code page file in /Public/MAPPINGS/VENDORS/APPLE/ says the same thing.

Since Unicode acknowledged that "system fonts" assign glyphs to DC1-DC4, I assumed that the table had the correct ones. Given that both IBM CP1275 and Chicago.ttf show propeller, checkmark, diamond, and Apple logo, that seems to be pretty solid evidence that those are the correct glyphs. That leaves the issue of what to make of the glyphs at the other C0 code points.

From what I'm reading, all Mac OS code pages map 0x00 to 0x1F to their ASCII equivalents, but "system" fonts assign glyphs to DC1-DC4, and it's reasonable for us to show those glyphs (with a note) in the tables for those code pages, provided that they all use the same glyphs for those code points. If they don't, then we should list them as DC1-DC4 and include a note that system fonts map various glyphs to those code points. It seems that Chicago has glyphs for most of the other unprintable control characters. And why not? IBM did the same thing with CP437 and other DOS code pages. The question remains whether the other system fonts assign the same glyphs at those code points. List of typefaces included with macOS#System fonts up to Mac OS X 10.7 Lion lists a large number of Mac OS system fonts, but ROMAN.TXT mentions that Chicago, New York, Geneva, and Monaco had character ROMs and, unlike any other system fonts that might have been in a character ROM, only supported code points up to 0xD8. It seems reasonable to use these fonts as the basis for a test. Do the TTF files for the New York, Geneva, and Monaco have the same glyphs for DC1-DC4, and for the rest of the C0 controls? DOSGuy (talk) 05:37, 23 August 2020 (UTC)

The accompanying TTF for Geneva does not seem to have glyphs for any of the C0 controls. I have not been able to track down a contemporary TTF for the other two, although I have also located and extracted the bitmap (NFNT) versions of Chicago, Geneva and Monaco (bitmap Chicago only includes the graphics for the device controls, but matches IBM's chart and the TTF file in which graphics they are; neither Geneva nor Monaco includes graphics for any of the C0 controls). Screenshots of the fonts on Imgur. --HarJIT (talk) 12:38, 23 August 2020 (UTC)

The bitmaps are the ones to go with, especially Chicago. I was programming these things back when they came out, and software absolutely took advantage of these extra characters, so they should be in there, just like they are in CP480 and other contemporary character sets. They are likely removed fro the TTF fonts because there is almost no use of them on modern systems like OS/X. I would try to locate the closest matching glyph in Unicode, and also change the footnote to an explanation at the bottom so they don't all have a footnote.Spitzak (talk) 17:54, 23 August 2020 (UTC)

Update Chicago bitmaps from Mac OS 8.0. Unlike the Mac OS 6.0.7 bitmap font, it includes more C0 glyphs than just the four device control characters. However, it does so in a completely different layout from the TTF version (albeit still focused on keyboard symbols). The four device control glyphs are still the same as the system 6.0.7 version (and the TTF, and the IBM chart) though, so what I'm gathering from this that they were the earliest and most standard / stable C0 glyphs (either being present or absent, but not differing between versions of the font when present), presumably hence their listing by IBM. --HarJIT (talk)

It seems very confusing to have the table diverge from the actual character set specification by including how some fonts remap certain characters, so I reverted the change. The fact that some fonts will remap code positions to other characters seems beyond the scope of an article on the character set, not individual fonts. It would also not be feasible to cover all fonts that remap characters. There are many fonts that do this for many characters in this set, like Symbol and Zapf Dingbats. Mkhadpe (talk) 15:12, 10 July 2021 (UTC)

How does a Mac user create these symbols on a Mac?

I am a Mac user, and I am disappointed that this article includes no explicit information about how a Mac user can type these characters on a Mac.

I know about going to the "Emoji & Symbols" tab on the Edit menu (or by typing ^⌘-space).

But could somoene knowledgeable on this subject please remedy the obvious omission of which sequences of keys result in typing these symbols on a Mac? Thanks.65.141.95.170 (talk) 22:32, 5 November 2020 (UTC)