29

ISO-8859-1 and Win1252 have a couple of characters that are normally associated with accented letters of the Roman alphabet:

  • 0xA8, ¨ (umlaut)

  • 0xB4, ´ (acute accent)

  • 0xB8, ¸ (cedilla)

... which sounds reasonable enough, until you consider that they're all pretty much useless on their own for anything besides ASCII art.

As far as I can tell, neither ISO-8859-1 nor Win1252 have/had a character code that explicitly meant, "combine {this character} and {that character} into one". Obviously, Unicode has multiple flavors of combining codes.

Was there ever a real operating system that used Win1252 or ISO8859-1 and actually supported multibyte character-composition (presumably, using one of the C0 or C1 codes to encode it)? Or is this just something that ended up in ISO-8859-1/Win1252 because nobody could think of anything better to stick at those codepoints, and someone figured they might someday be usable for composition purposes?

Improve this question
11
  • 7
    Nothing in the code definition says that the carriage has to move on printing any given character. But if it does on your equipment, there is backspace. Note that if your device can't handle backspace and overprint, then it would be unlikely to be able to display the result of any other compose sequence.
    – dave
    Commented Jun 26 at 23:45
  • 9
    You cannot combine them on a glas terminal but you can easily on a printer.
    – Patrick Schlüter
    Commented Jun 27 at 7:10
  • 4
    I can also see a use for those characters if you write a text disscussing their use (a bit like your question). How would you write that question without access to "¨", "´" and "¸"?
    – UncleBod
    Commented Jun 27 at 9:23
  • 2
    @PatrickSchlüter You cannot combine them on a glass terminal but you can easily on a printer. If your terminal font has, say, e-acute, your display software can conceivably convert the 2-byte sequence 'acute, e' to a single displayed character on output.
    – dave
    Commented Jun 27 at 11:09
  • 4
    @dave I didn't mean that combining character never exist on glass terminals, just that it is almost always possible on printers, you only need a backspace code (implying btw that ASCII was conceived primaly for transmission and output on print devices. ASCII invented inn the early '60s, glas terminals in the 70s).
    – Patrick Schlüter
    Commented Jun 27 at 14:29

4 Answers 4

Reset to default
48

TL;DR: It's about compatibility with previous 7-bit character sets

They are there for upward compatibility with previous character sets, much the same way as Unicode features duplicates to maintain 1:1 relation with various previous other character sets.

History of those characters goes back to ECMA-6 defining rules for

  • international 7 bit character sets with
  • basic compatibility,
  • how to add certain national character (like Diaeresis) and
  • how to create composed characters from that set.

The Question

ISO-8859-1 and Win1252 have a couple of characters that are normally associated with accented letters of the Roman alphabet which sounds reasonable enough, until you consider that they're all pretty much useless on their own for anything besides ASCII art.

Only if those are all considered on their own and as as 'carriage advancing' - an assumption one may have looking at simple cases in today's usage.

As far as I can tell, neither ISO-8859-1 nor Win1252 have/had a character code that explicitly meant, "combine {this character} and {that character} into one".

Sure, it's either special attributes, depending on software/language/character set or the more general BACKSPACE (x'08').

Obviously, Unicode has multiple flavors of combining codes.

Most of them due the need to include historic encoding variants - which the three mentioned characters are.

Was there ever a real operating system

Sounds like an easy misconception to ask an OS to do such things. character handling, especially such chases as composed characters is what application software was about, OSes didn't care for such bells and whistles..

Having an OS drawing characters on a bitmap display, a prerequisite to composing, is a very new development, way more recent than the character definitions leading to above encoding.

that used Win1252 or ISO8859-1 and actually supported multibyte character-composition (presumably, using one of the C0 or C1 codes to encode it)?

As mentioned, either

  • using BS, so o + BS + ¨ gives ö,
  • or having them being combining by default, so ¨ + a shows ä

Which BTW highlights another 'shortcut' made from today's POV: Those codes were made for communication, not display. Rules for combination were optional and application specific.

Or is this just something that ended up in ISO-8859-1/Win1252 because nobody could think of anything better to stick at those codepoints, and someone figured they might someday be usable for composition purposes?

Almost, just the other way around, as they were already in use with 7 bit codes, way before 8859-1 (or later CP1252) have been defined. So best to take a look at the

History Involved

  • CP1252 of 1992 (*1) is based on ISO 8859-1 Latin Alphabet #1 (1987), while
  • ISO 8859-1 itself is ISO's adaption of ECMA-94 published in 1985 (*2)

So those character assignments clearly predate Windows and even ISO 8859. Both carried them on for compatibility. Usage or not was up to application software.

Now, looking into ECMA-94 shows not only the definition of four Latin based alphabets (*2), but also a common subset above x'80' containing exactly those characters:

enter image description here

(Taken from ECMA-94 Appendix A)

Such a subset in all 4 character sets is usually a strong hint about compatibility issues, and that's where ISO 646 comes into play. ISO 646 was defined in 1967, creating a base character set close following US-ASCII. In addition to making the Dollar sign optional (and allowing substitution of Hash with Pound) it defined code points and rules for creation of national variants - and in turn there were plenty.

The case of above 3 diacritics (*3) can best be made with ISO-IR-025 (aka French standard AFNOR NF Z 62010-1973), the original variant used in France, which defines Diaeresis at x'7E'. French is not only a good example because them being a major voice during standardisation, but their language also being (in)famous for all the diacritical marks it throws around their characters :))

It's quite logical, as that character was already present on French typewriters long before computers and text processing became a thing. The French keyboard featured separate keys for Diaeresis and other diacritics as seen on the circumflex key (second row second to last key):

enter image description here

(Image taken from Wikipedia)

Early typewriters did usually only feature basic Latin letters - even in Germany with our Umlauts. If one wanted to write an Ü, it was U backspace " (*4). Now while German manufacturers soon added three more keys to the left, French didn't. And French software went along with that.

And all according to international standards, which brings us to ECMA-6. Before ISO-646 there was ECMA-6 of 1965, defining a 7-bit code close to ASCII, in development at the same time. And while it defined a basic variant, called IRV (International Reference Version), which equalled ASCII-1967 (*5), it also defined the code points for national characters as marked here:

enter image description here

(Taken from ECMA-6 Table 1 p.16)

The coloured spots (colouring mine) is where all those weird characters ended up one can find in old 7 bit tables. Like Diaeresis on x'7E'. And ECMA-6 also defines in section 5 how to encode composite characters:

enter image description here

(Taken from ECMA-6 Section 5 p.12)

So it's simply done by overstriking using

  • <modifier> <backspace> <character> or
  • <character> <backspace> <modifier>

This explains why there are Degree and Diaeresis in ISO-IR-025, but Cedille and Accent Aigu are still missing, except ECMA-6 continues as:

enter image description here

(Taken from ECMA-6 Section 5 p.12)

delivering the formula for creating characters with either diacritical mark. Except, it created additional complexity, if not ambiguity, to decide between composed and non-composed use. This got even emphasised by French software assuming for certain characters to always be composing (*6).

So when ECMA-94 came to be, every character that had a double use in 7 bit got a distinct position. Either due being part of the IRV variant or by getting a new position above x'A0'.

  • x'5E' - Accent Circonflexe
  • x'60' - Accent Grave
  • x'7E' - Petit Tilde
  • x'A8' - Trema (Diaeresis)
  • x'B0' - Rond en Chef (Degree)
  • x'B4' - Accent Aigu (Acute)
  • x'B8' - Cedille/Virgule

So here you have it: with the new ECMA-94 encoding, use of either character/modifier was now clear and unbridled (*7). ISO-8859, Unicode and CP1252 inherited them.

*1 - At that point it's important to understand that Windows 1.0 used plain 8859-1 (after all, it was the most recent standard back then), while 2.0 'only' added those dreaded left/right quotation marks. Windows 3.1 finally added in 1992 all the remaining codes in 8x/9x columns that make up CP1252 as we know it.

*2 - Together with -2, -3 and -4 which as well are defined in ECMA-94.

*3 - Well those plus Degree °.

*4 - Yes, that's double quotation.

*5 - Except for the Dollar sign.

*6 - Don't judge too fast, saving a byte by making the default case as composing (there are lots of characters with marks in French), software could save the backspace. A lot at a time when every byte counted more than a megabyte today.

*7 - ... well, except for sequence, but that's another story :))

Improve this answer
4
  • 2
    Unicode includes both spacing diacritics and combining diacritics. The reason for the spacing ones is mostly historic – these are in particular the characters that Unicode inherited from ISO-8859-?, such as the spacing umlaut ¨ (at 0xA8 in ISO-8859-1 and at 0x00A8 in Unicode). ...
    – Uwe
    Commented Jun 27 at 11:28
  • ... The combining diacritics, such as the combining umlaut at 0x0308, serve a real purpose, though: If you want to support every language on this planet, including languages that use more than one diacritic mark on a letter (stuff like "c with caron above and comma above" or so), providing precomposed letters with accents for each required combination becomes simply infeasible. Therefore, at some point, the Unicode consortium decided that they would not add any further precomposed letters if the same result could also be obtained using combining diacritics).
    – Uwe
    Commented Jun 27 at 11:29
  • "So those character assignments clearly predate Windows and even ISO 8859." Sort of. It predated the release of Windows, but only by a matter of months. Windows was clearly in development before it was released though (and developing Windows undoubtedly took longer, so work on Windows probably started before work on ISO 8859). Pretty sure that's purely a nit-pick though, not likely to affect any conclusions.
    – Jerry Coffin
    Commented Jun 30 at 4:16
  • @JerryCoffin So, how was it based on that character set if created before? Note that standards also need a development time - and more important ratification time. The assignment for Latin-1 was done before 1983 - followed by a long line of signing, publication and adaption by various standard bodies.
    – Raffzahn
    Commented Jun 30 at 6:51
8

Was there ever a real operating system that used Win1252 or ISO8859-1 and actually supported multibyte character-composition

It goes back much farther. Multics supported "canonicalization" in ring 0 (the OS kernel) in an attempt to insure that inputs that looked the same on a terminal would be seen as the same string by code.

This proved to be a difficult moving target. There were tricky corner cases. Terminals and character encodings evolved, changing the problem space.

Improve this answer
6

Even on systems which didn't have keyboard-driver support for combining diacritics, some applications programs would provide such support themselves. Although my preferred text editor from the 1980s would use a three-keystroke sequence to produce combining diacritics (type grave, regardless of the accent to be produced, followed by a pair of characters), some programs on some systems likely used a two-keystroke approach of typing the accent and then the modified letter. Having a character code for the accent certainly facilitated things.

Improve this answer
1
  • 3
    In a similar vein: on a Flexowriter, underscore was non-advancing, so you could write proper Algol 60 with underlined basic symbols (which the KDF9 compilers supported). Sure, begin was 10 keystrokes (underscore, b, underscore e, ...) but it was worth it!
    – dave
    Commented Jun 27 at 11:14
-1

I can think of a simple use.

If your keyboard driver supports it, when you want to type an accented letter, say an ë, you press the [¨] key and then the [e] key. Between these two keystrokes your screen should display the umlaut. At least that is what the mac does. To display that, you need a character code representing the umlaut. So, specific codes for accents alone can be useful.

Improve this answer
4
  • You're aware that the question is about a character set, not keyboard or rendering? Also, Macs do not use either of the mentioned character sets but MacRoman (as default).
    – Raffzahn
    Commented Jun 29 at 11:22
  • 1
    Mac Roman also includes acute and diaresis characters. The question was why a character set includes such characters, I gave an example of where it can be useful.
    – Florian F
    Commented Jun 29 at 14:26
  • It's not a bad idea. But having a combining character and just combining it with a space would accomplish the same thing. Still, if combining characters aren't available, I could see using this.
    – trlkly
    Commented Jun 29 at 17:42
  • 1
    Today, yes. But these were introduced before the time of multi-byte characters. On old text displays you had 1 position = 1 character = 1 byte.
    – Florian F
    Commented Jun 29 at 17:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .