Medical symbols

i agree with the earlier respondent. i spent about an hour adding such auto-correction preferences. in addition, once you put in the time to construct a text and symbol substitution array in one application (e.g., Pages), Mr. Koenig has written an applescript which allows you to copy the array to the other applications in the iWork suite (http://discussions.apple.com/message.jspa?messageID=8939649#8939649).

So much for correct spelling:-)

True, speedtyping is a primordial sin -:).

Is there really a parallel in color standards to Unicode's compatibility decompositions?

Wrt deviceColor then its just deviceColor just as WOW! moused in MacPaint could be called deviceCharacter meaning that there is no independent information about the meaning.

A parallel could conceivably be explored for CIEBased and ICCBased. It's an interesting idea and there have been developer discussions, but I can't recall reading published papers.

There are straightforward parallels between the ColorSync 2/ICC architecture and the TrueType 2/GX/Apple Advanced Architecture, unsurprisingly.

In both architectures, the intention is that the intelligent drawing transform be determinate and independent of runtime rendering.

In the TT2/GX/AAT architecture e.g. David Turner (whose scaler has replaced Sampo Kaasila's scaler in Java) notes that the drawing intelligence is hardcoded into the individual font.

In the CS2/ICC architecture e.g. Chris Murphy ('Real World Color Management') has posted that it is a problem that the drawing intelligence is hardcoded into the individual profile.

Microsoft's thinking in relation to the character-glyph model and the colour-colourant model are a work with these ideas of perceived problems with redundancy and with inflexible predetermined intelligence. Don't misread this: it is not meant to say that Microsoft's thinking in relation to the character-glyph model and the colour-colourant model is invalid, but only to say that it is not universally valid and to the extent it is valid it is oversold (the same as Adobe oversells).

The Microsoft OpenType Specification recommends that, "As much as possible, the tables of OpenType Layout define only the information that is specific to the font layout. The tables do not try to encode information that remains constant within the conventions of a particular language or the typography of a particular script. Such information that would be replicated across all fonts in a given language belongs in the text-processing application for that language, not in the fonts."

The Microsoft Windows Color System is based on somewhat similar suggestions. One idea is to have the intelligent drawing transform be a client of the application or operating system, and by the same token reduce information redundancy in the transform. Another idea is to have the Profile Connection Space specify more of the drawing intelligence, in this case by changing the practical parametrisation of the PCS to a CIECAM model over the CIEXYZ and CIEL a*b models of the specification as it is. But as ICC developers have pointed out, if CIECAM is implemented in the intelligent drawing transform itself then the transform supports determinate drawing that is independent of runtime rendering. In other words, there is no advantage to WCS.

There is a tendency to think that linearisation/normalisation is part and parcel of the multidimensional reference character/colour space, and that as much as possible drawing should be done directly off the grid points. This is another part of the thinking behind OpenType and the Windows Color System. I understand why one would want to say this, but for a range of reasons I'm not sure I agree. But it's a huge discussion.

/hh

References:
http://www.microsoft.com/typography/otspec/TTOCHAP1.htm
http://www.color.org/ICCwhite_paper_24ICCandWCS.pdf
http://lists.apple.com/archives/colorsync-users/2006/Jan/msg00319.html
http://lists.apple.com/archives/colorsync-users/2006/Jan/msg00313.html
http://lists.apple.com/archives/colorsync-users/2006/Jan/msg00318.html

Pages is built with Unicode font encoding.

Take your O2 and change the 2 to a unicode superscript or subscript 2:

+Menu > Edit > Special Characters… > by Category > Digits > double click on the ² or ₂ > the character is inserted+

You should be able to search and replace on this if necessary.

btw These are chemical formulae not "medical symbols" and should be subscripted not superscripted.

As I already responded to the same question some times ago, try the Auto-correction tool whose array may be defined from menu Pages > Preferences

In the string 'before' type H2
In the string 'after' insert H₂

I inserted the character SUBSCRIPT TWO from the Character Palette.
It's the Unicode 2082

from 2080 thru 2089 is the entire set of subscript digits.

Using the feature I got:



Yvan KOENIG (from FRANCE samedi 7 février 2009 17:11:16)

Any ideas on how to put certain symbols in. Eg: O2 SpO2, H2O.

If you think anyone might ever need to search your document for those character strings, I would recommend you do it all manually via Format > Font > Baseline rather than via auto-correction. The reason is that people will not normally input unicode sub/superscripts for searching, but simply O2, etc., and that will find your formula when you use Format > Font > Baseline (but not when you use the unicode characters).

Hello Tom

If everybody works this way, I'm wondering why such characters where designed.

The Apple advice is clearly: use these Unicode characters as it's what is offered in the default substitution array.

Yvan KOENIG (from FRANCE samedi 7 février 2009 19:05:31)

I'm wondering why such characters where designed.

The general Unicode recommendation is that super/subscripts in rich text should be handled via style or markup. They exist in the code charts because of the need to roundtrip with legacy standards and because sometimes they have to be usable in plain text, such as phonetic notation systems.

The array itself is in the preferences file.

It's grabbed from:
<startupVolume>:Library:Application Support:iWork '09:Frameworks:SFWordProcessing.framework:Versions:A:Resources:English.lproj:De faults.plist



Yvan KOENIG (from FRANCE samedi 7 février 2009 20:55:30)

Thanks, I should have guessed that. I assume they use Unicode characters there because formatting is not an option. As a practical matter, it's a lot more likely someone will want to search on a chemical formula than on a fraction or an exponent, so using unicode for those is less of a problem. On Google h2o gives 30 million hits and h₂o gives 22,000, for what it's worth.

Tom Gewecke wrote:
Thanks, I should have guessed that. I assume they use Unicode characters there because formatting is not an option.

Why, playing with baseline, 1/4 does the trick no less no more than H2O 😉

Yvan KOENIG (from FRANCE samedi 7 février 2009 22:01:36)

If everybody works this way, I'm wondering why such characters where designed. The Apple advice is clearly: use these Unicode characters as it's what is offered in the default substitution array.

This is not technically correct. I'm sorry, Yvan.

First, you need to know that in constructing a character model for the writing systems of world scripts (or a colour model for the cultural concepts of colour around the world), you are going to get a multidimensional grid where the grid points are not equidistant.

In an ideal world, when you construct a reference grid / connection grid for character information and colour information, your grid will wind up with equidistant grid points as in a Euclidean space any parallel lines you draw through any grid points which are locally equidistant should stay equidistant to the periphery of the grid space.

In the real world, this did not happen either for ISO or for the CIE, despite the very best efforts of the developers. Therefore, there is a subsequent linearisation/normalisation in both the Unicode model and in the ICC model. I know this is abstract, but bear with me a moment and you will see where it is heading.

In the CIE model for CIEL a*b D50 2 degree standard that is used as one of two colour connection spaces (the other is CIEXYZ), the grid points are not semantically equidistant e.g. you get hue bending in cyans that turn magenta. And in the ISO model for 10646 there are a lot of what SC2/WG2 calls glyph-like characters.

For instance, the Alphabetic Presentation Forms block (Anglo-American ligatures) and the Arabic Presentation Forms block. Then you have the academic linguists who want small capitals, but that does not mean that you should be drawing your small capital glyphs by direct depiction onto small capital characters. And you have the same problem with superscripts and subscripts.

These are not intended for you to draw superscripts and subscripts in a school assignment. They have specialised applications, and for those specialised applications they may be used if absolutely necessary, but in choosing to draw your appearance directly off unconventional character codes, you need to know if there are normalisations/linearisations for those unconventional character codes.

First, try reading ISO-IEC Technical Report 15285: An Operational Model for Characters and Glyphs. Second, try downloading Unicode Checker either from the link in the Apple Text developer subsite or from directly from Earthlingsoft. The Apple Character Palette is not telling you the down and dirty facts on what is and what is not a related character.

/hh

Reference:
http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/tr15285:1998.pdf

Below the matrix for the standard universal synonyms followed by the matrix for the three search services, Google Search (Advanced), Microsoft Live Search (Advanced), and Yahoo! Search (Advanced). The matrix shows that one search service is setting a private synonym which is not supported by the standard universal synonyms of 10646/Unicode. In other search situations it is Google that sets a private synomym. The issue with private synonyms is that they students and scholars may come away with the belief that one search service is better than another search service, but this is unreliable as only the universal synonyms of the standard are reliable in any and all search services today and tomorrow.

Below the matrix for superscripts. For all superscript numbers the Apple Character Palette > Character Info > Related Characters window reports that normalisation NFD, normalisation NFC, normalisation NFKD and normalisation NFKC are related. For all superscript numbers, Apple TextEdit and Apple Pages do not consider NFD/NFC related to NFKD/NFKC for content-based searching. For all superscript numbers, furthermore, it is not possible to predict which search systems will set a synonym between NFD/NFC and NFKD/NFKC for searching.

SUPERSCRIPT ONE : NFD ¹ (no synonym), NFC ¹ (no synonym), NFKD 1 (SUPERSCRIPT ONE synonmous with DIGIT ONE), NFKC 1 (SUPERSCRIPT ONE synonymous with DIGIT ONE).
SUPERSCRIPT TWO : NFD ² (no synonym), NFC ² (no synonym), NFKD 2 (SUPERSCRIPT TWO synonmous with DIGIT TWO), NFKC 2 (SUPERSCRIPT TWO synonmous with DIGIT TWO).
SUPERSCRIPT THREE : NFD ³ (no synonym), NFC ³ (no synonym), NFKD 3 (SUPERSCRIPT THREE synonmous with DIGIT THREE), NFKC 3 (SUPERSCRIPT THREE synonmous with DIGIT THREE).
SUPERSCRIPT FOUR : NFD ⁴ (no synonym), NFC ⁴ (no synonym), NFKD 4 (SUPERSCRIPT FOUR synonymous with DIGIT FOUR), NFKC 4 (SUPERSCRIPT FOUR synonymous with DIGIT FOUR).
SUPERSCRIPT FIVE : NFD ⁵ (no synonym), NFC ⁵ (no synonym), NFKD 5 (SUPERSCRIPT FIVE synonymous with DIGIT FIVE), NFKC 5 (SUPERSCRIPT FIVE synonymous with DIGIT FIVE).
SUPERSCRIPT SIX : NFD ⁶ (no synonym), NFC ⁶ (no synonym), NFKD 6 (SUPERSCRIPT SIX synonymous with DIGIT SIX), NFKC 6 (SUPERSCRIPT SIX synonymous with DIGIT SIX).
SUPERSCRIPT SEVEN : NFD ⁷ (no synonym), NFC ⁷ (no synonym), NFKD 7 (SUPERSCRIPT SEVEN synonymous with DIGIT SEVEN), NFKC 7 (SUPERSCRIPT EIGHT synonymous with DIGIT SEVEN).
SUPERSCRIPT EIGHT : NFD ⁸ (no synonym), NFC ⁸ (no synonym), NFKD 8 (SUPERSCRIPT EIGHT synonymous with DIGIT EIGHT), NFKC 8 (SUPERSCRIPT EIGHT synonymous with DIGIT EIGHT).
SUPERSCRIPT NINE : NFD ⁹ (no synonym), NFC ⁹ (no synonym), NFKD 9 (SUPERSCRIPT NINE synonymous with DIGIT NINE), NFKC 9 (SUPERSCRIPT NINE synonymous with DIGIT NINE).
SUPERSCRIPT ZERO : NFD ⁰ (no synonym), NFC ⁰ (no synonym), NFKD 0 (SUPERSCRIPT ZERO synonymous with DIGIT ZERO), NFKC 0 (SUPERSCRIPT ZERO synonymous with DIGIT ZERO).

Below the matrix for subscripts. For all superscript numbers the Apple Character Palette > Character Info > Related Characters window reports that normalisation NFD, normalisation NFC, normalisation NFKD and normalisation NFKC are related. For all subscript numbers, Apple TextEdit and Apple Pages do not consider NFD/NFC related to NFKD/NFKC for content-based searching. For all subscript numbers, it is not possible to predict which search systems will set a synonym between NFD/NFC and NFKD/NFKC for searching.

Subscript one : NFD ₁ (no synonym), NFC ₁ (no synonym), NFKC 1 (SUBSCRIPT ONE synonymous with DIGIT ONE), NFKC 1 (SUBSCRIPT ONE synonymous with DIGIT ONE).
Subscript two : NFD ₂ (no synonym), NFC ₂ (no synonym), NFKD 2 (SUBSCRIPT TWO synonymous with DIGIT TWO), NFKC 2 (SUBSCRIPT TWO synonymous with DIGIT TWO).
Subscript three : NFD ₃ (no synonym), NFC ₃ (no synonym), NFKD 3 (SUBSCRIPT THREE synonymous with DIGIT THREE), NFKC 3 (SUBSCRIPT THREE synonymous with DIGIT THREE).
Subscript four : NFD ₄ (no synonym), NFC ₄ (no synonym), NFKD 4 (SUBSCRIPT FOUR synonymous with DIGIT FOUR), NFKC 4 (SUBSCRIPT FOUR synonymous with DIGIT FOUR).
Subscript five : NFD ₅ (no synonym), NFC ₅ (no synonym), NFKD 5 (SUBSCRIPT FIVE synonymous with DIGIT FIVE), NFKC 5 (SUBSCRIPT FIVE synonymous with DIGIT FIVE).
Subscript six : NFD ₆ (no synonym), NFC ₆ (no synonym), NFKD 6 (SUBSCRIPT SIX synonymous with DIGIT SIX), NFKC 6 (SUBSCRIPT SIX synonymous with DIGIT SIX).
Subscript seven : NFD ₇ (no synonym), NFC ₇ (no synonym), NFKD 7 (SUBSCRIPT SEVEN synonymous with DIGIT SEVEN), NFKD 7 (SUBSCRIPT SEVEN synonymous with DIGIT SEVEN).
Subscript eight : NFD ₈ (no synonym), NFC ₈ (no synonym), NFKD 8 (SUBSCRIPT EIGHT synonymous with DIGIT EIGHT), NFKC 8 (SUBSCRIPT EIGHT synonymous with DIGIT EIGHT).
Subscript nine : NFD ₉ (no synonym), NFC ₉ (no synonym), NFKD 9 (SUBSCRIPT NINE synonymous with DIGIT NINE), NFKD 9 (SUBSCRIPT NINE synonymous with DIGIT NINE).
Subscript zero : NFD ₀ (no synonym), NFC ₀ (no synonym), NFKD 0 (SUBSCRIPT ZERO synonymous with DIGIT ZERO), NFKC 0 (SUBSCRIPT ZERO synonymous with DIGIT ZERO).

Sample searches for the chemical formula for carbon dioxide on 8 February 2009 at 14:00 Central European Time.

Google Search > Advanced Search > This Exact Word or Phrasing.
CO2 finds 19,700,000 results for site:com
CO² finds 259,000 hits for site:com

Microsoft Live Search > Advanced Search > This Exact Phrase.
CO2 finds 3,130,000 results for site:com
CO² finds 51,200 results for site:com

Yahoo! Search > Advanced Search > The Exact Phrase.
CO2 finds 85,900,000 results for site:com
CO² finds 85,900,000 results for site:com

/hh

Yahoo! Search > Advanced Search > The Exact Phrase.
CO2 finds 85,900,000 results for site:com
CO² finds 85,900,000 results for site:com

Very interesting! I did not realize anyone did that.

Maybe on some other discussion boards but, as you've seen, the first poster would have readily replied to "chemical formulae" just as well as "medical symbols". The other side of the coin is that there may have been several users that read "medical symbols" who, not knowing your question actually involved "chemical formulae" may have avoided your post.

Henrik Holmegaard wrote:

If everybody works this way, I'm wondering why such characters where designed. The Apple advice is clearly: use these Unicode characters as it's what is offered in the default substitution array.

This is not technically correct. I'm sorry, Yvan.

May I tell you that I am not interested by your obsessions about character recognition. I don't write to publish on line.
When I write it's for my own use or to print.
So I use the available characters as I want. My rules are typographycal ones, not your fantasmatic ones.

When Skira or Teriade where preparing books with the "Imprimerie Nationale", with Matisse, Picasso, Le Corbusier, Giacometti, Derain … they made typography not "fly s0d0misation".

Yvan KOENIG (from FRANCE dimanche 8 février 2009 17:57:43)