[Egyptian] Some general considerations

Sat Jul 23 13:51:53 BST 2016

Hi Marwan

Thank you for sharing your thoughts. I’m sympathetic to much of what you have written. Lots of good points.

When I kicked the ball rolling on the topic 18 months ago I submitted a rough background note to UTC L2/15-069 <http://www.unicode.org/L2/L2015/15069-egyptian-plain.pdf> . I gave two general approaches. 

1.       An implied clustering scheme (similar to what you are suggesting in your note). I first raised this “Simplified Egyptian” notion at I&E 2006 when we were discussing the initial repertoire.

2.       An example of an explicit approach (much like what we have now as the UTC recommendation).

Like you I like the Simplified approach and it would work well for much casual use. One reason the explicit approach was actually chosen is it enables the author of a transcription to be clear about intended layout. If the look of a text were reliant on a particular fonts clustering model there are opportunities for confusion long term. Some explicit structure seemed essential. The need to input joiner characters was a tradeoff – however specialist software for Egyptologists will be able to use specialist input methods for fast input of text. And remember the most popular input method is copy and paste!

The simplicity of a single LIGATURE was proposed with consideration about input methods and the practicality/usability of editing in general purpose software. I’ve not had time yet to analyse the Ramses data fully and have not yet received corresponding TLA data but on evidence so far the 4 corner method is only possibly needed for at most something like 1 in 5,000 clusters so this low frequency should be taken into account when we decide what to do.

On vertical and horizontal have you looked at the 3 controls + 2 group controls (as per note yesterday). Have you tried experimenting with font I sent out in the week (this has a couple of vertical/tall group examples in the doc about the font?

Regards,

Bob

From: Egyptian [mailto:egyptian-bounces at evertype.com] On Behalf Of Marwan Kilani
Sent: 23 July 2016 10:46
To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>
Subject: [Egyptian] Some general considerations

Hello Everyone

First of all: I am attaching a pdf version of this email because I am using a few images, and I am not sure they will displayed in the right places in the email. If you don’t see any image in the text below or something does not make sense, please refer to the pdf.

-------

I dare to write here an email pointing out a few general and specific observations on both what has been said in Cambridge, and what has been discussed in these emails in the past few days.

I have the feeling that many of you will not like what I am going to write, but well..

First of all, as you know I didn’t know any of you before Cambridge, so I had the feeling to be a bit an “external observer”. Which, in turn, led me to a few observations.

First:

Do you know the Indian story of the three (or more) blind men who are put in front of an elephant and are asked to find out what hey have in front of them ( https://en.wikipedia.org/wiki/Blind_men_and_an_elephant )? One in front of the trump, one next to the ear and one near the tail. The three blind men start touching the elephant and start to try to describe it and to try to figure out what kind of animal is, but they end up fighting because they can only touch a small part of the animal but missed the general picture.

Besides the “entrenched positions” mentioned by Nigel, I had the feeling that some of the participants in Cambridge were a bit like the blind men, knowing very well their specific fields, but missing a bit the general picture, thus ending up misunderstanding the others.

Now, I don’t want to sound arrogant. I don’t think I have a vision of the whole picture and I don’t think to be more knowledgeable than any of you. I put myself as well among those blind men.

But considering that, correct me if I am wrong, So and I (note that I am talking only in my name, not in So's name) are the only person at that workshop who:

a) are Egyptologists and therefore know both how Egyptian hieroglyphs works and what Egyptologists need (or at least what we need as egyptlogists)

b) have been playing since a while with Unicode characters, fonts, input methods etc and therefore have a certain understanding of how these technical tools work

c) have a good practical understanding of how non-Latin complex horizontal/vertical scripts work. In particular So is familiar with Japanese, Chinese and Korean, I think? While I know pretty well Arabic-based scripts, Indian ones (I lived in Nepal and when I was there I ended up teaching Nepali to Nepali children in a Nepali school) and I have played a lot with Chinese and Japanese scripts.

Then, perhaps, our small little contribution should also be considered to make sense of the whole big elephant.

This even more considering that in spite of having never met before, both So and I ended up developing very similar solutions to some of the problems you are discussing, solutions that, by the way, seem to me very similar to what Ishida was suggesting in some of his emails.

Solutions that, in fact, are already implemented by various scripts around the world.

Second:

Many of the problems you are discussing don’t have a single “right” solution, because in fact many of those problems depends on how you interpret the data (i.e. the ancient hieroglyphs). Therefore, the aim should not be to find the “right” solution, but rather to find the easiest *interpretation* that could led to the easiest implementation in Unicode. 
We are not ancient Egyptians, we don’t know how ancient Egyptian scribes perceived their writing system. We can just observe it from the outside and suggest interpretations. Which are not “right” or “wrong”, but rather “more efficient” or “less efficient” in respect to the problems we want to solve through these interpretations. This is something that, I think, should be kept in mind.

Third

As said during the meeting in Cambridge, I am not against the introduction and use of some control characters per se.
Still, honestly, more I read about your proposals and about your control characters, and more I am convinced that using rendering algorithms at the font level and general or contextual ligatures embedded within the fonts as a main way to combine and display groups would be much easier and much more efficient than using control characters.

This said, allow me to call your attention to a few more specific points.

1) JSesh approach

I had the feeling during the meeting and reading your emails that many of you think in a very JSesh-based mentality. Like I had the feeling that at least some of the participants’ goal is to imitate JSesh in Unicode.

But Unicode *is* *not* JSesh, or at least should not be JSesh.
Using control functions, parentheses etc can be an efficient way in JSesh, but I doubt that a system requiring to input 10 (sic!) control characters to display 3 (sic!) hieroglyphs in a pretty common group (the Htp example in Mark-Jan’s last proposal) makes much sense in a unicode perspective. Especially considering that you can obtain exactly the same result without control character and just with 1 (sic!) general ligature within the font that will be automatically rendered by usual standard already available rendering algorithms.

In other words, what can be an efficient solution to a problem in JSesh, is not necessarily a good solution in Unicode. And Unicode is not even a stand-alone thing: Unicode can work in combination with rendering algorithm (i.e. ligatures embedded in fonts), with layouts at the editor level etc. that can help solving the problems on different level than just on the Unicode encoding level.

2) Groups in fonts

Someone in the list was saying that the groups need to be listed, but that not all of them necessarily need to be built in the font (or something like that).

This is not true: compound characters and groups will not automatically build on their own, and if you envisaged the possibility to build a group that you *do* need to have in the font, otherwise it wont display correctly and you will have random broken control-characters popping out here and there in your hieroglyph text. This perhaps will not bother you in your database etc, but it will be just unacceptable for common users (and, for instance, for editors).

If you are accepting that a group can be built, then you need a way to display that group, i.e. you must have that group saved somewhere in your font.

Whether you will build those characters through control characters or with rendering and ligature algorithms embedded in the fonts.

3) the 4 “small sign in the corner of big sign” control characters.

If you really want to have control characters to combine small signs in the corner of bigger signs, you can do that with just 2 control characters, you don’t need 4 of them. These because the distinction you are making between “big” and “small” signs is superfluous.

It is enough to have 2 transversal control characters, that we can represent as “A\B” and “A/B”. They will join the main signs by virtually/ideally putting them at two opposite corners of the square, on the base of their relative order.

So for instance, if you want to render the group  tw, you will just type in  t + “A\B-control-character” +   w.

If instead you want to code for  wt, then you will just need to type in  w + “A\B-control-character” +    t.

If you want to render  twt, then you just type in  t + “A\B-control-character” +   w + “A\B-control-character” +  t

In all these cases, you can simply use the same control character.

You don’t need two distinct control characters for that, because there is no need to specify which one is the “big” sign, and which one is the “small” one, because what really matters is not their size, but their relative position.

NOTE: if by any chance you are going to adopt this system of 2 control characters, then I’d like to be mentioned in the proposal. You know, it could be useful on the CV.

4) Vertical and horizontal script and control characters

You are talking about using control characters to render texts in horizontal and vertical texts. This, however, can generate some quite relevant problems.
In particular, you have to consider that it will be hardly possible to automatically convert a vertical text encoded with control characters into horizontal text. In other words, if you have a text written in vertical columns that used control characters, and for whatever reason (for instance for editorial reasons, you editor wants your text in horizontal lines and not in vertical lines, for instance if you are quoting a hieroglyphic passage within a English paragraph) you will need to turn it into horizontal text, you will hardly be able to do it automatically, and you will likely have to retype it entirely.

The problem is that the control characters that you will need and use in your vertical text will not be the same and will not be inputted in the same places as those that you will need in your horizontal rendition of the same text.

Let’s take, for instance, the following example.

If this text will be typed with a vertical font (as I would expect it to be), then to display it correctly you will have to type the following sequence of Unicode characters:

 + + “left/right-ctrl-character” (sic!) +  + “up/down-control-character” (sic!) +  +  + 

NOTE that you will probably (as far as I know, correct me if I am wrong) have to use the “left/right-ctrl-character” (not a up/down crtl-character) to combine the  and  and then the “up/down ctrl character (not a “left/right ctrl character) to combine them with the , because in vertical texts the baseline of reference is the left line of the column. Note that this will change the order the signs have to be inputted, which means it will interfere with the searchability of the text.

This however is a problem that should be possible to solved somehow. Perhaps, I am not sure. I am not expert of these details.

If however you will try to display this same text (i.e. this same sequence of Unicode characters) horizontally, it wont be enough to chance the direction of the text and to use a horizontal font, because what you would obtain would be something wrong like this:

 "broken-control-character”  "broken-control-character” 

In order to display horizontally the same text in a graphically acceptable way, in fact, you will have to type the following sequence of Unicode characters:

 +  +  + “up-down-control-character” +  +  + “up-down-control-character” + 

Which would be displayed as:

Essentially, you will have to type the text anew. Not very practical, in my opinion.

Using rendering algorithms, i.e. general or contextual ligatures embedded within the *font* at the font level (instead of control characters), would be a very easy way to solve the problem.

In fact it would be enough to have two fonts, one for vertical texts and one for horizontal texts (or one single font with the possibility to switch between the two layouts) with different sets of ligatures embedded in them.

In that way, you will just have to type the following plain sequence of Unicode characters (without any control character):

 +  +  +  +  + 

And the ligature algorithm in the vertical font will render the ligature .

Then, to turn this same vertical string of text into horizontal text you will just have to change the font, and the algorithm in the horizontal font will automatically display the correct  and  ligatures.

Without need to retype anything.

NOTE that the hieroglyphic text you see the examples here above have all been obtained in this way, namely without control characters and just with my font with embedded ligatures.

As Ishida suggested in one of his emails, this is essentially how Asian languages deal with this problems. It is very efficient, it works, it does not require any new special character and frankly I still don’t understand why Egyptian should be different.

5) special characters, vertical/horizontal texts and input methods

Note that because of the problem with control characters and horizontal/vertical texts highlighted above, you *wont be able* to use a same simple predictive input method to type vertical and horizontal texts, because the sequences of signs and control characters needed will be *totally* different, and will both need to be encoded independently within the input method itself.

In fact, you will probably have to explicitly list in advance within the input method every single possible combination of hieroglyphic signs + control characters, or you will have to just type you text sign by sign, control character by control character (even if you adopt shortcuts to input the control characters and the most common groups, the problem will still be there).

Again, with general or contextual ligatures embedded at the font level this problem would not exist, because the input method would just have to input the plain sequence of signs, and it will be the rendering algorithm within the fonts that will take care of displaying the signs in the correct spatial order.

6) Ramesside “groups” (or “tall groups”).

You all seem to assume that the clusters of signs we see in Ramesside texts are “groups” (or ligatures) analogous to the middle Egyptian square groups, and therefore have to be created, manipulated and displayed as graphical units.

For the non-Egyptologists among us, this is a Ramesside text

in red you have what is generally referred to as a “Ramesside group” (or “tall groups”).

Here, instead, you have an ordinary Egyptian text, 

and in red you have what are generally considered as ordinary “square groups”.

As you can see, the difference is that in ordinary Egyptian writing, sings are grouped into regular square spaces (or half-squares). In Ramesside writing, instead, signs tend to be combined into vertically elongated rectangles. These rectangles can contain multiple ordinary square groups.

For instance, the following Ramesside group from the text above:

could be split into two ordinary square groups,  and , in the ordinary square groups writing.

As said, people often assume that these clusters of signs in Ramesside texts have to be understood as “groups” analogous to the “square groups” of the ordinary writing.

But, what if the Ramesside “groups” were actually not really “groups”?

Or better, what if there were an easier and most efficient way to analyses, interpret, describe, and therefore display them?

People seem to often assume that there are only two main ways to write a string of text, namely vertically or horizontally. 

This however is in not true.

It is also possible to write short horizontal strings of text within a larger main vertical frame, and similarly it is possible to write short vertical strings of text within a larger main horizontal frame.

The second case, in particular, is attested in Asian scripts.

Have a look at the following image:

This is a Japanese text, as you can see from the next image, it is written in short vertical “columns” (red), organized into one general horizontal “line” (green).

Namely, the text is written (the text in the pic is right to left, I am transcribing it left to right because it is easier to explain the concept)

---------------

大馬大呉店

博町光服の

---------------

But it has to be read:

大博 | 馬町 | 大光 | 呉服 | 店の

namely:

大博馬町大光呉服店の

Japanese writing has “groups” (i.e. characters, marked in white in the following picture) that in some general respect could be compared to Egyptian groups (they are not identical, I know, but *in some respects* they are conceptually comparable).

Now, *no one* dealing with Japanese writing would consider the short vertical strings of text (the red bits above) as some sort “non-ordinary elongated groups(characters)”. And *no one* would ever consider to code such hypothetical elongated vertical groups into Unicode, or to devise control characters or anything to pre-compose them. They are just sequences of *regular* groups(characters) written vertically within a main horizontal layout.

And in order to represent such a text in Unicode, you just have to play with the layout of your text in your text editor. You don’t need special control characters or anything else, it is *just* a question of *layout*.

Now, Ramesside inscriptions can be analysed exactly in the same way.

In other words, what you are interpreting as the Ramesside “abnormal elongated/tall groups” (red in the pic above) could actually be interpreted just as short strings of texts written vertically (i.e short *columns*) within a bigger main horizontal layout (i.e. in lines, in green).

Such an interpretation has a few advantages both in respect to the actual data from the ancient texts and for what concern Unicode etc.

First, someone was pointing out that there are thousands of such “Ramesside groups” and a large part of them is attested only once. Well, if you interpreted them as short columns of texts, rather than as groups, you understand why: those are short strings of texts, they are not isolated independent graphic and orthographic units. 

This also helps to answer the question: “how many groups are you expecting to find in the future?”
Virtually, potentially, infinite.

If tomorrow we should find a new Ramesside temple with a new long text inscribed in “Ramesside groups”, there could be hundreds, even thousands of these new short vertical strings of texts.

Trying to describe (and encode) them as independent units (or devising control characters to build them) is more or less like trying to encode every singly column of hieroglyphic text as single independent “groups”. 

It does not make much sense, as it would not make sense to try to describe and code every single horizontal sequence of groups(characters) in the Japanese texts above.

Rather, it would make much more sense to deal with these “Ramesside short vertical strings of text disposed in horizontal lines” as if they were.. well, short vertical strings of text disposed in horizontal lines.

This can be *easily* done at the layout level, either with xml/CSS style sheets, or with any other layout algorithm of any text editor. Word can do that, already. It is enough to use a vertical font, and create a page layout with horizontal sequences (= the lines) of very short vertical columns.

That is all what you need.

The Ramesside “group” (or “tall group”)   used by Bob as example in his last proposal, for instance, would not need to be built and displayed as “group” (i.e. with control characters etc) at all, but it could just be inputted as a plain sequence of independent signs displayed with a vertical font within a vertical column, in a general layout that present series of horizontal sequences (i.e. a “lines”) of such short columnts. No need for ligatures, no need for control characters, nothing. Just vertical fonts and properly set up layouts for the page where the signs will be displayed.

Obviously, there will still be signs that will need to be combined in “groups”, i.e. in “real” square groups. As you can see from the pic above, however, if you interpret the Ramesside texts as composed of short vertical columns, the number of groups needed decrease significantly. And in general, those groups are often the same basic groups that you find in good old ordinary Egyptian square groups orthography.

So no need to list and encode (as Unicode or at the font level, doesn’t matter) thousands of unique groups, we would just need to encode the basic square groups and then playing a bit with the layout of the text.

And this brings me to the next point:

7) What are the “square groups”?

I have never specifically worked on square groups from a linguistic point of view, and I do not know if there is any specific study about square groups and their graphic behaviour within a larger linguistic frame (i.e. for instance comparing them with the behaviour of similar “groups” in other writing systems). This is one of those points where the experience of some of you could be extremely useful.

Such a study could be used, for instance, to define some contextual rules to allow the font to automatically manage the combination of at least some of these groups, or at least to define some rules to automatically prioritize one ligature over the other (if we are working with ligatures at the font level).

If such a study exists, then it would be useful to take it into consideration in the discussion.
If such a study does not exist, then perhaps it could be worth considering doing it *before* submitting any new proposal involving control characters to the Unicode consortium, because I think it would be better to be sure we really understand how those groups work, before suggesting a method to encode them.

I am obviously talking about control characters etc, I am not talking about expanding the basic set of glyphs. 

Otherwise, we would be encoding something whose actual functioning has never been studied, and therefore we would risk to be encoding features and elements that are actually superfluous, or that could have been managed in a more efficient way at other levels (ligatures within the fonts, layout table at the texteditor level etc).

Ok, I guess this is more or less all what I wanted to say.

Now feel free to ignore me :-)

Best

Marwan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 799 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 317 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 654 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 806 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 654 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.png
Type: image/png
Size: 910 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image013.png
Type: image/png
Size: 3701 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image015.png
Type: image/png
Size: 1698 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image017.png
Type: image/png
Size: 622 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image019.png
Type: image/png
Size: 661 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image021.png
Type: image/png
Size: 483 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image022.png
Type: image/png
Size: 622 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image023.png
Type: image/png
Size: 623 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image024.png
Type: image/png
Size: 320 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image025.png
Type: image/png
Size: 620 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image026.png
Type: image/png
Size: 489 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image028.png
Type: image/png
Size: 3663 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image029.png
Type: image/png
Size: 661 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image031.jpg
Type: image/jpeg
Size: 1021 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image033.jpg
Type: image/jpeg
Size: 896 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image035.png
Type: image/png
Size: 14433 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image037.png
Type: image/png
Size: 20432 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0019.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image038.png
Type: image/png
Size: 4403 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0020.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image039.png
Type: image/png
Size: 7742 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0021.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image041.jpg
Type: image/jpeg
Size: 1095 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image043.png
Type: image/png
Size: 703 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0022.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image045.png
Type: image/png
Size: 465 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0023.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image046.png
Type: image/png
Size: 13279 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0024.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image047.png
Type: image/png
Size: 11587 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0025.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image048.png
Type: image/png
Size: 11995 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0026.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image050.png
Type: image/png
Size: 21407 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0027.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image052.png
Type: image/png
Size: 878 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/8de5bd26/attachment-0028.png>