Next week Microsoft will be making announcements about Windows 8 and I expect this will raise speculation on software futures in the press. So now seems like a good time to forestall any questions about any implications for InScribeX Web directions over the next year or so.
In short, Silverlight/.Net has been a successful technical choice for development of IXW to date and I plan to continue to use Silverlight through 2012 to further evolve IXW and explore more aspects of Ancient Egyptian in Unicode as a cross-platform Mac OSX/Windows (XP and later) solution.
Nevertheless there are some other desirable developments in Ancient Egyptian on computer that don’t fit into the IXW cross-platform approach, for instance deeper integration with other applications and efficient support for a variety of low power and touch screen devices. I’d like to share some thinking on these topics here in the near future.
Meanwhile IXW is currently at Preview 3.3 (the third update this year) and I’m on track for a 3.4 release next month. The ‘preview 3’ series to wrap this Winter with 3.5 which completes the first draft of the word list/dictionaries and incorporates more analysis on sign lists.
I’ve been holding back user interface changes until Preview 4 which is intended to enable continuation of the step by step approach I’ve taken this year. Whereas the 2011 theme has been building a more comprehensive dictionary, the main 2012 theme is teasing out the relationships between ‘Simplified Egyptian’, hieroglyphs in Unicode, and MdC encodings and I hope to continue the dynamic of updates every 2/3 months in the 4.x framework. More on this closer to the time.
Friday, 9 September 2011
Monday, 22 August 2011
InScribeX Web 3.3 now available
I've just released the latest version of InScribeX Web. Version 3.3 is the third update this year following version 3.1 (April) and 3.2 (June). The dictionary now contains over 28,000 references, an increase of around 50% from the 3.0 version released last year.
There are no changes to system requirements to run InScribeX Web so virtually all Windows and Intel-based Mac machines are supported.
As far as the draft (EGPZ) word list used as the basis of the dictionaries is concerned, references to Egyptian Grammar (Gardiner) and Concise Dictionary of Middle Egyptian (Faulkner) are regarded as complete for the time being with this version 3.3 (aside from any remaining corrections required).
For development of the word list, I currently have a hit-list of 580 existing references needing further research and about 2500+ further references to be added before reaching my target of what to include in the first draft. In practical terms, I'm aiming for an updated 3.4 release in the Autumn as a stepping stone to a completed first draft.
Aside from the word list/dictionaries, there are other topics such as MdC and InScribe document editing, Simplified Egyptian, Egyptian in HTML, expanding the Unicode repertoire, and mathematical modelling of Egyptian. None of which are planned for 3.4 although I'm still actively prototyping in these areas.
Note. InScribeX Web is still based on Silverlight 3 (or later) in the (possibly forlorn) hope that 'Moonlight' (the Linux equivalent to Silverlight for Windows and Mac) will catch up this year. However the whole cross-platform question has moved on since the first 2009 version of InScribeX Web most visibly with the growth of the smartphone user base, and the profile of first generation mass-market Tablet/Slate devices. I'll try to address some of the questions of how this affects Ancient Egyptian in the digital world, and InScribeX in particular, in future blog posts.
There are no changes to system requirements to run InScribeX Web so virtually all Windows and Intel-based Mac machines are supported.
As far as the draft (EGPZ) word list used as the basis of the dictionaries is concerned, references to Egyptian Grammar (Gardiner) and Concise Dictionary of Middle Egyptian (Faulkner) are regarded as complete for the time being with this version 3.3 (aside from any remaining corrections required).
For development of the word list, I currently have a hit-list of 580 existing references needing further research and about 2500+ further references to be added before reaching my target of what to include in the first draft. In practical terms, I'm aiming for an updated 3.4 release in the Autumn as a stepping stone to a completed first draft.
Aside from the word list/dictionaries, there are other topics such as MdC and InScribe document editing, Simplified Egyptian, Egyptian in HTML, expanding the Unicode repertoire, and mathematical modelling of Egyptian. None of which are planned for 3.4 although I'm still actively prototyping in these areas.
Note. InScribeX Web is still based on Silverlight 3 (or later) in the (possibly forlorn) hope that 'Moonlight' (the Linux equivalent to Silverlight for Windows and Mac) will catch up this year. However the whole cross-platform question has moved on since the first 2009 version of InScribeX Web most visibly with the growth of the smartphone user base, and the profile of first generation mass-market Tablet/Slate devices. I'll try to address some of the questions of how this affects Ancient Egyptian in the digital world, and InScribeX in particular, in future blog posts.
Monday, 8 November 2010
Simplified Egyptian: Numerals
This is the second of a series of notes on a systematic way of working with Ancient Egyptian Hieroglyphs in Unicode, following up from Simplified Egyptian: A brief Introduction.
What follows makes a lot more sense if you have a hieroglyphic font installed, see my post Egyptian Hieroglyphs on the Web (October 2010).
Ancient Egyptian, in common with other early mathematical systems, had no notion of negative integers or the digit Zero. The Egyptian numeral system is not positional in the modern sense. It is nevertheless straightforward to decode. Examples:
Egyptian 𓎉𓏻 is 42 (𓎉 represents 40, 𓏻 represents 2).
Egyptian 𓆿𓍣𓎉𓏻 is 4,242 (𓆿 represents 4000, 𓍣 represents 200).
Our modern decimal system uses positional notation where the numerals 0, 1 … 9 are used to represent units, tens, hundreds etc. by virtue of position. The Ancient Egyptians used different symbols based on a tally system as should be obvious from the examples. Fortunately, one similarity to modern notation is that the higher magnitude quantities were normally written first (i.e. to the left in Simplified Egyptian, which is always written left to right).
Normalized forms of numerals
The following list gives the preferred representation of hieroglyphs in Unicode for numerals in Simplified Egyptian.
1 to 9: 𓏺, 𓏻, 𓏼, 𓏽, 𓏾,𓏿, 𓐀, 𓐁, 𓐂.
10 to 90: 𓎆, 𓎇,𓎈, 𓎉, 𓎊, 𓎋, 𓎌, 𓎍, 𓎎.
100 to 900: 𓍢, 𓍣, 𓍤, 𓍦, 𓍦, 𓍧, 𓍨, 𓍩, 𓍪.
1,000 to 9,000: 𓆼, 𓆽, 𓆾, 𓆿, 𓇀, 𓇁, 𓇂, 𓇃, 𓇄.
10,000 to 90,000: 𓂭, 𓂮, 𓂯, 𓂰, 𓂱, 𓂲, 𓂳, 𓂴, 𓂵.
100,000: 𓆐
1,000,000: 𓁨
Each of these forms is available in Unicode as a unique character. For instance hieroglyph 2 is the character U+133FB 𓏻 EGYPTIAN HIEROGLYPH Z015A. Use these ‘normal’ forms for basic writing of numbers in Simplified Egyptian and avoid practices such as repeating 𓏺 for 𓏻 unless there is a compelling reason.
Note that large numbers such as 𓁨𓁨𓆐𓆐𓂮𓆽𓍣𓎇𓏻 2,222,222 were not generally encountered in ancient texts so replicating the 𓁨 and 𓆐 is rather anachronistic. An alternative multiplicative notation evolved for large numbers although uses are apparently rare so I’ll defer this topic for now.
Alternative forms of numerals
The use of normalized forms as given above makes it easy to find a number such as 𓎉𓏻 (42) in web documents, word processor and spreadsheet documents, and so forth (so long as software is sufficiently up to date of course). Unicode provides some alternative forms such as U+13403 𓐃 EGYPTIAN HIEROGLYPH Z015I (numeral 5) but these alternates should be avoided for numerals in Simplified Egyptian where at all possible (𓐃 actually has a specific use as a fraction).
Other arrangements are found in Egyptian texts, such as the following form of 35 ( from Gardiner, Egyptian Grammar, p194).
Simplified Egyptian takes the position that these kinds of numeral groups are a matter for more elaborate treatments of hieroglyphs where it is not acceptable to take license and write the number as 𓎈𓏾.
Repeating numeral 1 twice may look very much like numeral 2 in a hieroglyphic font but this practice should be avoided in Simplified Egyptian unless there is a good reason. The rationale is because most Ancient Egyptian mathematics survives in hieratic rather than hieroglyphic writing and the numerals were often simplified into a less tally-like glyph appearance. The fact that modern discussion of the hieratic often uses a hieroglyphic presentation should not detract from the original character-like behaviour. There is the important practical point that web searches and text processing work far better with normalized forms.
Rotated versions of units (e.g. 𓐄, 𓐅 …) and tens (𓎭 and 𓎮) are used in hieratic (and sometimes hieroglyphic) to number days of the month. Simplified Egyptian also adopts this convention (I hope to return to this on a topic about calendars).
Confusables
The stroke hieroglyphs U+133E4 𓏤 EGYPTIAN HIEROGLYPH Z001 (representing unity and ideogram) U+133FB 𓏺 EGYPTIAN HIEROGLYPH Z015A (numeral 1) are distinguished in Unicode. Fonts usually make the numeral stroke taller then the ideogram stroke, reflecting Ancient Egyptian conventions. Texts encoded in MdC often do not make this distinction but it is strongly recommended to do so in Simplified Egyptian so as to enable accurate text processing.
Likewise, the plurality signs U+133E5 𓏥 EGYPTIAN HIEROGLYPH Z002 and U+133E6 𓏦 EGYPTIAN HIEROGLYPH Z002A should be distinguished from numeral 3 U+133E5 𓏼 EGYPTIAN HIEROGLYPH Z015B.
In some fonts, characters such as U+0131 ı LATIN SMALL LETTER DOTLESS I and U+006C l LATIN SMALL LETTER L may look very similar to the Egyptian stroke. There are various other opportunities for confusion, for instance numeral 10 𓎆 can look very similar to U+2229 ∩ INTERSECTION and some other characters.
Other examples are the special forms for 1, 2 and 3 used in dates potentially confusable with MINUS SIGN, HYPHEN and other dashes (1), EQUALS SIGN (2), and IDENTICAL TO (3) but should never appear in a context where the meaning is unclear. The special form of 10 looks rather like SUBSET OF.
Simplified Egyptian hieroglyphs should never be written with any non-Egyptian characters just beacause they look similar.
Mathematics beyond numerals
Cardinal numbers, fractions, weights, lengths, and other measurements are matters for future topics about Simplified Egyptian.
Update. Apparently, according to Google, this note is the first writing of 𓎉𓏻 on the web, a reminder it will be interesting to see how use of hieroglyphs grows in months and years to come.
What follows makes a lot more sense if you have a hieroglyphic font installed, see my post Egyptian Hieroglyphs on the Web (October 2010).
Ancient Egyptian, in common with other early mathematical systems, had no notion of negative integers or the digit Zero. The Egyptian numeral system is not positional in the modern sense. It is nevertheless straightforward to decode. Examples:
Egyptian 𓎉𓏻 is 42 (𓎉 represents 40, 𓏻 represents 2).
Egyptian 𓆿𓍣𓎉𓏻 is 4,242 (𓆿 represents 4000, 𓍣 represents 200).
Our modern decimal system uses positional notation where the numerals 0, 1 … 9 are used to represent units, tens, hundreds etc. by virtue of position. The Ancient Egyptians used different symbols based on a tally system as should be obvious from the examples. Fortunately, one similarity to modern notation is that the higher magnitude quantities were normally written first (i.e. to the left in Simplified Egyptian, which is always written left to right).
Normalized forms of numerals
The following list gives the preferred representation of hieroglyphs in Unicode for numerals in Simplified Egyptian.
1 to 9: 𓏺, 𓏻, 𓏼, 𓏽, 𓏾,𓏿, 𓐀, 𓐁, 𓐂.
10 to 90: 𓎆, 𓎇,𓎈, 𓎉, 𓎊, 𓎋, 𓎌, 𓎍, 𓎎.
100 to 900: 𓍢, 𓍣, 𓍤, 𓍦, 𓍦, 𓍧, 𓍨, 𓍩, 𓍪.
1,000 to 9,000: 𓆼, 𓆽, 𓆾, 𓆿, 𓇀, 𓇁, 𓇂, 𓇃, 𓇄.
10,000 to 90,000: 𓂭, 𓂮, 𓂯, 𓂰, 𓂱, 𓂲, 𓂳, 𓂴, 𓂵.
100,000: 𓆐
1,000,000: 𓁨
Each of these forms is available in Unicode as a unique character. For instance hieroglyph 2 is the character U+133FB 𓏻 EGYPTIAN HIEROGLYPH Z015A. Use these ‘normal’ forms for basic writing of numbers in Simplified Egyptian and avoid practices such as repeating 𓏺 for 𓏻 unless there is a compelling reason.
Note that large numbers such as 𓁨𓁨𓆐𓆐𓂮𓆽𓍣𓎇𓏻 2,222,222 were not generally encountered in ancient texts so replicating the 𓁨 and 𓆐 is rather anachronistic. An alternative multiplicative notation evolved for large numbers although uses are apparently rare so I’ll defer this topic for now.
Alternative forms of numerals
The use of normalized forms as given above makes it easy to find a number such as 𓎉𓏻 (42) in web documents, word processor and spreadsheet documents, and so forth (so long as software is sufficiently up to date of course). Unicode provides some alternative forms such as U+13403 𓐃 EGYPTIAN HIEROGLYPH Z015I (numeral 5) but these alternates should be avoided for numerals in Simplified Egyptian where at all possible (𓐃 actually has a specific use as a fraction).
Other arrangements are found in Egyptian texts, such as the following form of 35 ( from Gardiner, Egyptian Grammar, p194).
Simplified Egyptian takes the position that these kinds of numeral groups are a matter for more elaborate treatments of hieroglyphs where it is not acceptable to take license and write the number as 𓎈𓏾.
Repeating numeral 1 twice may look very much like numeral 2 in a hieroglyphic font but this practice should be avoided in Simplified Egyptian unless there is a good reason. The rationale is because most Ancient Egyptian mathematics survives in hieratic rather than hieroglyphic writing and the numerals were often simplified into a less tally-like glyph appearance. The fact that modern discussion of the hieratic often uses a hieroglyphic presentation should not detract from the original character-like behaviour. There is the important practical point that web searches and text processing work far better with normalized forms.
Rotated versions of units (e.g. 𓐄, 𓐅 …) and tens (𓎭 and 𓎮) are used in hieratic (and sometimes hieroglyphic) to number days of the month. Simplified Egyptian also adopts this convention (I hope to return to this on a topic about calendars).
Confusables
The stroke hieroglyphs U+133E4 𓏤 EGYPTIAN HIEROGLYPH Z001 (representing unity and ideogram) U+133FB 𓏺 EGYPTIAN HIEROGLYPH Z015A (numeral 1) are distinguished in Unicode. Fonts usually make the numeral stroke taller then the ideogram stroke, reflecting Ancient Egyptian conventions. Texts encoded in MdC often do not make this distinction but it is strongly recommended to do so in Simplified Egyptian so as to enable accurate text processing.
Likewise, the plurality signs U+133E5 𓏥 EGYPTIAN HIEROGLYPH Z002 and U+133E6 𓏦 EGYPTIAN HIEROGLYPH Z002A should be distinguished from numeral 3 U+133E5 𓏼 EGYPTIAN HIEROGLYPH Z015B.
In some fonts, characters such as U+0131 ı LATIN SMALL LETTER DOTLESS I and U+006C l LATIN SMALL LETTER L may look very similar to the Egyptian stroke. There are various other opportunities for confusion, for instance numeral 10 𓎆 can look very similar to U+2229 ∩ INTERSECTION and some other characters.
Other examples are the special forms for 1, 2 and 3 used in dates potentially confusable with MINUS SIGN, HYPHEN and other dashes (1), EQUALS SIGN (2), and IDENTICAL TO (3) but should never appear in a context where the meaning is unclear. The special form of 10 looks rather like SUBSET OF.
Simplified Egyptian hieroglyphs should never be written with any non-Egyptian characters just beacause they look similar.
Mathematics beyond numerals
Cardinal numbers, fractions, weights, lengths, and other measurements are matters for future topics about Simplified Egyptian.
Update. Apparently, according to Google, this note is the first writing of 𓎉𓏻 on the web, a reminder it will be interesting to see how use of hieroglyphs grows in months and years to come.
Thursday, 4 November 2010
Silverlight in the News
Silverlight made it onto the BBC News on Tuesday – Coders decry Silverlight change. Take an unfortunate choice of words by a senior executive or two; add the reactive and ill-informed commentators on some web message boards; then mix in some natural concerns from developers. Bang! Tempests in teacups, the media love them.
Personally speaking, I find it reassuring to observe that the amateur tradition is alive and well in Microsoft and at least one major multinational company is not self-wrapped in a cloak of PR and spin-doctoring. That being said, the last few minutes of Doctor Who The Christmas Invasion ought to be made compulsory viewing for all senior executives.
As a developer I'm happy so long as .Net is treated as a strategic family of products. Thanks to Novell it may become so on Unix/Linux too (even if the Linux ‘community’ is slow to recognize what the third wave of Unix is really about). Hey theres another tabloid headline: C/C++ is dead!
I hope I'm not alone in being pleased to learn Silverlight 5 is not being rushed out. Especially if it means some of the niggles are resolved and the SL/WP7/WPF portability model improved. And Unicode 6.0 of course! A Mix 2011 Beta with Summer release please.
Two real news stories for developers:
An interesting talk at PDC 2010 for C# developers: ‘The Future of C# and Visual Basic’ by Anders Hejlsberg – don’t be put off like I almost was by the Visual Basic tag, it is hardly mentioned so we are not subjected yet again to the irony implicit in the keyword Dim. The main theme is simplification of Asynch programming with the new await keyword for the next .Net revision. Along with parallel constructs, this pattern brings very useful ways of exploiting multi-core processors to .Net in a clean software design. The talk is summarised here.
Developers in the .Net/WPF/Silverlight space should also check out PDC 2010: 3-Screen Coding: Sharing code between Windows Phone, Silverlight, and .NET by Shawn Burke. I alluded to the value of portable code last month in Of Characters and Strings although I didn’t highlight the .Net 4 changes that enable sharing of binary assemblies (a topic in its own right). The new tooling for Visual Studio to assist in creating Portable Assemblies, as previewed by Shawn, should be very helpful in managing the shared assembly model. It should also help focus Microsoft development on removing some of the irritating incompatibilities between Silverlight and WPF.
I just can’t wait for await.
Bob Richmond
Personally speaking, I find it reassuring to observe that the amateur tradition is alive and well in Microsoft and at least one major multinational company is not self-wrapped in a cloak of PR and spin-doctoring. That being said, the last few minutes of Doctor Who The Christmas Invasion ought to be made compulsory viewing for all senior executives.
As a developer I'm happy so long as .Net is treated as a strategic family of products. Thanks to Novell it may become so on Unix/Linux too (even if the Linux ‘community’ is slow to recognize what the third wave of Unix is really about). Hey theres another tabloid headline: C/C++ is dead!
I hope I'm not alone in being pleased to learn Silverlight 5 is not being rushed out. Especially if it means some of the niggles are resolved and the SL/WP7/WPF portability model improved. And Unicode 6.0 of course! A Mix 2011 Beta with Summer release please.
Two real news stories for developers:
An interesting talk at PDC 2010 for C# developers: ‘The Future of C# and Visual Basic’ by Anders Hejlsberg – don’t be put off like I almost was by the Visual Basic tag, it is hardly mentioned so we are not subjected yet again to the irony implicit in the keyword Dim. The main theme is simplification of Asynch programming with the new await keyword for the next .Net revision. Along with parallel constructs, this pattern brings very useful ways of exploiting multi-core processors to .Net in a clean software design. The talk is summarised here.
Developers in the .Net/WPF/Silverlight space should also check out PDC 2010: 3-Screen Coding: Sharing code between Windows Phone, Silverlight, and .NET by Shawn Burke. I alluded to the value of portable code last month in Of Characters and Strings although I didn’t highlight the .Net 4 changes that enable sharing of binary assemblies (a topic in its own right). The new tooling for Visual Studio to assist in creating Portable Assemblies, as previewed by Shawn, should be very helpful in managing the shared assembly model. It should also help focus Microsoft development on removing some of the irritating incompatibilities between Silverlight and WPF.
I just can’t wait for await.
Bob Richmond
Monday, 1 November 2010
Windows: The 25th Anniversary
The first version of Microsoft Windows was released over 25 years ago.
The conventional release date quoted is that of the Microsoft Windows 1.0 retail product for ‘IBM compatible’ PCs launched on 20th November 1985. The truth, as usual, is a little different. In the beginning, as now, Windows was distributed by computer manufacturers (OEMs) and OEM releases were shipping weeks before the Microsoft retail set, possibly as early as September. In the pre-internet era product launches worked differently to nowadays.
Since blogging on My first Home PC – recollections of the RM Nimbus PC-186 I’ve browsed some of my notes surviving from 1985. There was a lot of interest in a pre-Beta of Windows I built for the BETT show in January to accompany the PC-186 launch. Windows was fairly stable by then, I'd been running prototypes during 1984 tracking alpha versions of Microsoft code. The new Intel 80186 CPU in combination with a larger memory space made Windows more fluid on the Nimbus compared with contemporary IBM PC models and their look-alikes. In May I built a Beta release for the PC-186 which had fairly widespread distribution in the UK with the early Nimbus computers sold to the RM education market of schools and colleges. After painstaking work on optimizations of the graphics driver and improvements to the Nimbus-specific DOS application switching system (all written in 16 bit assembly language), I mastered the first release candidate in late August. I don’t recall exactly when the first release version actually shipped; perhaps the answer is hidden in my attic or the RM archives.
Trivia. Windows 1 install could fit on two 3.5”/720K disks. I also created a version to run on a single 720K drive system with Windows Write, Notepad, Paint and a few other lightweight apps. However the majority of PC-186 systems ran off network servers or hard drive. Familiar features of Windows such as GDI graphics, the message pump, EXE/DLL architecture were present right at the beginning. However the original windowing system treated applications as tiles; full overlapping windows did not appear until version 2 (1987).
Windows 1 was not a commercial success for Microsoft. RM grew one of the larger installed bases among OEMs. Most PC manufacturers (including RM beyond the PC-186) embraced the quirky and limiting IBM PC hardware/BIOS compatibility design; application vendors usually worked with these primitive interfaces rather than use a hardware-independent API like Windows. A dismal state of affairs for some years. Fortunately the Apple Mac and to a lesser extent Windows and various non-Intel based machines continued to point to the future for personal computers although in late 1985, I didn’t expect it would take over four years before the best-selling Windows 3.0 (1990) established the long term shape of the Personal Computer.
A few web searches today revealed that many aspects of the evolution of personal computers appear to be well hidden. It was interesting to be involved in the emergence of the PC for a few years so I suppose I ought to return to this period occasionally to fill in some more gaps in the online record.
Postscript. The practical side of history is learning from the past. Windows itself originated at a time when the situation with early personal computers was chaotic with few standards. An array of incompatible machines faced the software developer and the early user of PC technology. Today we have a mix of new and old generation technologies with systems like iOS, Android, WP7, Kindle, Windows, OSX, Desktop Linux, Xbox, PS3, Wii etc. etc. operating in a complex connected world; each with its own different developer stories to tell. A new chaos has emerged and, I suspect, we are once again looking to redefine the meaning of personal computing.
The conventional release date quoted is that of the Microsoft Windows 1.0 retail product for ‘IBM compatible’ PCs launched on 20th November 1985. The truth, as usual, is a little different. In the beginning, as now, Windows was distributed by computer manufacturers (OEMs) and OEM releases were shipping weeks before the Microsoft retail set, possibly as early as September. In the pre-internet era product launches worked differently to nowadays.
Since blogging on My first Home PC – recollections of the RM Nimbus PC-186 I’ve browsed some of my notes surviving from 1985. There was a lot of interest in a pre-Beta of Windows I built for the BETT show in January to accompany the PC-186 launch. Windows was fairly stable by then, I'd been running prototypes during 1984 tracking alpha versions of Microsoft code. The new Intel 80186 CPU in combination with a larger memory space made Windows more fluid on the Nimbus compared with contemporary IBM PC models and their look-alikes. In May I built a Beta release for the PC-186 which had fairly widespread distribution in the UK with the early Nimbus computers sold to the RM education market of schools and colleges. After painstaking work on optimizations of the graphics driver and improvements to the Nimbus-specific DOS application switching system (all written in 16 bit assembly language), I mastered the first release candidate in late August. I don’t recall exactly when the first release version actually shipped; perhaps the answer is hidden in my attic or the RM archives.
Trivia. Windows 1 install could fit on two 3.5”/720K disks. I also created a version to run on a single 720K drive system with Windows Write, Notepad, Paint and a few other lightweight apps. However the majority of PC-186 systems ran off network servers or hard drive. Familiar features of Windows such as GDI graphics, the message pump, EXE/DLL architecture were present right at the beginning. However the original windowing system treated applications as tiles; full overlapping windows did not appear until version 2 (1987).
Windows 1 was not a commercial success for Microsoft. RM grew one of the larger installed bases among OEMs. Most PC manufacturers (including RM beyond the PC-186) embraced the quirky and limiting IBM PC hardware/BIOS compatibility design; application vendors usually worked with these primitive interfaces rather than use a hardware-independent API like Windows. A dismal state of affairs for some years. Fortunately the Apple Mac and to a lesser extent Windows and various non-Intel based machines continued to point to the future for personal computers although in late 1985, I didn’t expect it would take over four years before the best-selling Windows 3.0 (1990) established the long term shape of the Personal Computer.
A few web searches today revealed that many aspects of the evolution of personal computers appear to be well hidden. It was interesting to be involved in the emergence of the PC for a few years so I suppose I ought to return to this period occasionally to fill in some more gaps in the online record.
Postscript. The practical side of history is learning from the past. Windows itself originated at a time when the situation with early personal computers was chaotic with few standards. An array of incompatible machines faced the software developer and the early user of PC technology. Today we have a mix of new and old generation technologies with systems like iOS, Android, WP7, Kindle, Windows, OSX, Desktop Linux, Xbox, PS3, Wii etc. etc. operating in a complex connected world; each with its own different developer stories to tell. A new chaos has emerged and, I suspect, we are once again looking to redefine the meaning of personal computing.
Tuesday, 26 October 2010
Egyptian Hieroglyphs on the Web (October 2010)
One year after the release of Egyptian Hieroglyphs in Unicode 5.2 there has been some progress in making hieroglyphs usable on the web although it is still early days. I hope these notes are useful.
If you can see hieroglyphs 𓄞𓀁 in this sentence, good. Otherwise. A few notes, and you can decide whether it might be better to wait until things have moved forward a little.
Information on Egyptian Hieroglyphs in Unicode
For information on Unicode 6.0 (the latest version) see www.unicode.org/versions/Unicode6.0.0/. While the full text for 6.0 is being updated, refer to the 5.2 version www.unicode.org/versions/Unicode5.2.0/ch14.pdf section 14.17. The direct link to the chart is www.unicode.org/charts/PDF/U13000.pdf where signs are shown using the InScribe font.
The Wikipedia article en.wikipedia.org/wiki/Egyptian_hieroglyphs is fairly accurate as far as it goes, and contains hieroglyphs in Unicode which can be viewed given a suitable browser and font.
InScribeX Web still contains the largest set of material viewable online including sign list, dictionaries and tools. You need a Silverlight (or Moonlight) compatible system (the vast majority of PCs, Linux, Mac or Windows, are fine.). There is no requirement you install a font. I last updated InScribeX Web in May – yes it is about due for an update but time is the enemy (and I’d like to see Moonlight 3 released first anyway).
Browsers
Of the popular web browsers, only recent versions of Firefox display individual Unicode hieroglyphs correctly. I expect the situation will change over the next few months. Meanwhile, use Firefox if you want to explore the current state of the art.
Search
Right now, only Google search indexes Unicode hieroglyphs (and the transliteration characters introduced at Unicode 5.1 in 2008). I expect at some point next year Bing and Yahoo will be brought up to date but meanwhile stick with Google.
Fonts
A satisfactory treatment of hieroglyphs on the web really needs smart fonts installed on your computer. I’m on the case (see Simplified Egyptian: A brief Introduction) but it will take some time until all the pieces of the puzzle including browser support come together (see ISO/Unicode scripts missing in OpenType and other comments here).
Neither Apple nor Microsoft provide a suitable font at the moment as parts of, or add-ons to, iOS, OSX, or Windows.
Meanwhile, in general I can’t advise about basic free fonts to use (fonts sometimes appear on the internet without permission of copyright holders and I don't want to encourage unfair use of creative work).
I will note an ‘Aegyptus’ font is downloadable at http://users.teilar.gr/~g1951d/ – the glyphs are apparently copied from Hieroglyphica 2000. I’ve not analyzed this yet.
For InScribe 2004 users I currently have an intermediate version of the InScribe font available on request (email me on Saqqara at [Saqqara.org] with ‘InScribe Unicode Font’ in the message title – I get a lot of spam junk mail. That way I can let you know about updates.).
Asking a user to install a font to read a web page is in general a non-starter; I think the medium term future for web sites is the Web Open Font Format (WOFF) once the dust settles on the new web browser versions in development. I’ll post here about the InScribe font in this context and make examples available when the time is ripe.
If you can see hieroglyphs 𓄞𓀁 in this sentence, good. Otherwise. A few notes, and you can decide whether it might be better to wait until things have moved forward a little.
Information on Egyptian Hieroglyphs in Unicode
For information on Unicode 6.0 (the latest version) see www.unicode.org/versions/Unicode6.0.0/. While the full text for 6.0 is being updated, refer to the 5.2 version www.unicode.org/versions/Unicode5.2.0/ch14.pdf section 14.17. The direct link to the chart is www.unicode.org/charts/PDF/U13000.pdf where signs are shown using the InScribe font.
The Wikipedia article en.wikipedia.org/wiki/Egyptian_hieroglyphs is fairly accurate as far as it goes, and contains hieroglyphs in Unicode which can be viewed given a suitable browser and font.
InScribeX Web still contains the largest set of material viewable online including sign list, dictionaries and tools. You need a Silverlight (or Moonlight) compatible system (the vast majority of PCs, Linux, Mac or Windows, are fine.). There is no requirement you install a font. I last updated InScribeX Web in May – yes it is about due for an update but time is the enemy (and I’d like to see Moonlight 3 released first anyway).
Browsers
Of the popular web browsers, only recent versions of Firefox display individual Unicode hieroglyphs correctly. I expect the situation will change over the next few months. Meanwhile, use Firefox if you want to explore the current state of the art.
Search
Right now, only Google search indexes Unicode hieroglyphs (and the transliteration characters introduced at Unicode 5.1 in 2008). I expect at some point next year Bing and Yahoo will be brought up to date but meanwhile stick with Google.
Fonts
A satisfactory treatment of hieroglyphs on the web really needs smart fonts installed on your computer. I’m on the case (see Simplified Egyptian: A brief Introduction) but it will take some time until all the pieces of the puzzle including browser support come together (see ISO/Unicode scripts missing in OpenType and other comments here).
Neither Apple nor Microsoft provide a suitable font at the moment as parts of, or add-ons to, iOS, OSX, or Windows.
Meanwhile, in general I can’t advise about basic free fonts to use (fonts sometimes appear on the internet without permission of copyright holders and I don't want to encourage unfair use of creative work).
I will note an ‘Aegyptus’ font is downloadable at http://users.teilar.gr/~g1951d/ – the glyphs are apparently copied from Hieroglyphica 2000. I’ve not analyzed this yet.
For InScribe 2004 users I currently have an intermediate version of the InScribe font available on request (email me on Saqqara at [Saqqara.org] with ‘InScribe Unicode Font’ in the message title – I get a lot of spam junk mail. That way I can let you know about updates.).
Asking a user to install a font to read a web page is in general a non-starter; I think the medium term future for web sites is the Web Open Font Format (WOFF) once the dust settles on the new web browser versions in development. I’ll post here about the InScribe font in this context and make examples available when the time is ripe.
Friday, 22 October 2010
Of Characters and Strings (in .Net, C#, Silverlight …): Part 2
"Your manuscript I’ve read my friend
And like the half you’ve pilfered best;
Be sure the piece you yet may mend –
Take courage man and steal the rest."
Anon (c. 1805)
As mentioned in Of Characters and Strings (in .Net, C#, Silverlight …): Part 1 many of the text processing features of .Net are such that code can be re-used over Silverlight, WPF, XNA, Mono, Moonlight etc. In this note I want to draw attention to a few key points and differences over platforms. It is far from a comprehensive analysis and I’ve skipped some important topics including collation, the variety of ways of displaying text ,and input methods.
A quick aside: I failed to highlight in Part 1 how 16-bit confusion in software is not limited to .Net, similar issues arise in Java (although Java has some helpful UTF-32 methods that .Net lacks) and the situation is far worse in the world of C/C++.
I’ll restrict attention to Silverlight 4, Silverlight 3 for Windows Phone 7 OS (WPOS7.0), and .Net 4. In case the significance of the opening quote passes the reader by, it is to be hoped that Silverlight 5 and any new branches on the .Net tree feature increased compatibility, deprecating certain .Net 4 elements where appropriate.
.Net Text in general
Many Silverlight (and WPF) programmers rely mainly on controls and services written by others to deal with text so are unfamiliar with the lower level implications – in this case the main thing is to make sure you test input, processing, and display components with text that contains non-BMP characters, combining character sequences, and a variety of scripts and fonts. You may also like to check out different culture settings. Relying on typing querty123 on a UK/US keyboard and using the default font is a sure-fire recipe for bugs in all but the simplest scenarios.
.Net text is oriented around UTF-16 so you will be using Unicode all or almost all the time. The dev. tools, e.g. Visual Studio 2010 and Expression Blend 4, work pretty well with Unicode and cope with the basics of non-BMP characters. I find the main nuisance with the VS 2010 code editor is that only one font is used at a given time, I can’t currently combine the attractive Consolas font with fall-back to other fonts when a character is undefined in Consolas.
For portability over .Net implementations, the best bet at present is to write the first cut in Silverlight 3 since for this topic SL3 is not far off being a subset of .Net 4. A good design will separate the text functionality support from the platform-specific elements, e.g. it’s not usually a good idea to mix text processing implementation in with the VM in a MVVM design or in the guts of a custom control. I often factor out my text processing into an assembly containing only portable code.
Text display on the various platforms is a large topic in its own right with a number of issues for portability once you go beyond using standard controls in SL, WPF etc. I’ll not go into this here. Likewise with text input methods.
Versions of Unicode
It would be really useful if the various flavours and versions of .Net were assertive on text functionality, e.g. Supports Unicode 6.0 (the latest version) or whatever. By support, I mean the relevant Unicode data tables are used (e.g. scripts, character info) not to imply that all or even most functionality is available for all related languages, scripts and cultures. Currently, the reality is much more fuzzy and there are issues derived from factors such as ISO/Unicode scripts missing in OpenType. Methods like Char.IsLetter can be useful in constructing a 'version detector' to figure out what is actually available at runtime.
Char structure
The .Net Char structure is a UTF-16 code unit, not a Unicode character. Current MSDN documentation still needs further updates by Microsoft to avoid this confusion (as noted in Part 1). Meanwhile the distinction should be kept in mind by developers using Char. For instance although the method Char.IsLetter(Char) returns true if the code unit is question is a letter-type character in the BMP, IsLetter(Char) is not in general a function you would use when looking for letters in a UTF-16 array.
It is therefore often a good idea to use strings or ‘string literal’ to represent characters, in preference to Char and ‘character literal’. Inexperienced programmers or those coming from a C/C++ background may find this odd to begin with, being familiar with patterns like
for (i=0; i < chars.Length; i++) { if (chars[i]=='A' { etc. }};
Fortunately, Char provides methods to work correctly with characters, for instance Char.InLetter(String, Int32). Char.IsLetter("A",0) returns true and the function works equally well for Char.IsLetter("\u10900",0) so long as your platform supports Unicode 5.1 (the version of Unicode that introduced U+10900 𐤀 PHOENICIAN LETTER ALF).
Char is largely portable apart from a few quirks. I find it especially puzzling that Char.ConvertFromUtf32 and Char.ConvertToUtf32 are missing from SL 3/4. Faced with this I wrote my own conversions and use these even on .Net 4.0 where the methods are available in Char, this way keeping my code portable and efficient.
I also wrote a CharU32 structure for use in UTF-32 processing (along with a StringU32) rather than extend Char to contain methods like IsLetter(int) for UTF-32 (as is done in Java). Makes for cleaner algorithms and something Microsoft may want to consider for .Net futures.
The CharUnicodeInfo class in SL 3/4 is a subset, missing GetDecimalDigit, a rather specialist helper for working with decimal numbers in non-Latin scripts and in most cases one would use GetNumericValue which is portable.
CharUnicodeInfo.GetUnicodeCategory and Char.GetUnicodeCategory have subtle differences.
String class
The .Net String is a sequential collection of Char objects whose value is immutable (i.e. its value is never modified but can be replaced. Informally, String encapsulates a read-only UTF-16 array. As with Char, the MSDN documentation tends to confuse Unicode character with UTF-16 code unit.
Comments above on use of string and string literal for Char also apply here. For instance the method IndexOf(Char) can only be used to find a Char, i.e. code unit. IndexOf(String) must be used to find an arbitrary Unicode character. If you try entering '\u10900' in C# in Visual Studio 2010, you will be warned “Too many characters in character literal” a reminder .NET character literals are not quite characters and "\u10900" is needed.
Much of String is portable. I’ll just mention a few differences:
Net 4.0 has extra String methods like StartsWith(String, Boolean, CultureInfo), a method which gives more flexibility in working with multiple cultures. SL 3/4 is oriented around current culture and invariant culture so not well suited to multilingual applications.
The whole model of culture and locale in software is way too complex to go into here, I’ll just say that the old fallacies like physical presence in Iceland means a user can speak Icelandic and never spends US dollars or that individuals use only one language have no place in the 21st Century.
SL 3/4 is missing the Normalize method, a very handy function when working with Unicode.
SL 3/4 has fewer constructors available to the programmer than Net 4 but some of those missing are error prone and wouldn’t normally be used in .Net 4.
StringBuilder class
Useful, gives measureable performance improvements constructing a lot of strings.
Very portable, just a few differences, I’ve not encountered these in real life code yet. Rather odd that Append(Decimal) is missing from SL 3/4 though.
StringInfo class
StringInfo is designed to work with actual Unicode characters so is very useful. I get the impression it is less well known among programmers than it ought to be.
Largely portable. However SL 3/4 is missing the SubstringByTextElements methods and LengthInTextElements both of which are handy for processing Unicode correctly in readable code. I’ve found myself simulating something similar to gain portability, although that being said, the portable enumeration methods make for a more common pattern.
Encoding classes
Encoding classes are often used while reading or writing text streams or converting from one text format to another, usually with a class derived from Encoding: SL 3/4 only provides the UnicodeEncoding (UTF-16) and UTF8Encoding classes, in contrast to .Net 4 which also has ASCIIEncoding, UTF7Encoding, and UTF32Encoding.
ASCII and UTF-7 are understandable, omission of UTF32Encoding is hard to see as anything other than an oversight given that UTF-32 is a useful weapon in the armoury of Unicode programming (although hardly ever a good idea for file streams). One of the first things I did in the early days of Silverlight 2 beta was to write conversion code. I hope Microsoft will add this to Silverlight 5, although for portability reasons it may be years before we can settle down with it.
The base Encoder class in .Net 4 has quite a number of extra methods and properties for Mail and Browser purposes as well as codepage handling. I tend to agree with the decision in SL to drop some of this complexity and discourage use of legacy stream formats even if that means occasionally custom code is required to convert ‘Windows ANSI’, ‘Mac OS Roman’ and the ISO/IEC 8859 series of 8 bit encodings.
The main features of Utf8Encoding such as BOM handling and exceptions are portable. Unicode normalization features are missing from SL 3/4 again, as with the String class.
Not the most portable part of .Net.
And like the half you’ve pilfered best;
Be sure the piece you yet may mend –
Take courage man and steal the rest."
Anon (c. 1805)
As mentioned in Of Characters and Strings (in .Net, C#, Silverlight …): Part 1 many of the text processing features of .Net are such that code can be re-used over Silverlight, WPF, XNA, Mono, Moonlight etc. In this note I want to draw attention to a few key points and differences over platforms. It is far from a comprehensive analysis and I’ve skipped some important topics including collation, the variety of ways of displaying text ,and input methods.
A quick aside: I failed to highlight in Part 1 how 16-bit confusion in software is not limited to .Net, similar issues arise in Java (although Java has some helpful UTF-32 methods that .Net lacks) and the situation is far worse in the world of C/C++.
I’ll restrict attention to Silverlight 4, Silverlight 3 for Windows Phone 7 OS (WPOS7.0), and .Net 4. In case the significance of the opening quote passes the reader by, it is to be hoped that Silverlight 5 and any new branches on the .Net tree feature increased compatibility, deprecating certain .Net 4 elements where appropriate.
.Net Text in general
Many Silverlight (and WPF) programmers rely mainly on controls and services written by others to deal with text so are unfamiliar with the lower level implications – in this case the main thing is to make sure you test input, processing, and display components with text that contains non-BMP characters, combining character sequences, and a variety of scripts and fonts. You may also like to check out different culture settings. Relying on typing querty123 on a UK/US keyboard and using the default font is a sure-fire recipe for bugs in all but the simplest scenarios.
.Net text is oriented around UTF-16 so you will be using Unicode all or almost all the time. The dev. tools, e.g. Visual Studio 2010 and Expression Blend 4, work pretty well with Unicode and cope with the basics of non-BMP characters. I find the main nuisance with the VS 2010 code editor is that only one font is used at a given time, I can’t currently combine the attractive Consolas font with fall-back to other fonts when a character is undefined in Consolas.
For portability over .Net implementations, the best bet at present is to write the first cut in Silverlight 3 since for this topic SL3 is not far off being a subset of .Net 4. A good design will separate the text functionality support from the platform-specific elements, e.g. it’s not usually a good idea to mix text processing implementation in with the VM in a MVVM design or in the guts of a custom control. I often factor out my text processing into an assembly containing only portable code.
Text display on the various platforms is a large topic in its own right with a number of issues for portability once you go beyond using standard controls in SL, WPF etc. I’ll not go into this here. Likewise with text input methods.
Versions of Unicode
It would be really useful if the various flavours and versions of .Net were assertive on text functionality, e.g. Supports Unicode 6.0 (the latest version) or whatever. By support, I mean the relevant Unicode data tables are used (e.g. scripts, character info) not to imply that all or even most functionality is available for all related languages, scripts and cultures. Currently, the reality is much more fuzzy and there are issues derived from factors such as ISO/Unicode scripts missing in OpenType. Methods like Char.IsLetter can be useful in constructing a 'version detector' to figure out what is actually available at runtime.
Char structure
The .Net Char structure is a UTF-16 code unit, not a Unicode character. Current MSDN documentation still needs further updates by Microsoft to avoid this confusion (as noted in Part 1). Meanwhile the distinction should be kept in mind by developers using Char. For instance although the method Char.IsLetter(Char) returns true if the code unit is question is a letter-type character in the BMP, IsLetter(Char) is not in general a function you would use when looking for letters in a UTF-16 array.
It is therefore often a good idea to use strings or ‘string literal’ to represent characters, in preference to Char and ‘character literal’. Inexperienced programmers or those coming from a C/C++ background may find this odd to begin with, being familiar with patterns like
for (i=0; i < chars.Length; i++) { if (chars[i]=='A' { etc. }};
Fortunately, Char provides methods to work correctly with characters, for instance Char.InLetter(String, Int32). Char.IsLetter("A",0) returns true and the function works equally well for Char.IsLetter("\u10900",0) so long as your platform supports Unicode 5.1 (the version of Unicode that introduced U+10900 𐤀 PHOENICIAN LETTER ALF).
Char is largely portable apart from a few quirks. I find it especially puzzling that Char.ConvertFromUtf32 and Char.ConvertToUtf32 are missing from SL 3/4. Faced with this I wrote my own conversions and use these even on .Net 4.0 where the methods are available in Char, this way keeping my code portable and efficient.
I also wrote a CharU32 structure for use in UTF-32 processing (along with a StringU32) rather than extend Char to contain methods like IsLetter(int) for UTF-32 (as is done in Java). Makes for cleaner algorithms and something Microsoft may want to consider for .Net futures.
The CharUnicodeInfo class in SL 3/4 is a subset, missing GetDecimalDigit, a rather specialist helper for working with decimal numbers in non-Latin scripts and in most cases one would use GetNumericValue which is portable.
CharUnicodeInfo.GetUnicodeCategory and Char.GetUnicodeCategory have subtle differences.
String class
The .Net String is a sequential collection of Char objects whose value is immutable (i.e. its value is never modified but can be replaced. Informally, String encapsulates a read-only UTF-16 array. As with Char, the MSDN documentation tends to confuse Unicode character with UTF-16 code unit.
Comments above on use of string and string literal for Char also apply here. For instance the method IndexOf(Char) can only be used to find a Char, i.e. code unit. IndexOf(String) must be used to find an arbitrary Unicode character. If you try entering '\u10900' in C# in Visual Studio 2010, you will be warned “Too many characters in character literal” a reminder .NET character literals are not quite characters and "\u10900" is needed.
Much of String is portable. I’ll just mention a few differences:
Net 4.0 has extra String methods like StartsWith(String, Boolean, CultureInfo), a method which gives more flexibility in working with multiple cultures. SL 3/4 is oriented around current culture and invariant culture so not well suited to multilingual applications.
The whole model of culture and locale in software is way too complex to go into here, I’ll just say that the old fallacies like physical presence in Iceland means a user can speak Icelandic and never spends US dollars or that individuals use only one language have no place in the 21st Century.
SL 3/4 is missing the Normalize method, a very handy function when working with Unicode.
SL 3/4 has fewer constructors available to the programmer than Net 4 but some of those missing are error prone and wouldn’t normally be used in .Net 4.
StringBuilder class
Useful, gives measureable performance improvements constructing a lot of strings.
Very portable, just a few differences, I’ve not encountered these in real life code yet. Rather odd that Append(Decimal) is missing from SL 3/4 though.
StringInfo class
StringInfo is designed to work with actual Unicode characters so is very useful. I get the impression it is less well known among programmers than it ought to be.
Largely portable. However SL 3/4 is missing the SubstringByTextElements methods and LengthInTextElements both of which are handy for processing Unicode correctly in readable code. I’ve found myself simulating something similar to gain portability, although that being said, the portable enumeration methods make for a more common pattern.
Encoding classes
Encoding classes are often used while reading or writing text streams or converting from one text format to another, usually with a class derived from Encoding: SL 3/4 only provides the UnicodeEncoding (UTF-16) and UTF8Encoding classes, in contrast to .Net 4 which also has ASCIIEncoding, UTF7Encoding, and UTF32Encoding.
ASCII and UTF-7 are understandable, omission of UTF32Encoding is hard to see as anything other than an oversight given that UTF-32 is a useful weapon in the armoury of Unicode programming (although hardly ever a good idea for file streams). One of the first things I did in the early days of Silverlight 2 beta was to write conversion code. I hope Microsoft will add this to Silverlight 5, although for portability reasons it may be years before we can settle down with it.
The base Encoder class in .Net 4 has quite a number of extra methods and properties for Mail and Browser purposes as well as codepage handling. I tend to agree with the decision in SL to drop some of this complexity and discourage use of legacy stream formats even if that means occasionally custom code is required to convert ‘Windows ANSI’, ‘Mac OS Roman’ and the ISO/IEC 8859 series of 8 bit encodings.
The main features of Utf8Encoding such as BOM handling and exceptions are portable. Unicode normalization features are missing from SL 3/4 again, as with the String class.
Not the most portable part of .Net.
Subscribe to:
Posts (Atom)