Towards Simplified Egyptian (March 2012)

I first mentioned Simplified Egyptian on this blog back in 2010, Simplified Egyptian: A brief Introduction, although the idea goes back several years before then.

The basis of Simplified Egyptian is to embed standard rules inside a font or functional equivalent (typically OpenType font) to instruct font rendering to combine hieroglyphs into predefined groups (much like the ligature ‘e’ with ‘acute’ normally combines into é e-acute).

So, why is it taking so long to implement? The first prerequisite to making Simplified Egyptian available in useful form was adding Egyptian Hieroglyphs to the Unicode standard (initiated 2006, finally released with Unicode 5.2 in October 2009). However a standard is necessary but not sufficient, popular Operating Systems (e.g. Windows, OS X, Linux, iOS, and Android) need to adequately support the standard. It is also essential that tools such as internet browsers, word processors and so on support standards compliant behaviour. Progress has been slow on all these fronts, disappointingly so.

Two positive developments during the last few months.

1. OpenType now (almost) formally recognizes the ‘egyp’ tag for fonts containing Egyptian Hieroglyphs (see http://www.microsoft.com/typography/otspec/scripttags.htm updated October 4, 2011 to bring the standard up to date, matching Unicode developments in recent years).
2. Firefox now recognizes ligatures in Egyptian fonts (not sure exactly when this happened but my test font was first seen to work correctly in Firefox 10 on Windows). Chrome, Internet Explorer, and Safari haven’t seen any progress in the 18 months since I published Egyptian Hieroglyphs on the Web (October 2010).

One minor negative two weeks ago. The Windows 8 consumer preview really ought to have worked since Unicode 6.x support is part of the design. However my Egyptian tests failed for Internet Explorer and several other programs and software interfaces. Hopefully those bugs will be shaken out before release and similar progress will be seen in OS X, iOS and Android before the end of 2012.

Looking at the trend it seems likely that by this time next year there will be enough pieces of the puzzle coming together to enable some useful Simplified Egyptian use scenarios on a variety of fully up to date systems with up to date software. Realistically, however, for most people 'up to date' is unlikely. Android phones are often stuck with obsolete versions of Android. Windows computers last for ages nowadays yet the cost of upgrading a version of Windows and Microsoft Office is normally prohibitively high for most people and organizations. As a rough estimate, it is going to take 3+ years before 25% of PCs (including tablets, excluding phones) are Simplified Egyptian capable.

Moving forward. Despite the apparently slow opportunities for uptake it seems worth starting the ball rolling now. Last year I created a list of about 1200 candidate rules for an implementation of Simplified Egyptian to test against the dictionary database and some sample documents. Further work is needed but I hope to provide a test implementation in InScribeX Web along with a Simplified Egyptian font this year, initially using a draft specification for the rules. IXW can be used to make sample web pages (using a downloadable version of the font) which we now know will be readable in Firefox at least. This work to be followed by ample time for comment and feedback on the specification from all, including experts in the subject. Timescales depend on when I can find some spare time (unless anyone knows of any funding!) but if all goes well, by around this time next year there will be a useable Simplified Egyptian system with at least some PC systems and a few standard apps that can use it. Then, as people upgrade systems and developers upgrade apps SE can reach out to an increasing audience.

Unfortunately a slow process with pitfalls e.g. web pages that only look correct on modern browsers unless we see a change in the habits of Apple, Google, Microsoft and other PC and device manufacturers. Most people working with hieroglyphs in software will continue to mainly use MdC-based solutions for some years to come on desktop/laptop systems. A topic I'll return to shortly.

InScribeX Web 3.5 available

The InScribeX Web software is now updated to preview version 3.5, replacing the previous version 3.4. The software now integrates about 30,500 references in the Egyptian dictionary database, and the accuracy level of the database has been substantially improved over 3.4. Apart from some minor performance oriented changes, there is no change to software functionality.

3.5 is the last of the 3.x series. I hope to continue the periodic update process every two to three months during 2012 as was done last year. I'm currently shooting for a 4.0 version in the Spring.

4.0 contains some usability changes and continues to support Windows and OSX platforms via Silverlight. It drops any attempt to support Linux desktop. My main objectives moving IXW forward this year are to 1. incorporate tools to enable use of Simplified Egyptian and 2. Make it easier to use Egyptian with Unicode in an up to date HTML5 Web browser context.

A note on Linux. When I started writing InScribeX Web the situation with Linux on desktop and laptop PCs looked fairly promising. Moonlight (the Linux equivalent of the Silverlight software used to deliver InScribeX in a web browser) was under active development by Novell. Since then, Linux has been very successful as the foundation of the proprietory Google Android operating system for mobile devices but interest in Linux desktop as an alternative to Microsoft Windows and Apple OSX has declined, not grown. The demise of Novell as an independent company caused Moonlight development to stop in an incomplete state meaning it is no longer realistic to take the current implementation of InScribeX Web onto the Linux desktop. This fact is only one consequence of the fact that the whole cross-platform perspective has changed in recent years thanks to low power microelectronics enabling interesting mobile devices. A topic I'd like to return to in the near future.

InScribeX Web 3.4 available

The InScribeX Web software is now updated to preview version 3.4, replacing the previous version 3.3. This uses the latest version of my word list/database for the dictionary feature. 3.4 contains over 30,000 references, representing an increase of about 2000 new entries since 3.3. There are also about 1500 corrections and clarifications to references present in the previous version. In short the database is getting close to my objectives for the first draft.

References in the dictionaries are as follows:

• AEM refers to Ancient Egyptian Medicine by J F Nunn (1996).


• DME refers to Concise Dictionary of Middle Egyptian by R O Faulkner (1961).


• EG refers to Egyptian Grammar by A Gardiner (Third edition, 1957).


• GHAD refers to Großes Handwörterbuch Ägyptisch-Deutsch by Rainer Hannig (2006).


• ME refers to Middle Egyptian by J P Allen (2000).


• Wb refers to Wörterbuch der Aegyptischen Sprach by A Erman and H Grapow (1926, 1971).

The largest single sub-collection of references is that from Wörterbuch which accounts for about 46% of the total number of references. Here my selection has been strongly guided by the ‘Beinlich word list’ although the German-English translations and transliterations into MdC machine coded hieroglyphs are my own.

The second largest sub-collection is from the Concise Dictionary, 38% of the total. The organisation of this Faulkner material largely follows the ‘Vygus word list’ though I’ve made a fairly large number of changes and MdC transliterations were done from scratch.

The smallest sub-collection currently is that from GHAD. This is only being used to add references relating to use of some of the rarer hieroglyphs.

I’d like to repeat and emphasise that InScribeX Web dictionaries are not intended to substitute for use of the various publications referenced. The user will want to refer directly to the Faulkner, Gardiner and other books to understand the context in which my dictionary entries are given. For instance Wörterbuch gives many alternative ‘spellings’ beyond those included in IXW at present. Egyptian Grammar has many instances of words not referenced in the current list, along with far more about the language and words beyond that of a simple list. Faulkner gives many references to the sources of his material.

To complete the first draft of the word list/database, I still have a parcel of work to tidy up references using rarer hieroglyphs so as to have a solid footing from which to tackle some practical issues of what to do with signs that are not in the Basic Egyptian Hieroglyphs set standardized in Unicode 5.2 (2009).

There is also a batch of references that needs re-checking and/or revised German-English translations.

I am therefore expecting several hundred more references and a bunch of corrections to the current set before drawing a line under this phase.

My current plan is still to incorporate these changes in a version 3.5 this winter to complete the IXW preview 3 developments. It also remains my intention to defer software changes (beyond anything of a minor technical nature) until this work is completed.

InScribeX Web directions (September 2011)

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.

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.

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.

The Real Truth about 42

Today is Sunday, 10/10/10, an appropriate day to reflect on the number 42. I’d better explain for the sake of the sanity of non-mathematicians that binary 101010 is in fact the number 42 in disguise.

An obvious feature of 42 is its prime factorization: 2x3x7. Obvious can be boring so I'll add the more obscure fact that the sum 2x3 + 2x7 + 3x7 = 41, just one less than 42. I don’t know if anyone has named the class of numbers whose pair-wise sum of its prime factors plus 1 equals the number itself. That sum emerged en route on a visit to Hove so if anyone really needs a name how about a ‘Hove number’? Not an exceptional inspiration, but possibly a brand new observation to add to a large literature on the topic of 42.

More ‘fascinating’ facts about 42 can be found at Wikipedia - 42 (number) where I learned Charles Dodgson, writing as Lewis Carroll, was also fond of 42. Perhaps it’s in the Oxford tap water. Computer programmers may be amused by the fact that the wildcard character ‘*’ has character code 42 in ASCII and Unicode.

Truth is, the number 42 has been regarded as special for (probably) over 5000 years.

Traditionally, Ancient Egypt was divided into administrative districts, usually called ‘nomes’ nowadays (from the Greek word for ‘district’, Νομός; also Egyptian spꜣt/𓈈/etc.). Curiously when I placed ideograms for the 20 nomes of Lower Egypt and 22 nomes of Upper Egypt into the first draft for the (as then) proposed Unicode standard for Egyptian Hieroglyphs, it was only afterwards that 42 clicked ‘not that number AGAIN’. I expect the fame of 42 goes back to the dawn of writing and mathematics itself.

Thoth, a (male) Egyptian deity (Egyptian Ḏḥwty; 𓅝, 𓁟 etc.), was associated with wisdom, magic, writing, mathematics, astronomy and medicine. Maat, a (female) deity (Egyptian Mꜣꜥt; 𓁦, 𓁧 etc.) was associated with truth, equilibrium, justice and order. She represents a fundamental concept in Ancient Egyptian philosophy. In some later traditions which featured male-female pairing between deities, Thoth and Maat were linked together (although rarely in a romantic sense). Both deities are prominent in the judging of the deceased as featured in the ‘Book of the Dead’.

The Papyrus of Ani gives a list of 42 ‘negative confessions’ for the deceased – “I have not committed sin”, “I have not murdered” etc. The ‘Ten Commandments’ of the Old Testament can be thought of as a condensed version. Sometimes referred to as ‘the doctrine of Maat’. 42 associated deities, supervised by Thoth, were assigned to the judgment of the deceased during his or her passage through the underworld.

I can’t resist mentioning that the modern name “Book of the Dead” was invented by Karl Richard Lepsius (the Egyptian rw nw prt m hrw has been more literally translated as the ‘Spells of Coming Forth by Day’ or similar). It can be no more than coincidence that the publication in question, “Das Todtenbuch der Ägypter nach dem hieroglyphischen Papyrus in Turin mit einem Vorworte zum ersten Male Herausgegeben” was published in 1842. Lepsius was a major and influential figure during the emergence of the modern discipline of Egyptology as well as being responsible for the creation of the first hieroglyphic typeface as implemented by typographer Ferdinand Theinhardt, the “Thienhardt font”.

The ’42 Books of Thoth’ aka ’42 Books of Instructions’ were composed from around 3rd century BC supposedly based on earlier traditions. Only fragments remain from this Hermetic text which apparently contained books on philosophy, mathematics, magic, medicine, astronomy etc. A legendary source, highly influential in later traditions of mysticism, alchemy, occultism and magic. The 42 Books have been believed by some to contain the hidden key to the mysteries of immortality and the secrets of the Universe. A fruitful topic I guess for Dan Brown and other writers of fiction.

Trivia. Visiting the South Coast last December, I was amused to discover the return rail-fare from Oxford was £42. Got me thinking how often 42 has cropped up in my life. Coincidence can be good fun. I decided to keep an eye open for incidents involving near neighbours of 42: 40, 41, 43, and 44. A prospect so intriguing and exciting I’m surprised I woke up on the approach to a snow and ice encrusted Hove before the train rattled on its way to Worthing. I can now report the scientifically meaningless result after 10 months ‘research’. Those worthy siblings 40, 41, 43, 44 just don’t cut the mustard compared with their famous colleague. Perhaps it’s just me. Although when my son started at secondary school this September, there was a certain inevitability about his reply when asked in what number classroom his form was based. For a moment I thought he was kidding.

I can't really leave the topic without mentioning the obvious.

The writer most credited for the prominence of 42 in modern times is the late Douglas Adams. In his radio series “Hitchhikers Guide to the Galaxy” (BBC Radio 4, 1978), the “Answer to the Ultimate Question of Life, the Universe, and Everything” is calculated to be 42. The meme exploded. Adams later claimed to have picked 42 pretty much at random.

We will never know whether Adams knew of the antiquity of 42 as a profound and famous number, indeed as the answer to his very own ultimate question. Its easy to speculate that he must have held some knowledge, at least at some subconscious forgotten level. A remarkable coincidence otherwise, unless 42 is in fact the answer.

Yet not impossible. After all there is something rather cute and appealing about 42. She still looks good for her age. Don’t you think so too?

ISO/Unicode scripts missing in OpenType

Unicode 6.0 release is imminent (see www.unicode.org), a year after the release of Unicode 5.2 (October 2009). Version 6.0 introduces three new scripts: Mandaic, Batak, and Brahmi. There are extensions to other scripts and many other improvements and clarifications.

An aside to anyone involved in HTML5 standardisation. It would be a really good idea if Unicode 6.0 compatibility were specified as part of the formal standard for HTML, and included in conformance testing.

OpenType is the de-facto standard for font technology and as such an essential part of implementating a script. The latest set of script tags (codes) for OpenType is given at www.microsoft.com/typography/otspec/scripttags.htm (document last updated in January 2008 when checked today).

The current ISO-15924 list of script codes is given at www.unicode.org/iso15924/iso15924-codes.html.

Unfortunately, some Unicode scripts are missing from the OpenType script tag list. This is long overdue an update.

The fact that Unicode 5.2 has not been incorporated in OpenType specifications a year after release makes for an unsatisfactory situation. I am writing to those concerned and encourage others to do likewise.

The following 15 Unicode scripts are missing from OpenType:

Avestan (134, Avst, Unicode 5.2)
Bamum (435, Bamu, Unicode 5.2)
Batak (365, BatkUnicode 6.0)
Brahmi (300, Brah, Unicode 6.0)
Egyptian hieroglyphs (050, Egyp, Unicode 5.2)
Imperial Aramaic (124, Armi, Unicode 5.2)
Kaithi (317, Kthi, Unicode 5.2)
Lisu (Fraser) (399, Lisu, Unicode 5.2)
Mandaic, Mandaean (140, Mand, Unicode 6.0)
Old Turkic, Orkhon Runic (175, Orkh, Unicode 5.2)
Inscriptional Pahlavi (131, Phli, Unicode 5.2)
Inscriptional Parthian (230, Prti, Unicode 5.2)
Samaritan (123, Samr, Unicode 5.2)
Old South Arabian (105, Sarb, Unicode 5.2)
Tai Viet (359, Tavt, Unicode 5.2)

As a footnote. Not available in Unicode yet, but of interest to Egyptology are:

Meroitic Hieroglyphs (100, Mero, formal proposal with WG2)
Meroitic Cursive (101, Merc, formal proposal with WG2)
Egyptian Hieratic (060, Egyh, no formal proposal yet , contact me if you have any ideas)
Egyptian Demotic (070, Egyd, no formal proposal yet, contact me if you have any ideas)

There are also some desirable additions to be made to Egyptian Hieroglyphs (I'd like to see something with ISO/WG2 in 2012 if not before).

Simplified Egyptian: A brief Introduction

I coined the term ‘Simplified Egyptian’ several years ago as a technical approach to making Ancient Egyptian in hieroglyphs more useable in the modern digital world (see HieroglyphsEverywhere.pdf, Bob Richmond, 2006).

The snag in creating an implementation has long been external factors such as the status of web browsers and Word Processors, along with the associated de-facto or formal industry standards. The devil is in the detail and there are many idiosyncrasies in modern technology once one departs from the everyday. A notion like Simplified Egyptian would be no more than a curiosity if it were not widely accessible on personal computers and other digital devices.

One factor in the equation was the need to include Egyptian Hieroglyphs in the Unicode standard (published in Unicode 5.2, October 2009). Implementations of 5.2 are slowly becoming available; for instance Google web search now accepts hieroglyphs although Microsoft Bing and Yahoo search do not yet. Another key factor is support by Internet browsers. Firefox 3.6 looks viable now and I expect the latest versions of other popular browsers to support Egyptian to some degree within the next few months.

As various pieces of the technical puzzle appear to be coming together in the 2011 timeframe I thought it would be useful to summarise now what I see Simplified Egyptian being about. I envisage putting more flesh on the bones in future blog posts on a prototype implementation as leisure time permits (this is an unfunded project at present so time is the enemy).

Simplified Egyptian (SE) works as follows.

1. Define a subset of the Unicode 5.2 list of characters for Egyptian Hieroglyphs, avoiding variants and rarely used (in Middle Egyptian) characters.
2. Define fixed rules for combining hieroglyphs into groups so these rules can be implemented in TrueType/OpenType fonts or alternative rendering methods.
3. Use left to right writing direction.
4. Define data tables and algorithms for text manipulation and sorting.
5. Define ‘normalized forms’ for guidance on ‘correct’ ways of writing and processing Simplified Egyptian.

A more recent notion - Super-Simplified Egyptian (SSE) - takes these principles further by identifying an even more condensed subset of the Hieroglyphic script, a proper subset of SE, with a palette of fewer than 200 hieroglyphs.

There is no question that the SE method is highly anachronistic, SSE extremely so. Nevertheless, there is some utility in the approach.

I am also aware that superficially what I’m proposing suggests a flavour of modernised Egyptian at odds with the requirements of Egyptology for working with an ancient language with script usage that evolved over 3000 years. I will make no apologies for the fact that this is indeed one application and if SE encourages wider understanding of Egyptian albeit at a reduced technical level that is no bad thing in my opinion. Nevertheless, the most interesting aspect from my own interest is the question of how to use such a mechanism to enable improvements for academically sound publication and study of ancient texts in the context of 3000 years of language/script evolution. A non-trivial topic I shall not touch on further today.

My plan is to make available some small working examples of Simplified Egyptian on a series of web pages during the next few weeks. These examples use a WOFF (Web Open Font Format) font derived from my InScribe font. The reasons for doing this now are twofold.

1. A new generation of Internet Browsers pays greater attention to industry standards and should be capable of supporting Simplified Egyptian. Firefox 4 and Internet Explorer 9 are in Beta at the moment and I want to make the samples available for browser testing in case there is a need to shake out any browser bugs.

2. InScribe 3 for Windows will not use Simplified Egyptian. Originally it was my intention that SE would be a feature but it turned out to introduce too many complications in modes of use. Nevertheless, InScribe 3 retains some ‘SE-friendly’ characteristics and I want to be able to test these for real on the Web as I complete work on the software.

The samples will not work for users of older browser technology (right now this is a high ninety something per cent of internet capable devices). My short term concern is only that an elegant and simple to use implementation works as and when devices gain adequate support for internet standards.

That is not to say that workarounds can’t be contrived for devices whose manufacturers or users are not able or prepared to adapt to the new standards-based internet landscape. I'm happy to hear of any proposals.

Right now, this means use Firefox 3.6 or later to view samples as intended. I’m also tracking Chrome, Internet Explorer 9 Beta and Safari releases.

Quick test for Ancient Egyptian in web browsers (September 2010)

A quick test note to check Ancient Egyptian in Web browsers.

If you have a (Unicode 5.2 compatible) Egyptian font installed on your system, the next few lines ought to make sense:

ꜣꜢiIꜥꜤwWbBpPfFmMnNrRhHḥḤḫḪẖH̱sSšŠḳḲkKgGtTṯṮdDḏḎ

(in MdC this Egyptian transliteration reads +taa*AA*iIwWbBpPfFmMnNrRhh*HH*xx*XX*ss*SS*qq*kKgGtt*TT*dd*DD*)

𓄿𓇋𓏭𓂝𓅱𓃀𓊪𓆑𓅓𓈖𓂋𓉔𓎛𓐍𓄡𓋴𓈙𓈎𓎡𓎼𓏏𓍿𓂧𓆓

(in MdC these Egyptian hieroglyphs read +s-A-i-y-a-w-b-p-f-m-n-r-h-H-x-X-s-S-q-k-g-t-T-d-D)

In fact, this is a FAIL for hieroglyphs today on Windows for Chrome (6.0.472.63), Firefox (3.6.10) Internet Explorer 9 (Beta 9.0.7930), and Safari (5.0.2). Only Firefox successfully displays the transliteration.

Tantalizingly, the Firefox edit box does work:

Technically, all a browser needs to do is ennumerate all fonts on the host system and if the font implicit in the HTML is not present, use any font that supports the characters if available. Perhaps there needs to be some magic setting in the TrueType fonts for the browsers to work although this ought not to be necessary so I will count this as a multi-browser bug.

The lines should read:

Update. This site, Blogger, turned my HTML hieroglyph strings into entities, e.g. hieroglyphs in UTF-8 into  �� etc. Firebox has a bug in this case (entities in Unicode SMP) but not when raw UTF-8 is used in HTML so Firefox is very close to working, indeed it is good for many web pages. Blogger is a bit broken, the entities are simply confusing and bring nothing to the party.

Mangaglyphics

Apparently the Japanese word manga (katakana マンガ, kanji 漫画, hiragana まんが) can be loosely translated to English as “whimsical pictures”. Distinctive manga styles have seen growing popularity outside Japan during the last few decades predominantly through comic book, cartoon, and video game formats.

Some time ago I had the crazy notion that there are some interesting ways to combine the tradition of ancient Egyptian Hieroglyphs with manga styles in an entertaining way, mangaglypic seemed like the word rather than the equally obvious hieromanga. Fun, possibly with some educational value.
However with the work that needs to be done on improving accessibility to non-whimsical applications of ancient Egyptian on personal computers and other devices mangaglyphic is pretty low on my software to do list.

So why mention the term right now? Partly because it looks like a mangaglyph or two are creeping unasked into the InScribeX Web user interface. Partly because I’d be delighted to hear from artists or others experimenting with this style of image. However what actually stimulated my writing today was discovering the search engine bing.com still returns zero results for mangaglyphic or related words and google.com returns only one result. So in the unlikely event the term catches on at all I wanted to state mangaglyphic is meant to be a generic word. No attempts to register trademarks etc. please.

Lost in Hieroglyphs

One evening in February 2006, I noticed there had been a huge number of downloads of a draft specification I'd written about the encoding of Egyptian Hieroglyphs in the Unicode Private Zone (EGPZ=EGyptian in the Private Zone). Over 10,000 downloads within a week. A little detective work yielded the discovery that some hieroglyphs had appeared in the TV series 'Lost' and in the thirst for knowledge ... well, goodness knows what the legion of Losties made of such a dry document.

A proposal for Basic Egyptian Hieroglyphs in Unicode by Michael Everson and myself was starting to take shape at that time. I had also begun drafting a presentation entitled Hieroglyphs Everywhere for the Informatique et Egyptologie (I&E 2006) conference being held in Oxford that Summer. So the timing of the 'Lost event' was coincidental, indeed an encouragement to explore further the notion of making Ancient Egyptian more accessible in popular culture beyond the academic dimension.

Four years after. The EGPZ specification was released in 2006, The Unicode 5.2 Standard (October 2009) now contains Basic Egyptian Hieroglyphs. The process of making Ancient Egyptian more accessible continues. I&E 2010 is being held in Liege this July and I've just started writing a minor revision of the EGPZ specification and a followup to the Hieroglyphs Everywhere talk.

And 'Lost' is coming to an end on Tuesday 23rd May after six seasons. Perhaps the full significance of the statue of Taweret will be revealed. Most likely not and thats a good thing in my opinion, the world is a better place for some notions to remain wrapped in mystery.

Then there is the fact that 42 is one of the 'Lost Numbers'.  The mathematics and science of coincidence. Another day!

InScribeX Web Preview 3 released

I have just released Preview 3 of the InScribeX Web software on http://www.inscribex.com/. This version replaces Preview 2 for Windows and Mac users and works with Silverlight version 3 or 4. Linux users will probably want to stick with Preview 2 which runs with Moonlight 2 for the time being (see note below).

As illustrated, the user interface has been changed to require less screen space. This is very useful on low resolution displays, especially those found on netbooks. I have also chosen this two page view for the dictionaries so English-Egyptian and Egyptian to English can be viewed simultaneously (although it is probable that additional ways of working with the dictionaries will follow at some point).

Some features I had hoped to include in Preview 3 have been deferred in order that the software works with the current pre-release of Moonlight 3 (Moonlight is the equivalent to Silverlight for Linux systems). I hope to update Preview 3 over the summer to track Moonlight development and make a few additions and changes to functionality, the most interesting being  to add some basic UMdC editing features and include some revised dictionary content.

Preview 3 is about 25% smaller than preview 2 so loads faster over the web.

Coming soon ... InScribe Web Preview 4

Preview 4 is being developed in parallel to Preview 3 and I've adopted a development approach to allow components to be shared between the two versions. This sounds rather complicated but makes sense from my development perspective as part of the strategy of making InScribeX cross-platform over a range of computers and other devices. For the majority of Windows and Mac users, all this means is you should use Preview 3 for the time being then switch to Preview 4 when it is available (best guess sometime this summer).

Preview 4 takes advantage of new features in Silverlight 4 to enable printing and rich text editing of Egyptian texts among other enhancements. Watch this space.

InScribe Web on Linux

Moonlight 2 was released in December 2009 as a Linux FireFox plugin (this can be downloaded for popular modern Linux distributions from www.go-mono.com/moonlight/download.aspx). Moonlight 2 enables InScribe Web Preview 2 operation on Linux systems.

Pre-release 'alpha quality' Moonlight 3 plugins for Firefox and Chrome browsers on Linux can be downloaded from go-mono.com/moonlight/prerelease.aspx. InScribe Web Preview 2 appears to work as with Moonlight 2. InScribe Web Preview 3 mostly appears to run okay on the most recent (April) plugin versions. However one unavoidable problem at the moment is the full dictionaries take an extremely long time to load. I've therefore limited the dictionaries to 100 entries under Linux for the time being until the Moonlight bug is fixed (a good reason to stick with InScribe Web Preview 2). I'm planning to track Moonlight 3 pre-release versions towards release, updating Preview 3 if necessary and feasible.

All being well, Moonlight 3 will be released by Novell by Autumn with full Silverlight 3 compatibility so I can retire InScribe Web Preview 2 leaving Preview 3 a fully cross platform solution for Windows/Mac/Linux.

HTML5, Fonts, and the Web Open Font Format (WOFF)

WOFF is a file format intended to enable downloadable fonts to be used on web pages. Developed during 2009, WOFF 1.0 was submitted last month (www.w3.org/Submission/2010/03/, April 8th 2010) by Microsoft Corporation, Mozilla Foundation and Opera Software to W3C, the standards organisation for web technology.

WOFF is not the first technology for downloadable fonts but it is the first to carry strong industry support. An implementation is already available in Firefox 3.6. WOFF is expected to be supported in new versions of Chrome, Internet Explorer, Opera and Safari. In my opinion it is likely that WOFF will become the preferred way of including specialist fonts in HTML5 so a very positive development.

This is significant for applications of Ancient Egyptian and other specialist scripts since WOFF provides an effective way of displaying those scripts on web pages without expecting suitable fonts to have been installed on the host device. WOFF files are compressed and subsets can be used to keep download sizes much smaller than if the original (e.g. TrueType) fonts were used. There are indications that font suppliers will be open to distribution of fonts in WOFF format (in most cases commercial fonts are not licensed for distribution in TTF etc. formats although there are rules that in many instances allow embedding in documents such as PDF files).

It is impractical to use WOFF for published web sites today except for experimental purposes since the vast majority of web browsers in use do not know how to use WOFF. However software tools already exist. As far as my own work is concerned, I’m working on the assumption that over 70% of web browser usage will be WOFF compatible by the end of 2011 (though this is a pure guess!) at which point it becomes appropriate to make web pages that rely on WOFF for Egyptian.

I’d like to state the short to medium term status for my work concerning Ancient Egyptian on the web relating to WOFF.

1. InScribeX Web integrates a version of my InScribe font so doesn’t rely on browser support. I expect WOFF support will become part of the InScribeX story at some point in time, but not during 2010.
2. Meanwhile I'd be pleased to hear from anyone also looking at WOFF applications for Egyptian in Unicode and HTML5.
3. I’m interested in the use of ligatures and combining rules to enable ‘Simplified Egyptian’ to be written without markup so will be testing some WOFF implementations to try and detect any bugs in OpenType feature handling so these can be eliminated by the time browser support for WOFF is widely available.

Introduction to the UMdC file format for Ancient Egyptian

UMdC (Unicode Manuel de Codage) is a new file format for documents containing Ancient Egyptian. This informal note is aimed at people familiar with versions of the ‘Manuel de Codage’ (MdC) protocol as used in applications such as InScribe, JSesh, MacScribe and WinGlyph. My objective here is to explain a little about what UMdC is, why I’ve devised this new format and how I envisage it being used. The good news is the fact that UMdC is highly compatible with MdC so there is little in the way of learning curve required and there is no need to ditch existing software tools and methodologies entirely.

Manuel de Codage
A scheme for representing Ancient Egyptian was published in 1988. Manual for the Encoding of Hieroglyphic Texts for Computer-input (Jan Buurman, Nicolas Grimal, Jochen Hallof, Michael Hainsworth and Dirk van der Plas, Informatique et Egyptologie 2, Paris 1988). This is generally known as Manuel de Codage or simply MdC. It is useful to refer to the original scheme as MdC88.

MdC88 was never a formal specification and has been interpreted and extended in several ways for use by applications that work with Ancient Egyptian. There is no ‘standard’ MdC, only dialects. In many simple cases this is not a problem, everybody agrees what ‘+sO34-N37:Y1’- represents as hieroglyphs. However for more complex texts there is scope for ambiguity, confusion and incompatibility.

UMdC basics
Here is a list of some UMdC characteristics. My goal has been to keep things as simple as possible and avoid scenarios which may be useful for some purposes but are not in my opinion appropriate to be addressed in an MdC-like approach. It is not a specification; I simply want to give a flavour of what is involved.

1. UMdC files must use the ‘.umdc’ file extension (i.e. umdc file type) except in special circumstances. MdC88 did not define rules for file names so several alternatives are in use.
2. UMdC files must use UTF-8 (Unicode 8 bit) encoding. Unicode allows most modern languages to be written from English to Kanji to Arabic and Hebrew. MdC88 specified ASCII so even the accented characters popular in some European languages are not present. Dialects of MdC often use the ISO-8859-1 (Latin-1 Western European) 8 bit coding or similar but more by accident than design and there is a lot of scope for confusion.
3. UMdC files begin with the 8 characters ++++UMdC so software knows this is really meant to be a UMdC file and can proceed accordingly. MdC88 compatible software will interpret this sequence as a comment. It is permissible to precede this sequence with the Unicode BOM (some text editors such as Windows Notepad add the BOM and it would be confusing not to accept this) although doing so may throw some software!
4. UMdC follows MdC88 in stating that all text content is preceded by +l (normal text), +b (normal, bold text), +i (normal, italic text), +t (transliteration), +c (Coptic), +g (Greek) +s (hieroglyphs) and ++ (Comment). The ! and !! conventions for end of of line, end of page are used. This means UMdC is very compatible with MdC at one level. The rules here are however more tightly defined as will be detailed in specifications.
5. UMdC adds the notion of umdc-instruction. All umdc-instructions begin with the three characters +++. The beauty of this approach is MdC88-compatible software interprets a umdc-instruction as a comment so although information may be unused hieroglyph segments etc. survive unchanged. UMdC uses umdc- instructions for most new functionality such as rich text formatting options.
6. UMdC version 1.0 requires that Gardiner codes and mnemonics are based on EGPZ 1.0 specifications. MdC88 defined Gardiner codes but this set was superseded so although everyone agrees what “A1” and "n" mean the same is not true beyond the common Egyptian Grammar set.
7. Applications can elect to use application-specific umdc-instructions to implement features such as special hieroglyph layout options or non-EGPZ coding conventions. This is not encouraged except where unavoidable and there are rules.
8. UMdC itself cannot be extended by an application provider, only as an official change to the specification. A non-complying UMdC file counts as an error pure and simple; there are no 'dialects'. Rules govern future official extensions to avoid breaking software written to the current specification.

In short, the UMdC file containing

++++UMdC+lHello +sV9:W24-O49-!

Corresponds to MdC88

+lHello +sV9:W24-O49-!

UMdC Development Roadmap
I am working on UMdC documentation (to go on http://www.egpz.com/). This consists of user-oriented material, a technical reference, and implementation guidance for software writers and others who want to support UMdC.

I am also working on a complete implementation of a document editor for umdc files to be included in InScribeX Web (Preview 4) (to go on http://www.inscribex.com/).

UMdC support is also being included in a second edition of the InScribe 2004 software, namely InScribe 2004SE. As part of this, the ‘.InScribe’ file format is being adapted to be 100% UMdC compatible. Support for ‘.InScribe’ and ‘.umdc’ file integration into Windows search is another useful feature.

My aim is to get most if not all of this work completed in advance of the Informatique et Égyptologie 2010 meeting to be held early July in Liège. The project is unfunded so we shall see!

Silverlight 4 Release, Moonlight 3 Preview, and InScribeX Web

Last Thursday Microsoft released Silverlight 4, a significant milestone for the InScribeX Web project since SL4 brings a useful set of new functionality for delivering the InScribeX Web approach to Ancient Egyptian. Silverlight 4 runs on Windows (XP, Vista, 7) and Mac OSX (Intel systems). No platform change since version 3 beyond Google Chrome web browser now officially supported.

Meanwhile Novell continues development of Moonlight, the open source Linux equivalent to Silverlight. Moonlight is running several months behind Silverlight with the current release Moonlight 2 corresponding to Silverlight 2. Moonlight 3 release is expected sometime this Summer although previews have been available since February and the latest version (preview 6) made available last week is in pretty good shape.

With that background, I thought it would be useful to state now how these changes are affecting InScribeX Web.

InScribe Web Preview 2
I made this version available in July last year to run on Silverlight 2 not long before Silverlight 3 appeared. This version is still available and runs with Moonlight 2 on Linux as well as Silverlight 2, 3 or 4. I expect this version to remain live, unchanged, until a few weeks after Moonlight 3 release. At that point I expect to retire this version as there will be no need to continue Silverlight 2 compatibility.
 
InScribe Web Preview 3
This version is written for Silverlight 3 and tested to work with Moonlight 3 previews and Silverlight 4 release. I've held back on making this available until Silverlight 4 was released and out in the field for a couple of weeks so probably an early May release date. As it stands this version is not greatly enhanced over preview 2 although I've changed the interface to make more effective use of screen space and added a bunch of behind the scenes changes.  This redesign especially benefits netbooks and other low resolution devices. I'll probably migrate some features of Preview 4 back into Preview 3 for the sake of Linux users once Moonlight 3 is available and before the Moonlight 4 release. In particular some UMdC support. Once Moonlight 4 is available (Winter?) this version can be retired and Preview 4 used cross platform.
 
InScribe Web Preview 4
Preview 4 requires Silverlight 4 or later and makes use of some of the new functionality, notably to enable rich text editing and printing. Probably late May/early June for the first cut then some incremental changes to follow during the rest of the year. Preview 4 introduces and supports a new file format for texts incorporating Ancient Egyptian, namely UMdC (Unicode Manuel de Codage).
 
About UMdC
The question of file formats for hieroglyphs and Ancient Egyptian has been a thorn in my side for some time. The problem is not how to devise ways of representing Egyptian in interesting and more powerful representations but rather how to evolve current ways of working with hieroglyphs without adding unnecessary complications in forseeable future directions. I've finally settled on this UMdC approach as the simplest solution to remove this blockage.  A topic I hope to cover in more depth tomorrow.

Novell releases Moonlight 2. InScribeX Web 2 now available on Linux.

Novell has today released  Moonlight 2, their open source Linux implementation of Silverlight 2.

After trying the first Moonlight 2 preview back in May and testing out several preview versions and nine ‘beta’ versions, needless to say the first thing I checked was the current (July) release of  InScribeX Web to see if it is working at last. Sigh of relief!

InScribeX Web is software for working with Ancient Egyptian, including the Basic Egyptian Hieroglyphs added recently to Unicode (5.2). InScribeX has therefore now hit an early goal of running cross-platform on Windows, Mac and Linux.

The Novell press release (www.novell.com/nl-nl/news/press/new-release-of-moonlight-now-available/) also announced an update to their agreement with Microsoft to include Microsoft support for development/testing of Moonlight versions 3 and 4. Novell is working towards a Q1 2010 preview of Moonlight 3 for release in Q3 with Moonlight 4 to follow ‘shortly thereafter’. Miguel de Icaza describes some technical features, including parts of Moonlight 3 functionality already present in 2 at his blog, tirania.org/blog/archive/2009/Dec-17.html.

As noted here last week, my InScribeX Web development is now targetting Silverlight 4 as 'InScribeX Web 4' for the spring 2010 timeframe. Reasons include better desktop deployment, printing, rich text support and improved InScribe 2004SE interoperability. Whether some IW4 features might find their way into a Moonlight/Silverlight 2 or 3 compatible version for Linux is an open question. As always, time is the enemy.

Caveats. Some devices such as the Amazon Kindle use Linux but are not user configurable. Hand held devices in general would not be ideal for InScribeX Web because of input and/or small screen size, even if Silverlight or Moonlight were available. Likewise games consoles where I'd need to add controller support and a redesigned interface for widespread accessability. All the same, apparently Silverlight or Moonlight implementations for Windows Mobile, XBox 360, PlayStation 3 and Wii are in various stages of development so it will be interesting to see what possibilities arise during 2010.

Designing InScribeX Web version 4: Introduction

During the next few months I’m hoping to find enough time to complete the next version of InScribeX Web (see http://www.inscribex.com/ for the current technical preview). The idea of InScribeX Web is to provide some useful tools for working with Ancient Egyptian in Unicode without the need to buy or install specialist software.

For technical reasons, the next preview of InScribeX Web is unlikely to be online before March/April 2010 so I’ve decided that the best way forward is to blog on the subject so interested parties can follow the development work as it happens. There is no substitute for using software, rather than reading about it, but at least this way gives some opportunity for feedback.

Incidentally I’ve only just discovered my email spam filter had grown too aggressive (it’s a balancing act when one has a public email address) so please try again if you have attempted but failed to contact me in recent weeks.

In parallel with this development I’m continuing to work on a new version of InScribe 2004, namely InScribe 2004SE (Second Edition), which despite the 2004 handle is in fact a major functional upgrade which enables use of Unicode and refreshes the software to take advantage of new features in Windows Vista and 7 while retaining the mode of use and features of the original edition. This is relevant to InScribeX Web as the two are being designed to complement each other when the commercial InScribe 2004SE software is installed.

InScribeX Web uses the Microsoft Silverlight plugin for Web Browsers. The main reason for this choice is simple, I needed the most cost effective way of creating advanced internet software: the project is unfunded so there was no scope for the luxury of developing under more time consuming alternatives such as Adobe AIR or Google Gears (fortunately as Gears is no longer being developed in favour of Google changing tack to an as yet to be clarified HTML 5 approach in ChromeOS etc.). Practicalities aside, Silverlight also allows for fun graphics and other effects and must admit I rather enjoy having these facilities to hand as a refreshing change to the more formal approach necessary in the InScribe 2004SE development.

The choice of Silverlight is not without controversy, nor without complication from a developer perspective. The current InScribeX Web preview was written for Silverlight 2. Silverlight 3 was released in July adding new features and Silverlight 4 announced in November for release in the spring. If that is not enough, the Linux equivalent (Moonlight, developed as an open source project by Novell) is running some distance behind Silverlight itself with Moonlight 2 not expected to be released until early next year (when I built the InScribe Web technical preview, the Moonlight release was expected late Summer).

To sidestep the version complications, InScribeX Web development is now targeting Silverlight 4 (expected in March/April 2010, I am currently using the developer-only Beta preview) and for those interested in such matters I‘m using Visual Studio 2010 Beta 2 (with some Expression Blend) as the development environment. There are some major benefits using 4 which I’ll run over another day. It’s a pure guess but I’m half expecting version 4 to be the point at which Silverlight hits prime time; we shall see.

Unfortunately, this is not good news for Linux users! My thinking at the moment is to wait until Moonlight 2 is released and the current technical preview working and then make a call on what to do. I’m actually very keen on making InScribeX available on Linux (the X means cross-platform) but it would be perverse to penalize the 95% (or whatever it is) of the internet population who can use Silverlight.

Egyptian Hieroglyphs in Unicode 5.2

Having long resisted the temptation to blog, Egyptian Hieroglyphs pushed me over the edge and the topic makes a fitting start to this journal.

Unicode 5.2 (http://www.unicode.org/versions/Unicode5.2.0/) was released on October 1st, 2009. This iteration of the Unicode Standard is the first to include the Egyptian Hieroglyphic script, one of the earliest forms of writing and rather aesthetically pleasing notably in the colourful style encountered in monumental inscriptions.

The 1071 hieroglyphs specified in Unicode 5.2 are termed Basic Egyptian Hieroglyphs. This set is based on the work of Alan Gardiner, the majority being described in his book Egyptian Grammar (Third Edition, 1957). The list (in PDF format) can be found at http://www.unicode.org/charts/PDF/Unicode-5.2/U52-13000.pdf (this document is compiled using a version of my InScribe hieroglyphic font, itself inspired by the Gardiner font).

Inclusion in the Unicode Standard is only a starting point for a script to gain adequate support in digital applications and it is likely to be several years before software and web services catch up and provide adequate support for hieroglyphs. All the same it is fun to think that within the next decade people will be texting hieroglyphs and finding new uses for an ancient script beyond the academic.

Michael Everson and myself began work on defining this initial basic repertoire in late 2005 and the final list of 1071 took shape in Autumn 2006 following discussions at the biennial Informatique et Egyptologie meeting in Oxford that Summer. Defining a basic list was not without controversy. There are thousands more graphically distinct hieroglyphs known from ancient texts. The only way to achieve consensus on the basic set was to stick very closely to Gardiner even though this principle meant we are currently lacking some important signs known, for instance, from the Pyramids texts.

I hope work will begin in 2010 to standardize additional hieroglyphs to fill some of the most obvious gaps in a future version of Unicode. Nevertheless what we have now is adequate for many purposes.