The SINUHE the Hierotyper project is about keyboard input and display/edit of Unicode hieroglyphic inside 'Office' and web applications. SINUHE combines an ingenious adaptation of Japanese input methods for typing hieroglyphic by So Miyagawa with a font implementing a version of Simplified Egyptian by Marwan Kilani.
The project website is here and project sources with some documentation on GitHub at https://github.com/somiyagawa/SINUHE-the-Hierotyper. It is well worth taking a look at their videos on YouTube such as such as SINUHE the Hierotyper: demo 1. SINUHE is an ongoing work in progress and you need to feel comfortable with downloading the files and getting elements to work if you want to try it yourself. If you have a medium-large amount of hieroglyphic to type, SINUHE is faster than traditional use of codes and sign palettes so worth considering.
Longer term it is likely that standard Egyptian Hieroglyphic input methods will become available in their own right so this Japanese scenario for direct typing into standard word processing documents and the like will no longer be necessary. However, I can't see this happening earlier than a couple of years from now after Unicode 11 is released.
Meanwhile, SINUHE gives a preview of the kind of thing to expect for input as we move beyond the first generation of digital hieroglyphic and the typical input methods and workflow of traditional MdC applications. Of course you will be able to continue using hieroglyphic editors including traditional MdC-based systems to transcribe hieroglyphic then convert to and from Unicode if you prefer.
The notion of Simplified Egyptian Hieroglyphic fonts has been around for quite some time but as far as I know this is the first system using the technique to be made generally available on the web. The neat part about Simplified Hieroglyphic is it can be used in much modern software. However a major problem with this approach to fonts is one font may render the quadrat structure of hieroglyphic text differently to another font unless there is an agreed standard to which fonts conform to. I therefore recommend that anyone thinking of making simplified fonts should work alongside the SINUHE project to maintain a common approach to hieroglyph sequence mapping.
I'm planning to support SINUHE text format conversion to and from the control character approach of the Unicode Standard for Hieroglyphic used in the Hieroglyphs Everywhere Project (HEP). The great thing about open standards is all software writers have the information to enable them to do the same thing if they wish.
Thanks So and Marwen for interesting discussions and your demos of the system in action.
Bob Richmond
Tuesday 20 December 2016
Friday 16 December 2016
Web browser test for hieroglyphic (December 2016)
I've released a Hieroglyphs Everywhere Project (HEP) web browser test page for Unicode hieroglyphic to provide a simple test you can use to check at a glance the status of the web browser(s) you are using on PCs or other devices.
HEP uses web fonts so there's no need to install a hieroglyphic font on a PC or other device. HEP resources work within the scope of Unicode (2009) hieroglyphic to preview features relating to the new hieroglyphic writing system (currently expected in Unicode 11, 2018).
I'm making the test page available ahead of time so we can become aware of any unexpected issues.
Up to date versions of Google Chrome, Microsoft Edge/Internet Explorer, and Mozilla Firefox work well as a general rule. Keeping your web browser up to date is highly recommended, irrespective of hieroglyphic, for security and performance reasons.
I've found Firefox works consistently over a wide range of devices (including Android, Linux, macOS and Windows systems) aside from some minor visual variations.
Chrome varies from system to system: for instance polychromatic is missing from Windows 7 and (surprisingly) Android at this time. On Windows 10 a Chrome bug displays bold polychromatic text in black and white.
Safari still renders polychromatic text as monochrome on macOS and iOS. Presumably this will be fixed sometime in 2017. Meanwhile Firefox is available to Mac users for greater web standards compliance including polychromatic text.
Internet Explorer, like Chrome, is limited in capabilities by its host system for example IE on Windows 7 lacks modern font technology. If you are forced to use a legacy Windows 7 system I'd recommend you switch web browser from IE if you haven't already. I have a HEP work-around for some IE/Windows 7 issues but would rather spend the time needed on something useful unless this turn out to be a major problem.
During 2017, I expect to update and extend the test page from time to time. Several reasons for this can be anticipated.
HEP uses web fonts so there's no need to install a hieroglyphic font on a PC or other device. HEP resources work within the scope of Unicode (2009) hieroglyphic to preview features relating to the new hieroglyphic writing system (currently expected in Unicode 11, 2018).
I'm making the test page available ahead of time so we can become aware of any unexpected issues.
Up to date versions of Google Chrome, Microsoft Edge/Internet Explorer, and Mozilla Firefox work well as a general rule. Keeping your web browser up to date is highly recommended, irrespective of hieroglyphic, for security and performance reasons.
I've found Firefox works consistently over a wide range of devices (including Android, Linux, macOS and Windows systems) aside from some minor visual variations.
Chrome varies from system to system: for instance polychromatic is missing from Windows 7 and (surprisingly) Android at this time. On Windows 10 a Chrome bug displays bold polychromatic text in black and white.
Safari still renders polychromatic text as monochrome on macOS and iOS. Presumably this will be fixed sometime in 2017. Meanwhile Firefox is available to Mac users for greater web standards compliance including polychromatic text.
Internet Explorer, like Chrome, is limited in capabilities by its host system for example IE on Windows 7 lacks modern font technology. If you are forced to use a legacy Windows 7 system I'd recommend you switch web browser from IE if you haven't already. I have a HEP work-around for some IE/Windows 7 issues but would rather spend the time needed on something useful unless this turn out to be a major problem.
During 2017, I expect to update and extend the test page from time to time. Several reasons for this can be anticipated.
- Progress with the Unicode Standard for the Egyptian Hieroglyphic writing system and repertoire extensions.
- Identification of browser bugs, e.g. in OpenType font rendering.
- Additional browser features or browser bug avoidance techniques used by the Hieroglyphs Everywhere Project.
Bob Richmond
Wednesday 14 December 2016
Several Observations concerning Polychromatic Egyptian Hieroglyphic fonts
The Egyptian Hieroglyphic writing system is inherently polychromatic. The colour or colours used for individual hieroglyphs involve naturalistic, symbolic and conventional characteristics adapted to the materials or pigments available to the artist/scribe. For the most part, hieroglyphs were coloured consistently in a single painting or inscription. Conventions were used, for instance green is associated with growing plants and life, blue the sky and primeval flood. These characteristics of hieroglyphic makes it possible to envisage coherent polychromatic fonts with useful applications.
Symbol & Magic in Egyptian Art (R. H. Wilkinson, 1994), Chapter 5, provides a good introduction to Egyptian use of colour.
Hieroglyphic will be the first intrinsically chromatic Unicode writing system. It is important, however, to be clear that Unicode itself and its hieroglyphic content do not define chromatic features. This is done by systems built on Unicode such as CSS/HTML web standards, typically using the OpenType font standard for text rendering. Modern versions of web browsers such as Google Chrome, Microsoft Edge/Internet Explorer, and Mozilla Firefox already implement font technology to work with basic polychromatic, mainly thanks to the popularity of colour emoji.
Once hieroglyphic writing system additions are available in the Unicode standard there can be little doubt that polychromatic will dominate casual use of hieroglyphic. Hundreds of millions of children around the world encounter Egyptian each year as part of their education and colour makes hieroglyphic more comprehensible and interesting. This situation will benefit Egyptology since it will encourage digital industries to support Unicode hieroglyphic in their products. There are questions such as how far to scope casual hieroglyphic but the earliest this widespread deployment could begin is Summer 2018 so there is ample time to experiment with options and discuss details before a universal font rollout.
The situation with polychromatic for scholarly applications is different. Monochrome hieroglyphic has 150 years of publications to inform on strengths and weaknesses of transcriptions but there is no tradition of polychromatic typefaces at all. There are obvious benefits of colour such as hieroglyphs which look similar in monochrome yet have distinctive colour in paintings. Birds G001 ꜣ 𓄿 and G004 tyw 𓅂 are good examples. Nevertheless in the short term I expect most Egyptological work to continue to focus on monochrome. This principle also applies to implementation of Unicode hieroglyphic fonts and the methods, resources and tools for working with the next generation of hieroglyphic technology where there's a lot still to do. Incidentally, hieratic transcriptions that follow traditional use of red and black ink in hieratic do not need polychromatic fonts. Nevertheless if you are producing a book, thesis, museum website or the like aimed at the 2018/19 time-frame it is not too early to consider whether or how polychromatic hieroglyphic might be used to advantage.
My own work on polychromatic began with the simple question: is it technically feasible at the current state of technology? For a long time the answer has been no. As recently as January, when the Unicode hieroglyphic writing system was expected in 2017, polychromatic seemed best left to the second stage of development when technology was slightly further ahead. However, one positive result of the delay to 2018 is it now proves possible to bring polychromatic forward by a year for use by specialists (as noted above widespread deployment should wait on the standards process).
Hieroglyphic fonts are fairly complex to develop. Polychromatic adds more technical complexity. To simplify the first font I decided to focus on two aspects. 1. Use in a dictionary application and 2. software user interface (UI). This reduces quadrat layout and chromatic complexity, for instance I could ignore vertical writing and the tall or complex quadrats needed in some transcription scenarios. This is still a work in progress but I hope write more on the topic during 2017.
Bob Richmond
Symbol & Magic in Egyptian Art (R. H. Wilkinson, 1994), Chapter 5, provides a good introduction to Egyptian use of colour.
Hieroglyphic will be the first intrinsically chromatic Unicode writing system. It is important, however, to be clear that Unicode itself and its hieroglyphic content do not define chromatic features. This is done by systems built on Unicode such as CSS/HTML web standards, typically using the OpenType font standard for text rendering. Modern versions of web browsers such as Google Chrome, Microsoft Edge/Internet Explorer, and Mozilla Firefox already implement font technology to work with basic polychromatic, mainly thanks to the popularity of colour emoji.
Once hieroglyphic writing system additions are available in the Unicode standard there can be little doubt that polychromatic will dominate casual use of hieroglyphic. Hundreds of millions of children around the world encounter Egyptian each year as part of their education and colour makes hieroglyphic more comprehensible and interesting. This situation will benefit Egyptology since it will encourage digital industries to support Unicode hieroglyphic in their products. There are questions such as how far to scope casual hieroglyphic but the earliest this widespread deployment could begin is Summer 2018 so there is ample time to experiment with options and discuss details before a universal font rollout.
The situation with polychromatic for scholarly applications is different. Monochrome hieroglyphic has 150 years of publications to inform on strengths and weaknesses of transcriptions but there is no tradition of polychromatic typefaces at all. There are obvious benefits of colour such as hieroglyphs which look similar in monochrome yet have distinctive colour in paintings. Birds G001 ꜣ 𓄿 and G004 tyw 𓅂 are good examples. Nevertheless in the short term I expect most Egyptological work to continue to focus on monochrome. This principle also applies to implementation of Unicode hieroglyphic fonts and the methods, resources and tools for working with the next generation of hieroglyphic technology where there's a lot still to do. Incidentally, hieratic transcriptions that follow traditional use of red and black ink in hieratic do not need polychromatic fonts. Nevertheless if you are producing a book, thesis, museum website or the like aimed at the 2018/19 time-frame it is not too early to consider whether or how polychromatic hieroglyphic might be used to advantage.
My own work on polychromatic began with the simple question: is it technically feasible at the current state of technology? For a long time the answer has been no. As recently as January, when the Unicode hieroglyphic writing system was expected in 2017, polychromatic seemed best left to the second stage of development when technology was slightly further ahead. However, one positive result of the delay to 2018 is it now proves possible to bring polychromatic forward by a year for use by specialists (as noted above widespread deployment should wait on the standards process).
Hieroglyphic fonts are fairly complex to develop. Polychromatic adds more technical complexity. To simplify the first font I decided to focus on two aspects. 1. Use in a dictionary application and 2. software user interface (UI). This reduces quadrat layout and chromatic complexity, for instance I could ignore vertical writing and the tall or complex quadrats needed in some transcription scenarios. This is still a work in progress but I hope write more on the topic during 2017.
Bob Richmond
Thursday 1 December 2016
Egyptian numbers and MdC transcription of Hieroglyphic
A useful feature of most implementations of Manual de Codage (MdC) notation is distinct codes for numbers. There are five codes named 1, 2, 3, 4 and 5 used in the same way as hieroglyph alphanumeric codes or mnemonics as quadrat building blocks. This is especially useful when dealing with units 1 to 9 where it is often useful to distinguish between the concept of unity (Z1) and the number 1, duality (Z4/Z4A) and the number 2, plurality (Z2) and the number 3.
The situation with numbers, plurality and so forth is more nuanced than this summary suggests. Ancient scribes did not think in these terms. Conventions changed over time. Hieratic featured ligated forms. Specialist representations of numbers were used for fractions and other applications. My point here is about basic practical use of MdC not this wider picture.
There are two important reasons to make the numeric distinction.
1. Fonts. Most fonts used for MdC implementations to date do not display '1' differently to Z1. This will change with a new generation of improved fonts. See Egyptian Grammar (Gardiner, 1957) p191-p206 for examples showing how the original Gardiner font makes a distinction between Z1 and some numeric forms.
2. Search and analysis. Such applications using MdC are rare so far but the next generation of software will add these features. For instance searching transcriptions for dates is very useful and it is likely such software will be strict about use of number forms to avoid confusion.
Many examples of the practice of treating Z1 and numbers as if they are the same cropped up in the analysis referenced in my earlier post Analysis of Unicode Egyptian hieroglyphs in a collection of MdC-coded transcriptions. Part of the explanation of this is the fact that some of the transcriptions originated with early MdC editing software that did not support the numeric feature.
Examples of number codes used incorrectly are A1*B1:Z2 (people, plurality) incorrectly transcribed as A1*B1:3; G1&Z1 (ideogram) incorrectly transcribed as G1&1; Z1*Z1*Z1:Z1*Z1 (3:2) incorrectly transcribed as Z1*Z1*1:Z1*Z1.
It is not an MdC error to use the Z1 form. The verbose Z1*Z1*Z1:Z1*Z1 transcription, for instance, is a legitimate alternative to 3:2 in most current MdC implementations although it may render differently and in a less satisfactory way in some of these MdC implementations. Sometimes verbose is unavoidable such as using the current release of WikiHiero that does not recognise numeric codes. However it can be expected that future releases of MdC software may give a warning when verbose sequences are encountered. I'm taking this approach with data and software in the Hieroglyphs Everywhere Project (HEP) to avoid confusion when linking traditional MdC with Unicode-based solutions. In short, as a general rule use numeric representations for units in MdC where feasible.
MdC provides other numeric codes 10, 20, 30, 40, 50 and 100, 200, 300, 400, 500 used in a similar way to the units. I would like to recommend these but there is a bug in JSesh 5.5 that results in less satisfactory rendering of quadrats using these numeric forms. -20:10- is a less satisfactory rendering compared with -V20*V20:V20-. Fortunately, unlike the ambiguous situation with strokes, the linkage with Unicode is less problematic so for the time being its mostly harmless to use verbose notation.
The narrow Z2 issue
One problem encountered with MdC transcriptions is the fact that Hieroglyphica (1993 and 2000 versions) omitted defining a code for the narrow variant of Z2. The narrow variant is a feature of the Gardiner font and commonplace in Egyptian Grammar but not explicitly given a code in the sign list. This narrow variant is known as Z002A in Unicode and Z2D in Hieroglyphica extensions such as the Aegyptus font. Z2D was used in InScribe (2004) and documented in EGPZ version 1 (2006).
Unfortunately, the Z2D omission from Hieroglyphica means transcriptions that need the narrow variant often resort to using the number 3 as a substitute when using editing software such as JSesh 5.5. This unsatisfactory situation needs to be resolved.
Personally, when working with JSesh material I write 3\NaN (meaning not a number) - a legitimate JSesh construction. So rather than write -D21:X1*3- (as in Egyptian Grammar Exercise XVIII) I use -D21:X1*3\NaN-.
I'm not especially advocating my approach at present just drawing attention to the problem as something you will need to fix in your transcriptions in the future.
If you are developing MdC-related software such as WikiHiero it is safe and easy to add Z2D support.
Conclusions
In principle MdC support for numbers is fairly effective but has problems in some implementations. To understand this fully needs a more detailed analysis than can be adequately treated in a blog post.
I hope that by raising these points MdC users will give more thought to representation of numbers when transcribing new material or updating existing transcriptions.
To end on a positive note, the situation with Unicode-based solutions is better defined and potentially easier to use.
Bob Richmond
There are two important reasons to make the numeric distinction.
1. Fonts. Most fonts used for MdC implementations to date do not display '1' differently to Z1. This will change with a new generation of improved fonts. See Egyptian Grammar (Gardiner, 1957) p191-p206 for examples showing how the original Gardiner font makes a distinction between Z1 and some numeric forms.
2. Search and analysis. Such applications using MdC are rare so far but the next generation of software will add these features. For instance searching transcriptions for dates is very useful and it is likely such software will be strict about use of number forms to avoid confusion.
Many examples of the practice of treating Z1 and numbers as if they are the same cropped up in the analysis referenced in my earlier post Analysis of Unicode Egyptian hieroglyphs in a collection of MdC-coded transcriptions. Part of the explanation of this is the fact that some of the transcriptions originated with early MdC editing software that did not support the numeric feature.
Examples of number codes used incorrectly are A1*B1:Z2 (people, plurality) incorrectly transcribed as A1*B1:3; G1&Z1 (ideogram) incorrectly transcribed as G1&1; Z1*Z1*Z1:Z1*Z1 (3:2) incorrectly transcribed as Z1*Z1*1:Z1*Z1.
It is not an MdC error to use the Z1 form. The verbose Z1*Z1*Z1:Z1*Z1 transcription, for instance, is a legitimate alternative to 3:2 in most current MdC implementations although it may render differently and in a less satisfactory way in some of these MdC implementations. Sometimes verbose is unavoidable such as using the current release of WikiHiero that does not recognise numeric codes. However it can be expected that future releases of MdC software may give a warning when verbose sequences are encountered. I'm taking this approach with data and software in the Hieroglyphs Everywhere Project (HEP) to avoid confusion when linking traditional MdC with Unicode-based solutions. In short, as a general rule use numeric representations for units in MdC where feasible.
MdC provides other numeric codes 10, 20, 30, 40, 50 and 100, 200, 300, 400, 500 used in a similar way to the units. I would like to recommend these but there is a bug in JSesh 5.5 that results in less satisfactory rendering of quadrats using these numeric forms. -20:10- is a less satisfactory rendering compared with -V20*V20:V20-. Fortunately, unlike the ambiguous situation with strokes, the linkage with Unicode is less problematic so for the time being its mostly harmless to use verbose notation.
The narrow Z2 issue
One problem encountered with MdC transcriptions is the fact that Hieroglyphica (1993 and 2000 versions) omitted defining a code for the narrow variant of Z2. The narrow variant is a feature of the Gardiner font and commonplace in Egyptian Grammar but not explicitly given a code in the sign list. This narrow variant is known as Z002A in Unicode and Z2D in Hieroglyphica extensions such as the Aegyptus font. Z2D was used in InScribe (2004) and documented in EGPZ version 1 (2006).
Unfortunately, the Z2D omission from Hieroglyphica means transcriptions that need the narrow variant often resort to using the number 3 as a substitute when using editing software such as JSesh 5.5. This unsatisfactory situation needs to be resolved.
Personally, when working with JSesh material I write 3\NaN (meaning not a number) - a legitimate JSesh construction. So rather than write -D21:X1*3- (as in Egyptian Grammar Exercise XVIII) I use -D21:X1*3\NaN-.
I'm not especially advocating my approach at present just drawing attention to the problem as something you will need to fix in your transcriptions in the future.
If you are developing MdC-related software such as WikiHiero it is safe and easy to add Z2D support.
Conclusions
In principle MdC support for numbers is fairly effective but has problems in some implementations. To understand this fully needs a more detailed analysis than can be adequately treated in a blog post.
I hope that by raising these points MdC users will give more thought to representation of numbers when transcribing new material or updating existing transcriptions.
To end on a positive note, the situation with Unicode-based solutions is better defined and potentially easier to use.
Bob Richmond
Subscribe to:
Posts (Atom)