Tommy and I are working on a new feature that’s based Tommy’s earlier work while in Mérida. It will allow users to type in a word and convert it to a glyph block. For example, the user might enter “otoot” which is the ancient Mayan word for home. The app would then try to convert this to an image of a glyph block that contains only syllabic/phonetic glyphs. For “otoot”, in an ideal world the app would display:
This ideal image is from page 3 of Tokovinine’s catalog. In this post I want to set some expectations and try to be clear on what the app will and won’t do. Keep reading to see an image of our current rendering.
Converting the input characters to a glyph block is a multi-step process. First, the input characters must be divided into a list of syllables. Depending one what the user enters this may not be possible. For example, an input of “strength” will not generate a glyph block.
Next, for each syllable the app will internally generate a list of matching glyphs. But for some syllables/sounds there is no matching glyph and so converting the syllables to a glyph block is not possible.
What if there is not a single main glyph in the list of all the matching glyphs? If each syllable can only be written by affix glyphs we can’t form a reasonable glyph block. One can’t simply stitch a bunch of affix glyphs together and call it a glyph block.
Next, the app must determine what kind of glyph block to create. While there are many kinds of ways to arrange the glyphs, initially the app will only be able to create a few different kinds of glyph blocks. For one syllable words, there is only one kind of glyph block; an unadorned main glyph. For two syllable words the app a main glyph and one affix glyph. The affix will be in the correct location so reading in standard order preserves the syllable order of the user’s input. Three syllable words a main glyph and two affix glyphs, again preserving syllable order.
The app will only create one glyph block at a time. It will not support merging individual glyphs or infixing one glyph inside another. It will not support semantic determinatives. It will not use any logographic glyphs. It will only create an image of a glyph block. It will not support editing the glyph block. There is no underlying Unicode information for any glyph or glyph blocks. Each glyph block image image will be created by arranging, scaling and rotating the glyphs from Professor Tokovinine that are already in the app.
Here is a screenshot of our current attempt to render the glyph block for otoot using the same glyphs in the above image from Tokovinine’s catalog and using Unicode quadrat 3.02 definition:
Notice that there is extra whitespace around all the glyphs. We can eventually remove some of it, maybe most of it.
After this feature has been released we will investigate sending this glyph block image as a text message to another phone. Sending must go through the default messages app on the sender’s phone. We can’t build texting into the Ancient Maya App, that is not allowed. Instead, we can create the image to send and ask who to send it to. Then this info is handed off the default texting app where the user confirms they want to send it.
There are many different ways to layout glyphs in a glyph block. This preliminary Unicode proposal lays out 168 different ways starting on page 19. Initially we hope to support 1.01, 2.01, 2.02, 3.01, 3.02 3.07 and 3.09.
Although the app will initially be limited I think we’ll learn how to bring ancient Mayan writing to smartphones. We’ll see what works, what doesn’t work, what is missing and start to understand what users need. From this foundation we can look at how writing systems for Korean and Cherokee are deeply integrated into the smartphones.