<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><div>), we are dealing with a compound classifier made of two signs, the /n/ has an iconic value and the whole group refer to a man rowing in water.</div><div><br class=""></div><div>Etc., etc.</div><div><br class=""></div><div>So position is 'just an esthetic, layout matter, not a linguistic one’ as you say? This kind of assertion reflects badly on our understanding of the hieroglyphic system. That’s a pity to make such unwarranted statements in a discussion also aimed at non-specialists to whom we try to explain things as straightforwardly as possible in order to come up with a solution that is satisfying for everyone.</div><div><br class=""></div><div>Accordingly, if Unicode aims first and foremost at rendering the ‘linguistic’ dimension of writing, the examples above should suffice to show the importance of the ‘quadrat' organization of this script. Again, you might not like it from a computer/font oriented perspective; I agree it’s not convenient to encode, it might even not be possible to encode it at all in Unicode because the standard has not the capabilities needed (and only higher level protocols could then handle this). All of this is fine with me, but it would be great not to distord presentation of the data.</div><div><br class=""></div><div>[I leave here alone other semiotic dimensions of writing: the spatial arrangement is part of the ‘orthography’ of the scribes, not necessarily meaningful at the ‘linguistic’ level strictly speaking, but at the level of scribal practices, etc.: why don’t we use IPA for our modern languages? simply because writing is much more than ‘linguistic’ stricto sensu and that it make sense to know who writes ‘next’ and who plays with the script and writes ‘neckst’. As simple as that.] </div><div> </div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">No more than illuminated initial capital letters in medieval manuscripts. </div><div class="">Like these:</div><div class=""><br class=""></div><div class=""><a href="http://www.sothebys.com/content/dam/stb/lots/L12/L12240/256L12240_6G4Y2.jpg" target="_blank" class="">http://www.sothebys.com/content/dam/stb/lots/L12/L12240/256L12240_6G4Y2.jpg</a><br class=""></div><div class=""><br class=""></div><div class="">They are nice, they are fancy, they are there (hundreds of thousands of them), but they do not carry any additional linguistic information whatsoever. Thus, there is not specific need to (and in fact they are not) encode or represent them in unicode.</div></div></div></div></blockquote><div><br class=""></div>This comparaison is hilarious.</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">As far as I know (and please correct me if I am wrong), the only utility that recording the position of signs could have on a practical level would be to fill lacunas in text or to suggest alternative readings in hieratic scripts.</div></div></div></div></blockquote><div><br class=""></div>Nope, see above. This is one side-interest of the control characters that I mentioned in the discussions, indeed, but definitely not the only one, since the arrangement is meaningful at multiple levels.</div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal" style="text-align:justify"><b class=""><span lang="EN-GB" class="">1) JSesh approach</span></b> </p></div></blockquote></div><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal" style="text-align:justify"><span lang="EN-GB" class=""><br class=""></span></p></div></blockquote></span>Sure, everything needs not be dealt with at the level of Unicode, but the data needed should not be hidden in the ligatures embedded in the font either.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Again, what data?</div><div class="">What is the *linguistic* (not graphic, not philological) information carried by groups that is so important to code?</div></div></div></div></blockquote><div><br class=""></div>See above.<br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal" style="text-align:justify"><b class=""><span lang="EN-GB" class="">2) Groups in fonts</span></b></p><div style="text-align:justify" class=""><br class=""></div></div></blockquote></span>OK, sure. But then again control characters have the advantage of being explicit about the relative position of signs when a group is not in a font: how would you proceed for storing such an information, as a lay user, when using ligatures? (this is a real question, nothing ironic here).</div></blockquote><div class=""><br class=""></div><div class="">I am not sure I understand your question: the information about the spatial distribution is already coded in the ligature. the ligature IS the information.</div><div class="">And if the ligature does not exist, it takes (literally) 30 seconds to create it within a font. And with a common database and a common font of reference, if would be extremely easy to create a common shared table of ligatures that will allow everyone to see exactly the same groups (or alternatively if i write my text with the font x with the ligature x, it would be enough to embed the font itself in the text file (there are various ways to do so), because everyone would be using the same font or at least the same set of ligatures.</div></div></div></div></blockquote><div><br class=""></div>All this was clear, sure. What I meant is that the ligature are purely ‘graphic’ right? No information is stored about the position of one sign with respect to another?</div><div><span class="" style="text-align: justify;"> </span><span class="" style="text-align: justify;"> </span><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal" style="text-align:justify"><b class=""><span lang="EN-GB" class="">3) the 4 “small sign in the corner of big sign” control characters.</span></b></p></div></blockquote></span>I’m glad to see that your solution is exactly the same as the one we suggest! Indeed, there are logically 2 ‘variables’ (Top vs Bottom and Left-Right), if the sequence of signs indicates the Left-Right unambiguously (like in your example), then we only need to encode explicitly the Top vs Bottom, of course. This is basically how we represented things with Michael at the pub.</div><div class="">Please keep in mind that the four operators come from another type of syntax.</div></div></blockquote><div class=""><br class=""></div><div class="">This is not what I am suggesting. I am suggesting 4 control characters: top-bottom, left-right, A\B, B/A. instead of top-bottom, left-right + four corners.</div><div class="">Or perhaps I am not understanding your system.</div></div></div></div></blockquote><div><br class=""></div>OK, then I disagree because of the polysemic value of A/B and B/A.</div><div> <br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal" style="text-align:justify"><b class=""><span lang="EN-GB" class="">4) Vertical and horizontal script and control characters</span></b></p><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div></span>I do not understand why you do entirely get rid of the notion of ‘quadrat’ in your example. If you encode your text as /hthr-H*(n:t)-tA:tA/, the text would be displayed correctly whatever the orientation (hltr, hrtl, vrtl, vltr), no? Of course, one needs the notion of quadrat in the encoding for this; and this is a nice case for showing that we *need* this well-defined notion in the encoding, not just sequences of glyphs.</div></div></blockquote><div class=""><br class=""></div><div class="">If you want to have the "notion of quadrate" in unicode, then you have to introduce at least another control character that you will have to use in front of *every single quadrate* in your text. if i understood correctly, one of the proposal that were circulating was indeed suggesting something like that. Which means that to display any text you will probably end up using more control characters that hieroglyphic signs themselves. This can be a sound way of thinking in a MdC (as you don't like JSesh ;-) ) perspective, but I doubt it make sense in unicode (and more important i doubt the people of the unicode consortium will think it make sense).</div><div class=""><br class=""></div><div class="">Unless you want to code every single possible "quadrate" as an independent glyph: that would thus end up being conceptually comparable to a chinese character.</div><div class=""><br class=""></div><div class="">But I assume (i hope) we don't want do do that, right?</div></div></div></div></blockquote><div><br class=""></div>We use spaces between words, would it be bad to use quadrats separators between quadrats? Mutatis mutandis, it feels to me like saying ‘oh, no, there are blank spaces all around!’.</div><div><br class=""></div><div>More seriously, taking signs as basic units for Unicode might be a practical solution (even if it leads to many subsequent difficulties, see the vertical vs horizontal discussion), but denying the essential function of quadrats is kind of funny when discussing the introduction of control characters (1, 2, 38, it does not matter): what they do is building quadrats (implicitly or explicitly).</div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal" style="text-align:justify"><b class=""><span lang="EN-GB" class="">5) special characters, vertical/horizontal texts and input methods</span></b></p><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div></span>Your point escapes me, here. Unless it is a result of getting rid of the quadrats: within quadrats, the groups of hieroglyphs are essentially the same.</div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">With quadrats marked by special control characters would be even worse, as you would have to take into consideration even more possible combinations.</div><div class=""><br class=""></div><div class=""> <span style="text-align:justify" class=""> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><p class="MsoNormal" style="text-align:justify"><b class=""><span lang="EN-GB" class="">6) Ramesside “groups” (or “tall groups”).</span></b></p><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div></span>Why are they groups or quadrats and not ’small columns’? </div><div class=""><br class=""></div><div class="">The answer is simple and straightforward (and provided by your example): because they correspond to the size occupied by the A1 sign. Look at the example.</div></div></blockquote><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">but some signs do occupy the full height of the horizontal line (unlike in your Japanese example, which is nice, but as such irrelevant), which is the basis for deciding what counts as a unit (quadrat) or not. (Or do you have another definition in mind?). </div></div></blockquote><div class=""><br class=""></div><div class="">Not true.</div><div class="">This can be interpreted just as a question of layout, not as a question of grouping.</div></div></div></div></blockquote><div><br class=""></div>Paraphrasing what Ariel Shisha-Halevy once said to a colleague during a conference: you’re entitled to have your own kind of Egyptian if you want!</div><div>I’m not arguing against non-sense. But that’s a pity, because there are actually many cases (esp. in Ptolemaic temples) that fit perfectly with your ‘small columns’ hypothesis. </div><div>The Ramesside example that you provide simply does not work this way. </div><div><br class=""></div><div>And all the parallels from other scripts are pointless (and admittedly funny in the framework of this discussion), since none of these scripts are based on a quadratic structure that is close in any respect to Egyptian. Comparing apple with pears won’t help: and again, that’s a bit of a pity, because we have many cases in Egyptian of layouts similar to the ones you mentioned. These are nice cases of special layouts, indeed, and I agree with your analysis: we do not want to encode them. (unlike the quadrat structure).</div><div><br class=""></div><div> <br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">But if you want to be able to use it minimally for (1) standardized electronic corpus and (2) journals like LingAeg, etc. dealing with the Egyptian language, this would be a requirement. </div></div></blockquote><div class=""><br class=""></div><div class="">All the egyptian words quoted in my article published on the last issue of JNES were written with my font with just standard ligatures, without control characters. No one complained, no one told me anything, so I assume that such a system is indeed suitable for scientific publications, not only for writing tourists' names.. ;-)</div></div></div></div></blockquote><div><br class=""></div>I’m afraid that one paper consisting of a lexicographical discussion about the use of one word in one hieratic document cannot be taken as any evidence for disproving my point: you’re happy with the way your hieroglyphs are rendered? Perfect. But why should it be the case that people willing to render a simple hieroglyphic line as the one below would face difficulties? This escapes me.</div><div><br class=""></div><div> </div></body></html>