README.md

Caution:Use of proposed or accepted characters is at implementers'
own risk; the composition and allocation of the characters may change
before they are finally published in the Unicode Standard. Always check
the Unicode Pipeline
for the latest guidance.

The relevant characters are:

U+23FB POWER SYMBOL (⏻ or )

U+23FC POWER ON-OFF SYMBOL (⏼ or )

U+23FD POWER ON SYMBOL (⏽ or )

U+23FE POWER SLEEP SYMBOL (⏾ or )

As well as U+2B58 HEAVY CIRCLE (⭘ or ) for the power off symbol.

Note that POWER SLEEP SYMBOL has been moved into the "Miscellaneous
Technical Symbols" block in the Basic Multilingual Plane (BMP) at position
U+23FE and given its proper name at last.

See the latest news here. We hope to see the new symbols
in Unicode version 9.0, expected in June or July, 2016.

Add IEC 60417-5009 POWER SYMBOL ⏻ to the Unicode Standard

Success!

The U+23FB ⏻∗,
U+23FC ⏼, U+23FD ⏽, U+23FE ⏾, and
U+2B58 ⭘†
characters now appear in the Unicode
Pipeline Table with the
status of “Accepted”. They can be used now, and designed into
fonts, and they're on their way to be in a future version of the
Unicode Standard after 7.0. The symbols were approved by the ISO 10646
Working Group 2 (JTC 1/SC 2/WG 2) at the WG2 #62 meeting to go into
Amendment 2 to ISO/IEC 10646:2014
for publication in 2016. Right now they are in
ISO stage 5. See the
latest news for details.

Successful proposals cover every angle and raise every anticipated objection before those
objections can be raised in committee. Our proposal took the risk of pointing out disagreement
and ambiguities around the usage of some of the characters, especially ⏻; this was
probably one of the strengths of our argument.

It is possible to do this in a reasonable amount of time (around two months, from
start to finish, in our case).

Do provide your font along with the proposal, preferably through a clickable
link in the PDF of the proposal, even though the
instructions for submission don't ask
for it. During the UTC meeting when your proposal is considered, it's likely that
subcommittee members will need to write a quick proposal in support of your proposal
(that's how it's done) and it'll help them if your font is to hand when they need it.
They can't just extract the font from the PDF of your proposal, as we thought they
might.§

The right tool for font design is surprisingly important. A custom font is needed early
in the process because it's needed to write the proposal, but you should design the font
from the beginning to employ arbitrary Unicode code points, because you won't know until
late in the process what the actual code points will be.
Some of our work was wasted; to avoid that, choose a range in
the Unicode Private Use Area (E000 to F8FF)
to serve as a placeholder until the UTC suggests real code points. This ensures that
you don't get wrapped up in a font design tool that doesn't support Unicode—especially code
points above FFFF—which lots of programmes still don't support correctly. See
Notes on Tools for Creating Fonts below for more information on free font
design tools that work.

Choose a font file format—SVG is good—that can handle metadata
so it's possible to embed the font licence and designer's contact information in the font file.
The glyphs that will be standardised, that all subsequent font designers will follow, will be
defined by the final font you submit. Official font submission happens later in the process;
our proposal has been formally accepted and we haven't been asked for the official font yet,
so we still have an opportunity to fine-tune the glyphs before then.

Friends on the web are an invaluable resource; sometimes they appear out of nowhere,
provide free technical reviewing services, volunteer their time, and lend a hand. We couldn't
have done it without them.

If you have the font installed, the ⏻ characters ⏼ should ⏽ appear
⏾ inline ⭘ here. (This may not work in all web browsers.) See the
Web Browser Test section, especially the
HTML Font Embedding Test page below for a more thorough test
of your web browser's support for Unicode fonts.

Use of proposed or accepted characters is at implementers’ own risk; the composition and allocation
of the characters may change before they are finally published in the Unicode Standard. Always check
the Unicode Pipeline for the latest guidance.

Web Browser Test

Straight Compatibility Test

Here are the new characters displayed without using HTML font embedding: can you see all of them?

This page
uses font embedding in HTML and should work on more browsers.

Test Results

Application

Version

Platform

Results

Firefox

26.0

Windows XP Professional Service Pack 3

Firefox

26.0

Mac OS X 10.6.8 (Intel)

∗

Firefox

27.0

Mac OS X 10.6.8 (Intel)

∗

Firefox

27.0

Mac OS X 10.9.1 (Intel)

Chrome §

32.0.1700.107 m

Windows XP Professional
Service Pack 3

†

†

†

†

†

(Chrome with font embedding in CSS)

Chrome

32.0.1700.107

Mac OS X 10.7.5 (Intel)

†

Safari ∥

5.1.7 (7534.57.2)

Windows XP Professional
Service Pack 3

†

†

†

†

†

(Safari with font embedding in CSS)

¶

Safari

5.1.10 (6534.59.10)

Mac OX X 10.6.8 (Intel)

†

Safari

6.1.1 (7537.73.11)

Mac OS X 10.7.5 (Intel)

†

Safari

7.0.1 (9537.73.11)

Mac OS X 10.9.1 (Intel)

Safari §, **

7.0.6 (11B651)

iPad

Safari §, **

7.0.6 (11B651)

iPhone

Sea Monkey

2.24

Mac OS X 10.7.5 (Intel)

∗

IE 8

8.0.6001.18702

Windows XP Professional
Service Pack 3

†

†

†

†

†

(Microsoft Internet Explorer 8 with font embedding in CSS)

†

†

†

†

†

* Displays a small box with hexadecimal numbers in it like this: .
† Displays an empty box like this: .
‡ See http://gschoppe.com/blog/fixing-unicode-support-in-google-chrome/
for more information on Unicode support in Chrome under Windows.
§ Full support on these devices (everything works correctly) using
font embedding in CSS.
∥ Partial support (everything but BLACK WANING CRESCENT MOON
POWER SLEEP SYMBOL works) using
font embedding in CSS.
¶ Safari displays a black box for BLACK WANING CRESCENT MOON
POWER SLEEP SYMBOL, like this: .
alt="black box"/>
** iOS was the only software found to display stacked diacritics correctly.

Feedback by others on Amendment 2 has suggested
that POWER SLEEP SYMBOL ought to be encoded in the "Miscellaneous Technical Symbols" block
in the Basic Multilingual Plane (BMP), perhaps at U+23FE. This would co-locate it "...with
the other power related symbols in the same Unicode block."

Historical Section and Proposal Development

The following sections describe, in approximately chronological order, how the proposal
was developed from start to finish. We began the project on 1st December 2013 and reached
our goal the first week of February 2014.

The IEC 60417-5009 “Stand-by” Symbol

On 1 December 2013, Terence Eden posed a question to
Hacker News asking why Unicode lacks
the international symbol that appears on power switches. After searching for a while,
I learnt he was right — in fact, Unicode lacks all of the following
symbols:1

IEC 60417-5007

IEC 60417-5008

IEC 60417-5009

IEC 60417-5010

IEEE 1621

“ON” (power)

“OFF” (power)

“Stand-by”

“ON”/“OFF” (push-push)

“Sleep”

Click on any image for SVG.

Source of the above images: Wikipedia.
The first four symbols were drawn by Wikipedia users
klork and
DarkEvil;
the moon was made specifically for this purpose from the specifications in the
precise drawing.

Clearly these would be useful to anyone writing technical or user manuals. In fact, for
electronically publishing documentation, it is crucial to have symbols defined in
Unicode because it makes them search-able in text.

How to Add Symbols to Unicode

There are a few crescent moon symbols in Unicode already: the 🌙
CRESCENT MOON (U+1F319), ☽ FIRST QUARTER MOON (U+263D), and
☾ LAST QUARTER MOON (U+263E) symbols, but none of them are exactly
like the IEEE 1621 symbol; U+1F319 is closest, but faces the opposite direction.

Getting Access to the “Official” Symbols

Before submitting a proposal, I would like to verify the specifications for each
symbol shown above in IEEE 1621-2004 and IEC 61417, which is also
ISO 7000:2012,
and then translate those into whatever form of description is required by Unicode.

I have the document submission details now (it's in the members section).
It is encouraged that a representative for each proposal to the
UTC should attend the meeting
and present the document. The next meeting is
February 3–6, 2014 at
IBM in San Jose, California.

Any review is valuable, but the most useful of all can be things like,
I got bored half-way through this section. The current draft proposal is always
here (PDF). Email
the author or use a GitHub issue,
however you prefer.

Document the compass-and-straightedge construction of the Unicode POWER SLEEP SYMBOL.

Make a PostScript font and CMAP file.

Deadlines

The calendar has been updated; the next quarterly meeting of the
Unicode Technical Committee (UTC) will
take place 3–6 February 2014
in San Jose, California. The next meeting after that is 6–9 May 2014.
I want to get our proposal submitted in time to make the agenda for the February
meeting (two weeks in advance).

What To Do Next

There is an excellent
SVG font tutorial
specifically aimed at generating icon fonts. It includes an SVG font starter file,
instructions for using the SVG font editor built into Inkscape 0.48, recommendations
about which on-line font converters are most reliable, and tips for editing the
metadata and distributing the new font afterwards.

LaTeX

These instructions for
using TrueType fonts in LaTeX
are straightforward, but a better method is to use
XeTeX
which has built-in support for TrueType fonts already installed in the OS,
and is available in MiKTeX 2.9.

Notes on Encoding

When designing a new font of symbols where there is no pre-existing ordering to use, what is the
best way to define the encoding? There are practical and aesthetic reasons for doing it
thoughtfully. The practical reason is, encodings are shared across fonts, and if a string encoded
in your new symbol font is accidentally changed to or displayed in a different font, it may
coincidentally spell out a message that is
nonsensical, confusing, or offensive.
(Microsoft had this problem with the Wingdings font; it was either a coincidence or a conspiracy
depending on who's telling the story.)

Years ago at Lockheed, they had a special font containing the corporate logo in a few sizes,
for use in Microsoft Word before such graphics were common. It was not uncommon back then to
open a Word document and see a big “L” on the page where the letterhead was
supposed to be, because the font wasn't loaded. The fact suggests that the font designer
thought about the encoding and put the corporate logo in the capital-L encoding slot for
that reason, so it would fail gracefully if the font were unavailable.

In the absence of any well-defined convention for code pages in “sparse”
symbol fonts, here is a proposed encoding for the
old font:

Notes on XeTeX

XeTeX in the current version of MiKTeX has a bug that causes a harmless message
during compilation, ** WARNING ** Couldn't open font map file "kanjix.map". To
avoid it, place an empty file called kanjix.map in the current directory.