[Egyptian] Some general considerations

Sat Jul 23 10:46:07 BST 2016

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 [image: Inline image 2] tw,
you will just type in [image: Inline image 3] t +
“A\B-control-character” + [image:
Inline image 4]  w.

If instead you want to code for [image: Inline image 6] wt, then you will
just need to type in [image: Inline image 5] w +
“A\B-control-character” +  [image:
Inline image 7]  t.

If you want to render [image: Inline image 10] twt, then you just type
in [image:
Inline image 11] t + “A\B-control-character” +  [image: Inline image 12] w
+ “A\B-control-character” + [image: Inline image 13] 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.

[image: Inline image 14]

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:

[image: Inline image 15] + [image: Inline image 16]+
“left/right-ctrl-character” (sic!) + [image: Inline image 17] +
“up/down-control-character” (sic!) + [image: Inline image 18] + [image:
Inline image 19] + [image: Inline image 20]

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 [image: Inline image 21] and [image: Inline image 22] and
then the “up/down ctrl character (not a “left/right ctrl character) to
combine them with the [image: Inline image 23], 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:

[image: Inline image 24][image: Inline image 25]
"broken-control-character” [image:
Inline image 26] "broken-control-character” [image: Inline image 27][image:
Inline image 29][image: Inline image 30]

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:

[image: Inline image 31] + [image: Inline image 32] + [image: Inline image
33] + “up-down-control-character” + [image: Inline image 34] + [image:
Inline image 35] + “up-down-control-character” + [image: Inline image 36]

Which would be displayed as:

[image: Inline image 37]

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):

[image: Inline image 38] + [image: Inline image 39] + [image: Inline image
41] + [image: Inline image 42] + [image: Inline image 43] + [image: Inline
image 45]

And the ligature algorithm in the vertical font will render the
ligature [image:
Inline image 46].

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 [image: Inline image 47] and [image:
Inline image 48] 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

[image: Inline image 49]

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

[image: Inline image 50]

Here, instead, you have an ordinary Egyptian text,

[image: Inline image 51]

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

[image: Inline image 52]

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:

[image: Inline image 53]

could be split into two ordinary square groups, [image: Inline image 54]
 and [image: Inline image 55], 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:

[image: Inline image 57]

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).

[image: Inline image 56]

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).

[image: Inline image 58]

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.

[image: Inline image 59]

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”) [image: Inline image 60]  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/f26d4239/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tawy.jpg
Type: image/jpeg
Size: 4562 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tall group1.jpg
Type: image/jpeg
Size: 6521 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xAst.jpg
Type: image/jpeg
Size: 3110 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h.jpg
Type: image/jpeg
Size: 2014 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jap text.jpg
Type: image/jpeg
Size: 13279 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hthr hnwt tawy 1.jpg
Type: image/jpeg
Size: 9092 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h.jpg
Type: image/jpeg
Size: 2014 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0009.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: classical 2.jpg
Type: image/jpeg
Size: 134706 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0010.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hthr.jpg
Type: image/jpeg
Size: 4416 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0011.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w.jpg
Type: image/jpeg
Size: 2104 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0012.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nw.jpg
Type: image/jpeg
Size: 1714 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0013.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0014.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0015.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0016.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h.jpg
Type: image/jpeg
Size: 2014 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0017.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: israel 2.jpg
Type: image/jpeg
Size: 449778 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0018.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jap text copia.jpg
Type: image/jpeg
Size: 11587 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0019.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0020.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jap text copia 2.jpg
Type: image/jpeg
Size: 11995 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0021.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nw.jpg
Type: image/jpeg
Size: 1714 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0022.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0023.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: israel 1.jpg
Type: image/jpeg
Size: 37460 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0024.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tw.jpg
Type: image/jpeg
Size: 2452 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0025.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hthr.jpg
Type: image/jpeg
Size: 4416 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0026.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h.jpg
Type: image/jpeg
Size: 2014 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0027.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w.jpg
Type: image/jpeg
Size: 2104 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0028.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nw.jpg
Type: image/jpeg
Size: 1714 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0029.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0030.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w.jpg
Type: image/jpeg
Size: 2104 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0031.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0032.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: israel 2 copia.jpg
Type: image/jpeg
Size: 449778 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0033.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0034.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0035.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0036.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twt2.jpg
Type: image/jpeg
Size: 5167 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0037.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h.jpg
Type: image/jpeg
Size: 2014 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0038.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: classical 1.jpg
Type: image/jpeg
Size: 5244 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0039.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nw.jpg
Type: image/jpeg
Size: 1714 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0040.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hthr.jpg
Type: image/jpeg
Size: 4416 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0041.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0042.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0043.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tA.jpg
Type: image/jpeg
Size: 1196 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0044.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tall group.jpg
Type: image/jpeg
Size: 6174 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0045.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wt.jpg
Type: image/jpeg
Size: 2446 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0046.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hthr.jpg
Type: image/jpeg
Size: 4416 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0047.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hthr hnwt tawy 2.jpg
Type: image/jpeg
Size: 9078 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0048.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nbt.jpg
Type: image/jpeg
Size: 2393 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0049.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0050.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nw.jpg
Type: image/jpeg
Size: 1714 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0051.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hnwt.jpg
Type: image/jpeg
Size: 5740 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0052.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hnwt.jpg
Type: image/jpeg
Size: 5740 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment-0053.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Some general considerations.pdf
Type: application/pdf
Size: 282164 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160723/f26d4239/attachment.pdf>