From bobqq at live.co.uk  Mon Aug  1 11:33:25 2016
From: bobqq at live.co.uk (Bob Richmond)
Date: Mon, 1 Aug 2016 11:33:25 +0100
Subject: [Egyptian] Towards consensus on hieroglyphic writing in Unicode
	(Urgent)
Message-ID: <DUB402-EAS378DC023B45585130295E1E91040@phx.gbl>

Hi All

 

Mark-Jan, St?phane and I will be participating remotely in a UTC meeting on Thursday (late afternoon European time). As St?phane pointed out on Friday (his email is reproduced below) it is desirable we make progress towards establishing a consensus on what form hieroglyphic writing in Unicode should take. 

 

I will therefore try to compile a document the three of us (and others in this group I hope) can agree to by Thursday. Objections or concerns with any points to be listed so UTC have a clear picture of where we are.

 

I?ll first draft the document tomorrow (Tuesday) and circulate so if you would like to add a top level topic beyond the four below please let me know what you want. Also, if you have any specific objections to state now, drop me an email on list or privately. We can then drill down into detail on unresolved items.

 

I?ll take the consensus situation a month ago (before Cambridge) as a starting point (1 and 2) then add what I think summarizes other key points (3 and 4).

 

1. EGYPTIAN HIEROGLYPH HORIZONAL JOINER and EGYPTIAN HIEROGLYPH VERTICAL JOINER are an acceptable basis to build on.

 

TLA and Ramses project were comfortable with this in their April letters to UTC. This remains a consensus item.

 

2. Concerns were expressed about EGYPTIAN HIEROGLYPH LIGATURE JOINER

 

TLA and Ramses project along with Nederhof et al stated they had concerns in their April letters to UTC. This needs to be resolved before we can move forward.

 

3. Additional control characters relating to repertoire extension issues

 

Control characters such as stack/monogram joiner/insert centre have been floated as alternatives to encoding certain combinations as distinct characters (as is currently the policy for repertoire extension). These could be added as controls at a later stage but are not essential at this point.

 

4. Vertical writing and ?tall group? support should be better supported from the start

 

The 3 control solution focuses too much on horizontal text. The implicit OpenType approach to elements of shaping (as in section 4) is too unpredictable for usability. This should be addressed  (see the two Group Joiners for my proposed enhancement to deal with this).

 

Bob

 

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

 

-----Original Message-----

From: Egyptian [mailto:egyptian-bounces at evertype.com] On Behalf Of St?phane polis

Sent: 28 July 2016 11:38

To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com <mailto:egyptian at evertype.com> >

Subject: Re: [Egyptian] Two group joiners

 

Dear Mark-Jan,

 

Yeap, I do agree.

 

As you can see, I?m simply trying to be imaginative and to think about the better possible consensus before the very close deadline (in order not to take the chance for everything to collapse or to go in unwarranted territories, because I do care). As such, I understand perfectly the cost of getting rid of parenthesis; my point is that, as we know that we need to make clusters (and there is not much room for discussion about this basic principle), the only alternative would be this ?glue-precedence? operator, discussed in Section 9 of the document, that has not yet been discussed by others. 

 

It?s one or the other, but there are logically no third option as far as I understand.

I would like to hear what you and others think about the ?scope operator? for the insertion, but to sum up, a basic consensus document for control characters could in my view contain only 8 control characters (and we know that we could handle most [if not all] of the cases discussed so far with these characters, that the scheme will be coherent, that it will be easy to expand with others operators without destroying everything, etc.), namely:

 

1) Vertical [:] // Already in MdC and in Bob?s proposal

2) Horizontal [*] // Already in MdC in Bob?s proposal

 

3) Groups (precedence operator) [.] // Needed for clusters (insertion, vertical, horizontal) and for avoiding the multiplication of group-joiners of various level in the future.

 

4) Top-left [?] // Agreed on by most (if not all)

5) Bottom-left [?] // Agreed on by most (if not all)

6) Top-Right [?] // Agreed on by most (if not all)

7) Bottom-Right [?] // Agreed on by most (if not all)

 

8) Scope operator [!] // A suggestion to be discussed

 

Maybe that a quadrat separator [-] should be added in order to avoid issues, e.g. with multiple corners insertions following one another (but this should be tested of course), and because after all, the basic unit of this writing system is the quadrat (not the sign, even if it happens that 1 sign = 1 quadrat).

 

These operators correspond to a very ?flat? and linear syntax (without ?begin? and ?end? markers that seem to be so problematic), which is a requirement from the Unicode specialists as I understand it.

 

If needed, I am ready to leave out of this ?consensus? document:

- The join

- The insert-center

- The stack

- The empty

 

Not because I think we don?t need them (I think it would be great to have), but (1) because I would like the discussion to focus on the 8/9 operators above, (2) because these additions are easy to make in a second step and will not impedes much for short term encoding.

 

That?s about it for me at the moment. I leave the floor to you, Bob and others. 

 

Let me stress that it?s probably difficult for me/us to make more steps in the direction of a consensus. At this stage, everyone should probably try and understand other?s point of view and accept that compromises are needed rather quickly...

 

As you can see in the summary above, the central point is about the group/precedence operator. 

Then the ?scope? operator and what you think about it.

The rest should be easily agreed on.

 

Unicode is not a one time thing, as Bob said, sure, but one decision can affect all the future developments.

 

Take care,

 

St?phane

 

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

Chercheur qualifi? F.R.S.-FNRS

 

Universit? de Li?ge

Service d'?gyptologie

D?partement des sciences de l?Antiquit?

Place du 20-Ao?t,

B-4000 Li?ge

 

http://www.egypto.ulg.ac.be

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160801/c047c972/attachment.htm>

From bobqq at live.co.uk  Wed Aug  3 17:36:36 2016
From: bobqq at live.co.uk (Bob Richmond)
Date: Wed, 3 Aug 2016 16:36:36 +0000
Subject: [Egyptian] Consensus and Compromise on controls - discussion
	document
Message-ID: <HE1PR1001MB1067B814E13FEC488F4F706391060@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>

Hi All


I've not heard from anyone since I floated points on consensus on Monday. I know St?phane is on vacation - not the ideal time of year.



So here's my take on where we are and what we should be able to agree on for the UTC meeting. I've tried to write this objectively and I'll include objections or additions if I receive them.



I'm not happy to be dropping functionality for the first stage but after submitting the 3 character proposal April 2015 feedback and objections manifested 3 months ago and most of this only recently at Cambridge. There is still no clarity about exactly what is required for rare forms of writing. I've not been able to resolve all the issues by myself in the limited time since Cambridge.



Comments, objections, corrections all appreciated



Thanks

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160803/46504560/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EgyptianConsensusAndCompromise2016-08-03-DRAFT.pdf
Type: application/pdf
Size: 514372 bytes
Desc: EgyptianConsensusAndCompromise2016-08-03-DRAFT.pdf
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160803/46504560/attachment.pdf>

From egyptian-bounces at evertype.com  Mon Aug  1 18:15:30 2016
From: egyptian-bounces at evertype.com (egyptian-bounces at evertype.com)
Date: Mon, 01 Aug 2016 18:15:30 +0100
Subject: [Egyptian] Auto-discard notification
Message-ID: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>

From: Serge Rosmorduc <rosmord at gmail.com>
Subject: Re: [Egyptian] Some general considerations
Date: 1 August 2016 at 13:14:23 GMT-4
To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>



Le 23 juil. 2016 ? 19:12, Marwan Kilani <odusseus at gmail.com <mailto:odusseus at gmail.com>> a ?crit :

> Hello everyone
> 
> 
>> Third
>> 
> And your solution is a good one ? I have absolutely no doubt ? as long as you do not want to *search* for the relative position of signs with respect to one another. This is however a piece of information that is, like it or not, part of the ?orthographic? system of ancient Egyptian and to which we want to have access (see further Simon?s mail earlier this week).
> 
> In general, the spatial distribution of signs (i.e. the "grouping") has *no meaning at all* in Egyptian. No semantic, phonological, or morphological information is coded in the relative position of the signs. 
> This is demonstrated by the texts themselves: if the relative position of the signs were linguistically important, you would have some form of regularity, with some combinations being possible and others being forbidden. This is not the case.
> 

There are a few issues here:

a) right or wrong, the egyptological community *wants* a ? close enough ? representation of the original text. An automated layout is simply going to alienate them. 
I?m not speaking of corpus linguists here, but of almost all the people I have interacted with concerning JSesh, and they are probably a good sample. Usually, I have a hard time explaining them they are not doing a facsimile. 

b) there *is* information in sign positioning. In particular, quadrants limits are more likely to indicate word separation. In some cases, sign positioning can hint at possible alternative readings 
(I have a specific example in P. Turing 1880, where Gardiner?s reading D37:A1 could be replaced by D37:t with a better meaning. A ? flat ? rendering, like ? D37-A1 ? would have made the alternative rendering 
much more difficult to make.

c) and of course, in monumental texts, sign positioning can be really significant - our colleagues working on Ptolemaic temples will probably be quite vehement about it. For instance, in the spelling pt:HH:tA for Pt?.

Your approach is fine for some uses (and probably allows much faster typing, save when you have 50 orthographies for one word like we do),
 but you start from the standpoint that it?s reasonable to remove philological information from the document, and encode the pure linguistic string. 
it won?t work for most scholars, because most of our texts are damaged, have unsecure readings, etc. It?s not only about scholarly traditions.

> 
> Perhaps this question has been already asked, but honestly so far I haven't heard or read any convincing answer, and I haven't seen any common example (i can exclude there could be some uncommon case, i obviously have not seen all the egyptian texts existing in the world) where the position of a sign in respect with the other signs around it carries and linguistic information.
> 

nw:mw for m-?nw for instance, on the one hand, and pt:HH:tA on the other hand.


Best regards,

Serge


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160801/4186123b/attachment.htm>

From egyptian-bounces at evertype.com  Wed Aug  3 20:21:30 2016
From: egyptian-bounces at evertype.com (egyptian-bounces at evertype.com)
Date: Wed, 03 Aug 2016 20:21:30 +0100
Subject: [Egyptian] Consensus and Compromise on controls - discussion
	document
Message-ID: <mailman.3.1470252090.261441.egyptian_evertype.com@evertype.com>

From: Serge Rosmorduc <rosmord at gmail.com>
Subject: Re: [Egyptian] Consensus and Compromise on controls - discussion document
Date: 3 August 2016 at 15:19:49 GMT-4
To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>


Dear Bob,

Thanks for this posting. I have just returned, and spent most of monday afternoon reading the lengthy discussion you all have had.

Here are my comments about your document:

a) Point 1 is ok.

b) The wording of point 2 seems to me a quite biased. For instance, complex ligatures with ? or ? are the rule instead of the exception. 
The second one appears a lot in titles - and prosopographical databases, which include personal titles, are a good candidate for the use of Unicode. 

I object to a number of sentences:

"No detailed list of quadrats for which LIGATURE is inadequate has been submitted by Egyptologists or others ? :

We *have* given a number of examples for which LIGATURE was not precise enough. We won?t give an exhaustive list, for a number of reason: 
one counter example is sufficient ;  the coverage we have for the monumental corpus is not good enough ; it takes lots of time to find such examples 
by non-computerized means.

In Simon?s mail, he gives you an example where E6 LIGATURE Z2 would not give you the original result.

My position (and I suppose, the position of my colleagues) is the following:

	a) I acknowledge that the current technologies for text rendering are not powerful enough for general hieroglyphic text rendering
	b) I?m happy to have a limited system available
	c) as long as there can be an upward compatibility with more precise systems.

I understand that, given the current opentype system, font creators are likely to use the opentype substitution system for rendering any grouping, and that, as a consequence, 
we will need to provide lists of precomposed groups. But I think it would be ill-advised for this list to define the semantics of the stream of code points.  

In other words : if a opentype renderer is able to render fully a stream of hieroglyphic code-points, and that this stream is also understood by some high-level protocol renderer, 
they must provide the same result, without a need for precomposed groups known by the high-level protocol renderer.

Or: a human reader (knowing the codes and their meanings) should be able to predict the output of a particular stream.

?  The vast majority of typeset works in print use horizontal text and can be encoded using LIGATURE along with the other two. ? 
Your tests where done on relatively simple, hieratic texts. This is not ?  The vast majority of typeset works in print ?.  The IFAO publications of Ptolemaic temples, for instance, 
form a large part of those typeset texts (what is true is that most typeset texts are rendered as horizontal texts.)


So, I would propose :

2. There was no consensus about the EGYPTIAN HIEROGLYPH LIGATURE JOINER. Most Egyptologists in the meeting, and a number of computer scientists, felt it was too imprecise. A few examples of problematic cases where given. Some would prefer to use a geometrical approach of one form or another instead but no proven approach has
been suggested yet. This needs to be resolved on the basis of solid data and investigation. LIGATURE may need to be supplemented or replaced to accomplish what is seen as needed.

Comments/additions/corrections?


c) Point 4: as the discussions and examples have shown, complex groups are by no mean restricted to vertical text (or even to the New Kingdom and later) - see Simon?s mail.
I feel the wording you use will make it more difficult to include a system to deal with them later (be it another set of operators (as you first proposed in april, if I remember well, before mixing this operator with the ligature), or some parenthesis-like system.

4. Embedded groups support
The two control character approved in point one suffice for over 95% of groups. But in a few cases in horizontal texts, and quite frequently in vertical texts, at least one level of subgroups is needed. There is a view Unicode gives an opportunity to encourage new directions. The implicit OpenType approach to elements of shaping for vertical and tall group text (as in L2/16-018 section 4) is too unpredictable for usability and this should be addressed (see http://www.unicode.org/L2/L2016/16214-egyptian-ctrl-chars.pdf for possible enhancements to deal with this).


Compromised solution:

Action : I agree.

I?m not sure point "Agree two simple higher level protocols to be used alongside this limited system to enable work to move forward on specialist software support and database encoding in Unicode. One simple HLP for majority everyday use and a superset for specialist requirements (including vertical text, tall groups, and rare quadrats). ? completely belongs there (and there is a timing problem. I agree that a multi-layer system would be useful - I have even started to write one myself for a future version of JSesh. But it?s not our priority. And certainly not with deadlines as october.

Update section 11.4 Egyptian Hieroglyphs of the Unicode Standard to use the two control system rather than MdC (as stands at Unicode 9.0). Changes to Unicode data tables and technical notes? 

ok with that. The original MdC should probably still be referred to, for historical reasons.

"Immediate follow up
Establish specialist Egyptologist requirements clearly and consult with a wider expert user base. Coordinate an extended control scheme with the first expansion to the hieroglyphic repertoire. Start immediately and it should be possible to resolve key issues in months not years. The greatest Unicode limitation for hieratic transcription and many other purposes is a relatively small number of unencoded hieroglyphs rather than control-related issues so both need addressing soon. Prepare consensus update for consideration at UTC meeting starting 31st October.
"

I?ve issues regarding the timing. I feel that *some part* of the hieroglyphic expansion can be ready by the end of october. I?m not at all sure for the extended controls.

? Disadvantages ? : 
I agree with the first sentence : For the majority of scholars and virtually all casual users, using a system that almost but not quite meets their needs will be a little frustrating until more controls are added.

Regarding the second sentence: ?  Web sites such as Wikipedia will probably want to stick with non-text methods for rendering hieroglyphs (e.g. WikiHiero) until a more complete solution is available. ? 

well, if we have systems which implement high level protocols in a reliable way for the Web (as Mark-Jan has demonstrated with his Javascript version of RES), I see no reason for 
sites like Wikipedia to resort to non-HLP systems, save for simple quoting of signs and short words in any case, even if a Unicode solution appears.

Best regards,

Serge








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160803/745c05b5/attachment.htm>

From everson at evertype.com  Wed Aug  3 20:39:10 2016
From: everson at evertype.com (Michael Everson)
Date: Wed, 3 Aug 2016 15:39:10 -0400
Subject: [Egyptian] Consensus and Compromise on controls - discussion
	document
In-Reply-To: <HE1PR1001MB1067B814E13FEC488F4F706391060@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>
References: <HE1PR1001MB1067B814E13FEC488F4F706391060@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <78AEE005-95CD-409D-916F-1CACFF9B47A0@evertype.com>

Some of Serge?s contributions were lost because he was sending from an address which he had not subscribed to the list. 


From schweitzer at bbaw.de  Thu Aug  4 11:27:01 2016
From: schweitzer at bbaw.de (Simon Schweitzer)
Date: Thu, 4 Aug 2016 12:27:01 +0200
Subject: [Egyptian] Consensus and Compromise on controls - discussion
 document
In-Reply-To: <mailman.3.1470252090.261441.egyptian_evertype.com@evertype.com>
References: <mailman.3.1470252090.261441.egyptian_evertype.com@evertype.com>
Message-ID: <0e6c42b8-5c92-f139-e203-e24fdd4fe7b1@bbaw.de>

Hi all,

(@Bob and Serge: I "cced" you because my mails were blocked from the 
mailing list software so that I cannot participate on the discussions 
since two weeks.)

I fully agree with Serges comments. I only want to add a question: Where 
are the group joiners you (Bob) mentioned in your draft "Two Group 
Joiners for Unicode Hieroglyphic" from the 22th of July or why are they 
hidden in the section 4 'tall group' and why are they not mentioned in a 
explicit way? IMHO, this is a quite good way to deal with the levels of 
hierarchies that are expressed with brackets in MdC. And I think 
St?phane likes these joiners, too, cf. his mail from the 28th of July.

Best regards,

Simon

Am 03.08.2016 um 21:21 schrieb egyptian-bounces at evertype.com:
> From: Serge Rosmorduc <rosmord at gmail.com>
> Subject: Re: [Egyptian] Consensus and Compromise on controls - discussion document
> Date: 3 August 2016 at 15:19:49 GMT-4
> To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>
>
>
> Dear Bob,
>
> Thanks for this posting. I have just returned, and spent most of monday afternoon reading the lengthy discussion you all have had.
>
> Here are my comments about your document:
>
> a) Point 1 is ok.
>
> b) The wording of point 2 seems to me a quite biased. For instance, complex ligatures with ? or ? are the rule instead of the exception.
> The second one appears a lot in titles - and prosopographical databases, which include personal titles, are a good candidate for the use of Unicode.
>
> I object to a number of sentences:
>
> "No detailed list of quadrats for which LIGATURE is inadequate has been submitted by Egyptologists or others ? :
>
> We *have* given a number of examples for which LIGATURE was not precise enough. We won?t give an exhaustive list, for a number of reason:
> one counter example is sufficient ;  the coverage we have for the monumental corpus is not good enough ; it takes lots of time to find such examples
> by non-computerized means.
>
> In Simon?s mail, he gives you an example where E6 LIGATURE Z2 would not give you the original result.
>
> My position (and I suppose, the position of my colleagues) is the following:
>
> 	a) I acknowledge that the current technologies for text rendering are not powerful enough for general hieroglyphic text rendering
> 	b) I?m happy to have a limited system available
> 	c) as long as there can be an upward compatibility with more precise systems.
>
> I understand that, given the current opentype system, font creators are likely to use the opentype substitution system for rendering any grouping, and that, as a consequence,
> we will need to provide lists of precomposed groups. But I think it would be ill-advised for this list to define the semantics of the stream of code points.
>
> In other words : if a opentype renderer is able to render fully a stream of hieroglyphic code-points, and that this stream is also understood by some high-level protocol renderer,
> they must provide the same result, without a need for precomposed groups known by the high-level protocol renderer.
>
> Or: a human reader (knowing the codes and their meanings) should be able to predict the output of a particular stream.
>
> ?  The vast majority of typeset works in print use horizontal text and can be encoded using LIGATURE along with the other two. ?
> Your tests where done on relatively simple, hieratic texts. This is not ?  The vast majority of typeset works in print ?.  The IFAO publications of Ptolemaic temples, for instance,
> form a large part of those typeset texts (what is true is that most typeset texts are rendered as horizontal texts.)
>
>
> So, I would propose :
>
> 2. There was no consensus about the EGYPTIAN HIEROGLYPH LIGATURE JOINER. Most Egyptologists in the meeting, and a number of computer scientists, felt it was too imprecise. A few examples of problematic cases where given. Some would prefer to use a geometrical approach of one form or another instead but no proven approach has
> been suggested yet. This needs to be resolved on the basis of solid data and investigation. LIGATURE may need to be supplemented or replaced to accomplish what is seen as needed.
>
> Comments/additions/corrections?
>
>
> c) Point 4: as the discussions and examples have shown, complex groups are by no mean restricted to vertical text (or even to the New Kingdom and later) - see Simon?s mail.
> I feel the wording you use will make it more difficult to include a system to deal with them later (be it another set of operators (as you first proposed in april, if I remember well, before mixing this operator with the ligature), or some parenthesis-like system.
>
> 4. Embedded groups support
> The two control character approved in point one suffice for over 95% of groups. But in a few cases in horizontal texts, and quite frequently in vertical texts, at least one level of subgroups is needed. There is a view Unicode gives an opportunity to encourage new directions. The implicit OpenType approach to elements of shaping for vertical and tall group text (as in L2/16-018 section 4) is too unpredictable for usability and this should be addressed (see http://www.unicode.org/L2/L2016/16214-egyptian-ctrl-chars.pdf for possible enhancements to deal with this).
>
>
> Compromised solution:
>
> Action : I agree.
>
> I?m not sure point "Agree two simple higher level protocols to be used alongside this limited system to enable work to move forward on specialist software support and database encoding in Unicode. One simple HLP for majority everyday use and a superset for specialist requirements (including vertical text, tall groups, and rare quadrats). ? completely belongs there (and there is a timing problem. I agree that a multi-layer system would be useful - I have even started to write one myself for a future version of JSesh. But it?s not our priority. And certainly not with deadlines as october.
>
> Update section 11.4 Egyptian Hieroglyphs of the Unicode Standard to use the two control system rather than MdC (as stands at Unicode 9.0). Changes to Unicode data tables and technical notes?
>
> ok with that. The original MdC should probably still be referred to, for historical reasons.
>
> "Immediate follow up
> Establish specialist Egyptologist requirements clearly and consult with a wider expert user base. Coordinate an extended control scheme with the first expansion to the hieroglyphic repertoire. Start immediately and it should be possible to resolve key issues in months not years. The greatest Unicode limitation for hieratic transcription and many other purposes is a relatively small number of unencoded hieroglyphs rather than control-related issues so both need addressing soon. Prepare consensus update for consideration at UTC meeting starting 31st October.
> "
>
> I?ve issues regarding the timing. I feel that *some part* of the hieroglyphic expansion can be ready by the end of october. I?m not at all sure for the extended controls.
>
> ? Disadvantages ? :
> I agree with the first sentence : For the majority of scholars and virtually all casual users, using a system that almost but not quite meets their needs will be a little frustrating until more controls are added.
>
> Regarding the second sentence: ?  Web sites such as Wikipedia will probably want to stick with non-text methods for rendering hieroglyphs (e.g. WikiHiero) until a more complete solution is available. ?
>
> well, if we have systems which implement high level protocols in a reliable way for the Web (as Mark-Jan has demonstrated with his Javascript version of RES), I see no reason for
> sites like Wikipedia to resort to non-HLP systems, save for simple quoting of signs and short words in any case, even if a Unicode solution appears.
>
> Best regards,
>
> Serge
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com
>



From schweitzer at bbaw.de  Thu Aug  4 12:00:57 2016
From: schweitzer at bbaw.de (Simon Schweitzer)
Date: Thu, 4 Aug 2016 13:00:57 +0200
Subject: [Egyptian] Auto-discard notification
In-Reply-To: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
Message-ID: <b10925d3-583b-f9a4-ab86-51a51e36a248@bbaw.de>

Hi all,

only a remark concerning the relevance of grouping.


> a) right or wrong, the egyptological community *wants* a ? close enough ? representation of the original text. An automated layout is simply going to alienate them.
> I?m not speaking of corpus linguists here, but of almost all the people I have interacted with concerning JSesh, and they are probably a good sample. Usually, I have a hard time explaining them they are not doing a facsimile.

And the control characters horizontal and vertical grouping would 
increase the acceptance of the Unicode encoding by the Egyptological 
community.

>
> b) there *is* information in sign positioning. In particular, quadrants limits are more likely to indicate word separation. In some cases, sign positioning can hint at possible alternative readings
> (I have a specific example in P. Turing 1880, where Gardiner?s reading D37:A1 could be replaced by D37:t with a better meaning. A ? flat ? rendering, like ? D37-A1 ? would have made the alternative rendering
> much more difficult to make.
>
> c) and of course, in monumental texts, sign positioning can be really significant - our colleagues working on Ptolemaic temples will probably be quite vehement about it. For instance, in the spelling pt:HH:tA for Pt?.
>

At this point, I cannot agree. In my opinion, complex combinations in 
Ptolemaic times should be addressed as signs not as grouping of signs 
like the sign E232 for anx-mi-ra or Di-anx-mi-ra. So, why not a special 
sign for nw:mw or for pt:HH:ta? And the highly developed encoding in the 
Graeco-Roman temples are always based on the sign level and not on the 
grouping level. In other words: there is a relevance which sign is used 
for a specific phonetic value. But I do not know any examples (in the 
ancient texts or listed by the colleagues who are interested in the 
Ptolemaic writing system) that the grouping of signs is relevant so that 
there is a difference between A:B and A-B.
By the way, if I remember correctly there is not only nw:mw for m-Xnw 
but also nw-mw. (But I cannot find the reference at the moment, sorry.)
Therefore, I am not convinced that these arguments could persuade all 
"suspicious" colleagues of the relevance of the grouping. But anyway, we 
should have these control characters because of the "political" 
arguments mentioned above by Serge in section a).

Best regards,

Simon



From everson at evertype.com  Thu Aug  4 14:36:58 2016
From: everson at evertype.com (Michael Everson)
Date: Thu, 4 Aug 2016 09:36:58 -0400
Subject: [Egyptian] Consensus and Compromise on controls - discussion
	document
In-Reply-To: <0e6c42b8-5c92-f139-e203-e24fdd4fe7b1@bbaw.de>
References: <mailman.3.1470252090.261441.egyptian_evertype.com@evertype.com>
 <0e6c42b8-5c92-f139-e203-e24fdd4fe7b1@bbaw.de>
Message-ID: <9CBCFC77-738A-4658-9B21-731247B85B5A@evertype.com>

On 4 Aug 2016, at 06:27, Simon Schweitzer <schweitzer at bbaw.de> wrote:
> 
> (@Bob and Serge: I "cced" you because my mails were blocked from the mailing list software so that I cannot participate on the discussions since two weeks.)

Your e-mail address is subscribed to the list. 

M


From everson at evertype.com  Thu Aug  4 14:45:21 2016
From: everson at evertype.com (Michael Everson)
Date: Thu, 4 Aug 2016 09:45:21 -0400
Subject: [Egyptian] Auto-discard notification
In-Reply-To: <b10925d3-583b-f9a4-ab86-51a51e36a248@bbaw.de>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <b10925d3-583b-f9a4-ab86-51a51e36a248@bbaw.de>
Message-ID: <A2F001CC-E9BD-4912-BAB4-1C33173222F4@evertype.com>

On 4 Aug 2016, at 07:00, Simon Schweitzer <schweitzer at bbaw.de> wrote:
> 
> In my opinion, complex combinations in Ptolemaic times should be addressed as signs not as grouping of signs like the sign E232 for anx-mi-ra or Di-anx-mi-ra.

Can you supply annotated images so that those of us who do not read Egyptian can follow this?

> So, why not a special sign for nw:mw or for pt:HH:ta?

You mean a unique encoded character? What is the visual representation?

Michael


From bobqq at live.co.uk  Thu Aug  4 16:40:05 2016
From: bobqq at live.co.uk (Bob Richmond)
Date: Thu, 4 Aug 2016 15:40:05 +0000
Subject: [Egyptian] consensus document
Message-ID: <HE1PR1001MB1067D7726288059AD02933EF91070@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>




Latest doc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/7c4477fb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EgyptianConsensus2016-08-04.pdf
Type: application/pdf
Size: 468452 bytes
Desc: EgyptianConsensus2016-08-04.pdf
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/7c4477fb/attachment.pdf>

From rosmord at gmail.com  Thu Aug  4 20:06:52 2016
From: rosmord at gmail.com (Serge Rosmorduc)
Date: Thu, 4 Aug 2016 21:06:52 +0200
Subject: [Egyptian]  Repeating operators
In-Reply-To: <A2F001CC-E9BD-4912-BAB4-1C33173222F4@evertype.com>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <b10925d3-583b-f9a4-ab86-51a51e36a248@bbaw.de>
 <A2F001CC-E9BD-4912-BAB4-1C33173222F4@evertype.com>
Message-ID: <C6AC0651-DC00-4A83-AD3E-25165911BFB8@gmail.com>

Hello,

Just to clarify what I said (near to a pint of cider a month ago, and during the discussion yesterday).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: repeatOperatorProposal.pdf
Type: application/pdf
Size: 133228 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment.pdf>
-------------- next part --------------


A few additional comments:

Regarding the INSERT-BOTTOM-LEFT control character, I would favor splitting it in two versions. 
Basically, if we consider the graphical order, this control is somehow ambiguous, for it?s a mix of INSERT-BOTTOM and INSERT-LEFT.

With the current interpretation :

- seen as something like INSERT LEFT, A INSERT-BOTTOM-LEFT B suggests that A comes before B in the linguistic stream (case of 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.pdf
Type: application/pdf
Size: 2426 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment-0001.pdf>
-------------- next part --------------
)

- seen as something like INSERT BOTTOM, A INSERT-BOTTOM-LEFT B, with B above A, suggests that B comes before A in the linguistic stream. (case of 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.pdf
Type: application/pdf
Size: 2408 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment-0002.pdf>
-------------- next part --------------
).

As we have all remarked, the first case is often attested with birds, and somehow points out to the linguistic order A-B (but not always)

The second case, attested with 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.pdf
Type: application/pdf
Size: 3102 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment-0003.pdf>
-------------- next part --------------
, is much more regular, and points out to the ? main ? sign being first.

On a practical level, due to the size of the gap, it?s also the one where the lack of a proper mechanism hurts most. I guess using 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-4.pdf
Type: application/pdf
Size: 2008 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment-0004.pdf>
-------------- next part --------------
 instead of 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-5.pdf
Type: application/pdf
Size: 1999 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment-0005.pdf>
-------------- next part --------------
 does not hurt scholars sensitivity as much as 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-6.pdf
Type: application/pdf
Size: 2411 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment-0006.pdf>
-------------- next part --------------
 instead of 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-7.pdf
Type: application/pdf
Size: 2408 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160804/8af9e2de/attachment-0007.pdf>
-------------- next part --------------
.

So, I might favor the use of INSERT-BELOW in this case.


As an aside, INSERT-TOP-RIGHT suffers from the same problem, but I feel it?s only problematic when rendering vertical texts (where it?s sometimes unclear if the 
inserted text belongs to the end of the previous quadrant or to the current one).

Best regards,

Serge



From s.polis at ulg.ac.be  Thu Aug  4 20:40:09 2016
From: s.polis at ulg.ac.be (=?utf-8?Q?St=C3=A9phane_polis?=)
Date: Thu, 4 Aug 2016 21:40:09 +0200
Subject: [Egyptian] Repeating operators
In-Reply-To: <C6AC0651-DC00-4A83-AD3E-25165911BFB8@gmail.com>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <b10925d3-583b-f9a4-ab86-51a51e36a248@bbaw.de>
 <A2F001CC-E9BD-4912-BAB4-1C33173222F4@evertype.com>
 <C6AC0651-DC00-4A83-AD3E-25165911BFB8@gmail.com>
Message-ID: <59D52E4E-FC83-4AB1-98C1-9AE351C7EEF0@ulg.ac.be>

Hi guys,

After the fruitful discussions we had today with the UTC, let me quickly support the proposal sent by Serge a few minutes ago (before going back to my ?holiday? week).

It is certainly most economic and ?expandable? system proposed so far for horizontal and vertical groups. We would have ? most of the time ? a very simple syntax of the type p*t:pt (supported by Bob), but we could use **, :: instead of the ?group joiners? (proposed by Bob), and ***, :::, etc. whenever needed for additional levels of embedding. It might be that not all the fonts or software solutions need to support more than three or four levels, but at least, we have a single and coherent system (explicitly advocated for by the UTC members during the discussion today, who urged us not to develop several HLPs): only two operators, and the syntax of repeating these operators would make the trick for several levels of embedding. 

In practical terms, it?s equivalent to Bob's proposals regarding joiners and group joiners, except that we know how to expand the syntax in a coherent way for additional levels of embedding (that are well attested) and we won?t need to add several types of ?groups joiners? later on. I think that an agreement could be made on this during the meeting tomorrow. 
At least, I would definitely support an agreement that goes in this direction.

The ?INSERT? operator(s) could function along the same lines: low level of precedence with respect to ?:? and ?*?, but higher than ?::? and ?**?, allowing for the insertion of groups in ?corners? (see the example in the document sent by Serge). However, this needs to be tested in order to make sure to keep everything unambiguous (as Mark-Jan pointed out to me) and we should certainly refrain from any hasty decision on this point. Let?s prepare a document that tackles the various cases discussed so far for the next deadline. Better good than fast.

Have a good evening,

St?phane

------------------------------------------------------
Chercheur qualifi? F.R.S.-FNRS

Universit? de Li?ge
Service d'?gyptologie
D?partement des sciences de l?Antiquit?
Place du 20-Ao?t,
B-4000 Li?ge

http://www.egypto.ulg.ac.be
------------------------------------------------------



> Le 4 ao?t 2016 ? 21:06, Serge Rosmorduc <rosmord at gmail.com> a ?crit :
> 
> Hello,
> 
> Just to clarify what I said (near to a pint of cider a month ago, and during the discussion yesterday).
> 
> 
> <repeatOperatorProposal.pdf>
> 
> A few additional comments:
> 
> Regarding the INSERT-BOTTOM-LEFT control character, I would favor splitting it in two versions. 
> Basically, if we consider the graphical order, this control is somehow ambiguous, for it?s a mix of INSERT-BOTTOM and INSERT-LEFT.
> 
> With the current interpretation :
> 
> - seen as something like INSERT LEFT, A INSERT-BOTTOM-LEFT B suggests that A comes before B in the linguistic stream (case of <PastedGraphic-1.pdf>)
> 
> - seen as something like INSERT BOTTOM, A INSERT-BOTTOM-LEFT B, with B above A, suggests that B comes before A in the linguistic stream. (case of <PastedGraphic-2.pdf>).
> 
> As we have all remarked, the first case is often attested with birds, and somehow points out to the linguistic order A-B (but not always)
> 
> The second case, attested with <PastedGraphic-3.pdf>, is much more regular, and points out to the ? main ? sign being first.
> 
> On a practical level, due to the size of the gap, it?s also the one where the lack of a proper mechanism hurts most. I guess using <PastedGraphic-4.pdf> instead of <PastedGraphic-5.pdf> does not hurt scholars sensitivity as much as <PastedGraphic-6.pdf> instead of <PastedGraphic-7.pdf>.
> 
> So, I might favor the use of INSERT-BELOW in this case.
> 
> 
> As an aside, INSERT-TOP-RIGHT suffers from the same problem, but I feel it?s only problematic when rendering vertical texts (where it?s sometimes unclear if the 
> inserted text belongs to the end of the previous quadrant or to the current one).
> 
> Best regards,
> 
> Serge
> 
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com




From mn31 at st-andrews.ac.uk  Fri Aug  5 00:50:44 2016
From: mn31 at st-andrews.ac.uk (Mark-Jan Nederhof)
Date: Fri, 5 Aug 2016 00:50:44 +0100
Subject: [Egyptian] Repeating operators
In-Reply-To: <C6AC0651-DC00-4A83-AD3E-25165911BFB8@gmail.com>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <A2F001CC-E9BD-4912-BAB4-1C33173222F4@evertype.com>
 <C6AC0651-DC00-4A83-AD3E-25165911BFB8@gmail.com>
Message-ID: <2049990.OxRmIQ1ydP@thuis>

On Thursday 04 Aug 2016 21:06:52 Serge Rosmorduc wrote:
> On a practical level, due to the size of the gap, it?s also the one where the lack of a proper mechanism hurts most. I guess using 
> PastedGraphic-4.pdf
> 
>  instead of 
> PastedGraphic-5.pdf
> 
>  does not hurt scholars sensitivity as much as 
> [...]

I see what you mean with 4 and 5.

But have you considered the raised arms (kA) ? Lots of groups can be put within the raised arms. 
If  a horizontal group, or even a vertical group is being inserted, and one wants to do this using
vertical grouping + JOIN, there is no guarantee the result will be close to what one expects
(the group being actually inside the bounding box of the raised arms). For me, it feels
right to fit the Hm sign inside kA using VERT+JOIN, which might well 'stick out' above.
But not say the 't', which one expects properly inside, and which moreover is being read 
phonetically after the kA (if that means anything).

This is why I think we should reconsider using insert-inside for such cases. Then also the cobra
could be seen in a new light.

For the syntax without brackets, see attachment. I'm not sure that for simple machinery this is any easier
to process than a bounded number of bracket nestings. Note there are 12 binding values hidden in this
model.

I have left open the exact notation for operator precedence. I see at least four possibilities, as listed in the
document.

Mark-Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paper.pdf
Type: application/pdf
Size: 96275 bytes
Desc: not available
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160805/61d838d6/attachment.pdf>

From ncs3 at cam.ac.uk  Fri Aug  5 09:03:48 2016
From: ncs3 at cam.ac.uk (Nigel Strudwick)
Date: Fri, 5 Aug 2016 09:03:48 +0100
Subject: [Egyptian] Repeating operators
In-Reply-To: <2049990.OxRmIQ1ydP@thuis>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <A2F001CC-E9BD-4912-BAB4-1C33173222F4@evertype.com>
 <C6AC0651-DC00-4A83-AD3E-25165911BFB8@gmail.com> <2049990.OxRmIQ1ydP@thuis>
Message-ID: <A5E7F908-2EE3-4A91-A979-B49C7AEEFF21@cam.ac.uk>

1. Is it possible to have an explanation of this system not intended for specialists? I have tried to read these reports and I do not understand a word. Or were there some diagrams I have missed?

2. I feel Ptolemaic hieroglyphs should be completely omitted from this system as they are a total "niche market?. As I recall in Cambridge, we agreed we would concentrate on the basic set of characters and minimise extensions to it. Do remember that the hieroglyphica extended set was only really developed for the IFAO producing typeset texts of Ptolemaic inscriptions.

Nigel


On 5 Aug 2016, at 00:50, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk> wrote:

> On Thursday 04 Aug 2016 21:06:52 Serge Rosmorduc wrote:
>> On a practical level, due to the size of the gap, it?s also the one where the lack of a proper mechanism hurts most. I guess using 
>> PastedGraphic-4.pdf
>> 
>> instead of 
>> PastedGraphic-5.pdf
>> 
>> does not hurt scholars sensitivity as much as 
>> [...]
> 
> I see what you mean with 4 and 5.
> 
> But have you considered the raised arms (kA) ? Lots of groups can be put within the raised arms. 
> If  a horizontal group, or even a vertical group is being inserted, and one wants to do this using
> vertical grouping + JOIN, there is no guarantee the result will be close to what one expects
> (the group being actually inside the bounding box of the raised arms). For me, it feels
> right to fit the Hm sign inside kA using VERT+JOIN, which might well 'stick out' above.
> But not say the 't', which one expects properly inside, and which moreover is being read 
> phonetically after the kA (if that means anything).
> 
> This is why I think we should reconsider using insert-inside for such cases. Then also the cobra
> could be seen in a new light.
> 
> For the syntax without brackets, see attachment. I'm not sure that for simple machinery this is any easier
> to process than a bounded number of bracket nestings. Note there are 12 binding values hidden in this
> model.
> 
> I have left open the exact notation for operator precedence. I see at least four possibilities, as listed in the
> document.
> 
> Mark-Jan
> <paper.pdf>_______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com




From mn31 at st-andrews.ac.uk  Fri Aug  5 09:28:24 2016
From: mn31 at st-andrews.ac.uk (Mark-Jan Nederhof)
Date: Fri, 5 Aug 2016 09:28:24 +0100
Subject: [Egyptian] Repeating operators
In-Reply-To: <A5E7F908-2EE3-4A91-A979-B49C7AEEFF21@cam.ac.uk>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <2049990.OxRmIQ1ydP@thuis> <A5E7F908-2EE3-4A91-A979-B49C7AEEFF21@cam.ac.uk>
Message-ID: <12265172.nXMDQmfcWu@thuis>

Sorry, I should have said these specs were intended for the few techies among us only. 
I can try to rephrase it in non-technical terms, but not before I get back from 
a conference trip. Alternatively what is in this document is a worked-out idea in
Section 9 of the previous document, which is (slightly) more readable.

If that makes any difference: the specs pertain to syntax, and not (very much) about
expressive power in terms of being able to encode certain groups.

Mark-Jan

On Friday 05 Aug 2016 09:03:48 Nigel Strudwick wrote:
> 1. Is it possible to have an explanation of this system not intended for specialists? I have tried to read these reports and I do not understand a word. Or were there some diagrams I have missed?
> 
> 2. I feel Ptolemaic hieroglyphs should be completely omitted from this system as they are a total "niche market?. As I recall in Cambridge, we agreed we would concentrate on the basic set of characters and minimise extensions to it. Do remember that the hieroglyphica extended set was only really developed for the IFAO producing typeset texts of Ptolemaic inscriptions.
> 
> Nigel
> 
> 
> On 5 Aug 2016, at 00:50, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk> wrote:
> 
> > On Thursday 04 Aug 2016 21:06:52 Serge Rosmorduc wrote:
> >> On a practical level, due to the size of the gap, it?s also the one where the lack of a proper mechanism hurts most. I guess using 
> >> PastedGraphic-4.pdf
> >> 
> >> instead of 
> >> PastedGraphic-5.pdf
> >> 
> >> does not hurt scholars sensitivity as much as 
> >> [...]
> > 
> > I see what you mean with 4 and 5.
> > 
> > But have you considered the raised arms (kA) ? Lots of groups can be put within the raised arms. 
> > If  a horizontal group, or even a vertical group is being inserted, and one wants to do this using
> > vertical grouping + JOIN, there is no guarantee the result will be close to what one expects
> > (the group being actually inside the bounding box of the raised arms). For me, it feels
> > right to fit the Hm sign inside kA using VERT+JOIN, which might well 'stick out' above.
> > But not say the 't', which one expects properly inside, and which moreover is being read 
> > phonetically after the kA (if that means anything).
> > 
> > This is why I think we should reconsider using insert-inside for such cases. Then also the cobra
> > could be seen in a new light.
> > 
> > For the syntax without brackets, see attachment. I'm not sure that for simple machinery this is any easier
> > to process than a bounded number of bracket nestings. Note there are 12 binding values hidden in this
> > model.
> > 
> > I have left open the exact notation for operator precedence. I see at least four possibilities, as listed in the
> > document.
> > 
> > Mark-Jan
> > <paper.pdf>_______________________________________________
> > Egyptian mailing list
> > Egyptian at evertype.com
> > http://evertype.com/mailman/listinfo/egyptian_evertype.com
> 
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com




From bobqq at live.co.uk  Fri Aug  5 12:04:30 2016
From: bobqq at live.co.uk (Bob Richmond)
Date: Fri, 5 Aug 2016 11:04:30 +0000
Subject: [Egyptian] Repeating operators
In-Reply-To: <12265172.nXMDQmfcWu@thuis>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <2049990.OxRmIQ1ydP@thuis>
 <A5E7F908-2EE3-4A91-A979-B49C7AEEFF21@cam.ac.uk>,<12265172.nXMDQmfcWu@thuis>
Message-ID: <HE1PR1001MB1067E239F519B7478FBFE6FE91180@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>

Hi Mark-Jan



Just to say I enjoy reading your papers. Even when I view the argument as a reductio ad absurdum. Or the tourist seeking their way to Dublin. However I?m also the kind of sad individual who sometime freeze-frames on the ?Big Bang Theory? to look for errors in the equations. Don?t tell anyone ??.



So I?d like to endorse Nigels plea for less technobabble. I fear some Egyptologists here have been somewhat blinded by ?science?.



Regards,

Bob











From: Mark-Jan Nederhof<mailto:mn31 at st-andrews.ac.uk>
Sent: 05 August 2016 09:29
To: egyptian at evertype.com<mailto:egyptian at evertype.com>
Subject: Re: [Egyptian] Repeating operators



Sorry, I should have said these specs were intended for the few techies among us only.
I can try to rephrase it in non-technical terms, but not before I get back from
a conference trip. Alternatively what is in this document is a worked-out idea in
Section 9 of the previous document, which is (slightly) more readable.

If that makes any difference: the specs pertain to syntax, and not (very much) about
expressive power in terms of being able to encode certain groups.

Mark-Jan

On Friday 05 Aug 2016 09:03:48 Nigel Strudwick wrote:
> 1. Is it possible to have an explanation of this system not intended for specialists? I have tried to read these reports and I do not understand a word. Or were there some diagrams I have missed?
>
> 2. I feel Ptolemaic hieroglyphs should be completely omitted from this system as they are a total "niche market?. As I recall in Cambridge, we agreed we would concentrate on the basic set of characters and minimise extensions to it. Do remember that the hieroglyphica extended set was only really developed for the IFAO producing typeset texts of Ptolemaic inscriptions.
>
> Nigel
>
>
> On 5 Aug 2016, at 00:50, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk> wrote:
>
> > On Thursday 04 Aug 2016 21:06:52 Serge Rosmorduc wrote:
> >> On a practical level, due to the size of the gap, it?s also the one where the lack of a proper mechanism hurts most. I guess using
> >> PastedGraphic-4.pdf
> >>
> >> instead of
> >> PastedGraphic-5.pdf
> >>
> >> does not hurt scholars sensitivity as much as
> >> [...]
> >
> > I see what you mean with 4 and 5.
> >
> > But have you considered the raised arms (kA) ? Lots of groups can be put within the raised arms.
> > If  a horizontal group, or even a vertical group is being inserted, and one wants to do this using
> > vertical grouping + JOIN, there is no guarantee the result will be close to what one expects
> > (the group being actually inside the bounding box of the raised arms). For me, it feels
> > right to fit the Hm sign inside kA using VERT+JOIN, which might well 'stick out' above.
> > But not say the 't', which one expects properly inside, and which moreover is being read
> > phonetically after the kA (if that means anything).
> >
> > This is why I think we should reconsider using insert-inside for such cases. Then also the cobra
> > could be seen in a new light.
> >
> > For the syntax without brackets, see attachment. I'm not sure that for simple machinery this is any easier
> > to process than a bounded number of bracket nestings. Note there are 12 binding values hidden in this
> > model.
> >
> > I have left open the exact notation for operator precedence. I see at least four possibilities, as listed in the
> > document.
> >
> > Mark-Jan
> > <paper.pdf>_______________________________________________
> > Egyptian mailing list
> > Egyptian at evertype.com
> > http://evertype.com/mailman/listinfo/egyptian_evertype.com
>
>
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com


_______________________________________________
Egyptian mailing list
Egyptian at evertype.com
http://evertype.com/mailman/listinfo/egyptian_evertype.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160805/52e1b71a/attachment.htm>

From ncs3 at cam.ac.uk  Fri Aug  5 12:12:53 2016
From: ncs3 at cam.ac.uk (Nigel Strudwick)
Date: Fri, 5 Aug 2016 12:12:53 +0100
Subject: [Egyptian] Repeating operators
In-Reply-To: <HE1PR1001MB1067E239F519B7478FBFE6FE91180@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <2049990.OxRmIQ1ydP@thuis> <A5E7F908-2EE3-4A91-A979-B49C7AEEFF21@cam.ac.uk>,
 <12265172.nXMDQmfcWu@thuis>
 <HE1PR1001MB1067E239F519B7478FBFE6FE91180@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <5F70BF03-A436-40AC-A4E9-56E04D6B8158@cam.ac.uk>

I certainly have been. Thanks Bob. I also cannot conceive of how these codes work in practice, since when I type (say) Option e e, I get ? which is a discrete character in a font and not a combination of two others.

I would be interested in comments on my somewhat less uninformed thoughts about Ptolemaic signs.

N



On 5 Aug 2016, at 12:04, Bob Richmond <bobqq at live.co.uk> wrote:

> Hi Mark-Jan
>  
> Just to say I enjoy reading your papers. Even when I view the argument as a reductio ad absurdum. Or the tourist seeking their way to Dublin. However I?m also the kind of sad individual who sometime freeze-frames on the ?Big Bang Theory? to look for errors in the equations. Don?t tell anyone ?.
>  
> So I?d like to endorse Nigels plea for less technobabble. I fear some Egyptologists here have been somewhat blinded by ?science?.
>  
> Regards,
> Bob
>  
>  
>  
>  
>  
> From: Mark-Jan Nederhof
> Sent: 05 August 2016 09:29
> To: egyptian at evertype.com
> Subject: Re: [Egyptian] Repeating operators
>  
> Sorry, I should have said these specs were intended for the few techies among us only. 
> I can try to rephrase it in non-technical terms, but not before I get back from 
> a conference trip. Alternatively what is in this document is a worked-out idea in
> Section 9 of the previous document, which is (slightly) more readable.
> 
> If that makes any difference: the specs pertain to syntax, and not (very much) about
> expressive power in terms of being able to encode certain groups.
> 
> Mark-Jan
> 
> On Friday 05 Aug 2016 09:03:48 Nigel Strudwick wrote:
> > 1. Is it possible to have an explanation of this system not intended for specialists? I have tried to read these reports and I do not understand a word. Or were there some diagrams I have missed?
> > 
> > 2. I feel Ptolemaic hieroglyphs should be completely omitted from this system as they are a total "niche market?. As I recall in Cambridge, we agreed we would concentrate on the basic set of characters and minimise extensions to it. Do remember that the hieroglyphica extended set was only really developed for the IFAO producing typeset texts of Ptolemaic inscriptions.
> > 
> > Nigel
> > 
> > 
> > On 5 Aug 2016, at 00:50, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk> wrote:
> > 
> > > On Thursday 04 Aug 2016 21:06:52 Serge Rosmorduc wrote:
> > >> On a practical level, due to the size of the gap, it?s also the one where the lack of a proper mechanism hurts most. I guess using 
> > >> PastedGraphic-4.pdf
> > >> 
> > >> instead of 
> > >> PastedGraphic-5.pdf
> > >> 
> > >> does not hurt scholars sensitivity as much as 
> > >> [...]
> > > 
> > > I see what you mean with 4 and 5.
> > > 
> > > But have you considered the raised arms (kA) ? Lots of groups can be put within the raised arms. 
> > > If  a horizontal group, or even a vertical group is being inserted, and one wants to do this using
> > > vertical grouping + JOIN, there is no guarantee the result will be close to what one expects
> > > (the group being actually inside the bounding box of the raised arms). For me, it feels
> > > right to fit the Hm sign inside kA using VERT+JOIN, which might well 'stick out' above.
> > > But not say the 't', which one expects properly inside, and which moreover is being read 
> > > phonetically after the kA (if that means anything).
> > > 
> > > This is why I think we should reconsider using insert-inside for such cases. Then also the cobra
> > > could be seen in a new light.
> > > 
> > > For the syntax without brackets, see attachment. I'm not sure that for simple machinery this is any easier
> > > to process than a bounded number of bracket nestings. Note there are 12 binding values hidden in this
> > > model.
> > > 
> > > I have left open the exact notation for operator precedence. I see at least four possibilities, as listed in the
> > > document.
> > > 
> > > Mark-Jan
> > > <paper.pdf>_______________________________________________
> > > Egyptian mailing list
> > > Egyptian at evertype.com
> > > http://evertype.com/mailman/listinfo/egyptian_evertype.com
> > 
> > 
> > _______________________________________________
> > Egyptian mailing list
> > Egyptian at evertype.com
> > http://evertype.com/mailman/listinfo/egyptian_evertype.com
> 
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com




From bobqq at live.co.uk  Fri Aug  5 16:31:08 2016
From: bobqq at live.co.uk (Bob Richmond)
Date: Fri, 5 Aug 2016 15:31:08 +0000
Subject: [Egyptian] About the 'repeating operators' and group joiners
Message-ID: <HE1PR1001MB10676B545CF5475B1AD578C791180@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>

Hi All

I don?t think anyone else picked this up on ?repeating operators? Plus a little more explanation about the joining model attached.

Bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160805/c3e448cb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TwoByTwo-2016-08-05.pdf
Type: application/pdf
Size: 506750 bytes
Desc: TwoByTwo-2016-08-05.pdf
URL: <http://evertype.com/pipermail/egyptian_evertype.com/attachments/20160805/c3e448cb/attachment.pdf>

From john.baines at orinst.ox.ac.uk  Sat Aug  6 12:04:14 2016
From: john.baines at orinst.ox.ac.uk (John Baines)
Date: Sat, 6 Aug 2016 11:04:14 +0000
Subject: [Egyptian] Repeating operators
In-Reply-To: <5F70BF03-A436-40AC-A4E9-56E04D6B8158@cam.ac.uk>
References: <mailman.5.1470071730.2186.egyptian_evertype.com@evertype.com>
 <2049990.OxRmIQ1ydP@thuis> <A5E7F908-2EE3-4A91-A979-B49C7AEEFF21@cam.ac.uk>,
 <12265172.nXMDQmfcWu@thuis>
 <HE1PR1001MB1067E239F519B7478FBFE6FE91180@HE1PR1001MB1067.EURPRD10.PROD.OUTLOOK.COM>
 <5F70BF03-A436-40AC-A4E9-56E04D6B8158@cam.ac.uk>
Message-ID: <DAF9EB1313DB2A488DFAB320E63F97ED1693B2DB@MBX02.ad.oak.ox.ac.uk>

I haven't commented on this thread before because I am ignorant of the technical issues. 

I think it will be wise to allow in overall plans for any extra complications that may be posed by Graeco-Roman period hieroglyphic texts. At a guess they make up perhaps a fifth to a quarter of total published hieroglyphic texts (probably more of those published in typeset hieroglyphs). At present they have fewer specialists than people who work on earlier periods, but that could always change, and the period has a wider range of interested parties (classicists, ancient historians, etc.). Probably they do not go far beyond Ramessid monumental inscriptions in the ways in which they stack and combine signs, but of course their sign repertory (which I take not to be the main point here) is much larger.

John


-----Original Message-----
From: Egyptian [mailto:egyptian-bounces at evertype.com] On Behalf Of Nigel Strudwick
Sent: 05 August 2016 12:13
To: Egyptian Hieroglyphs in the UCS <egyptian at evertype.com>
Subject: Re: [Egyptian] Repeating operators

I certainly have been. Thanks Bob. I also cannot conceive of how these codes work in practice, since when I type (say) Option e e, I get ? which is a discrete character in a font and not a combination of two others.

I would be interested in comments on my somewhat less uninformed thoughts about Ptolemaic signs.

N



On 5 Aug 2016, at 12:04, Bob Richmond <bobqq at live.co.uk> wrote:

> Hi Mark-Jan
>  
> Just to say I enjoy reading your papers. Even when I view the argument as a reductio ad absurdum. Or the tourist seeking their way to Dublin. However I?m also the kind of sad individual who sometime freeze-frames on the ?Big Bang Theory? to look for errors in the equations. Don?t tell anyone ?.
>  
> So I?d like to endorse Nigels plea for less technobabble. I fear some Egyptologists here have been somewhat blinded by ?science?.
>  
> Regards,
> Bob
>  
>  
>  
>  
>  
> From: Mark-Jan Nederhof
> Sent: 05 August 2016 09:29
> To: egyptian at evertype.com
> Subject: Re: [Egyptian] Repeating operators
>  
> Sorry, I should have said these specs were intended for the few techies among us only. 
> I can try to rephrase it in non-technical terms, but not before I get 
> back from a conference trip. Alternatively what is in this document is 
> a worked-out idea in Section 9 of the previous document, which is (slightly) more readable.
> 
> If that makes any difference: the specs pertain to syntax, and not 
> (very much) about expressive power in terms of being able to encode certain groups.
> 
> Mark-Jan
> 
> On Friday 05 Aug 2016 09:03:48 Nigel Strudwick wrote:
> > 1. Is it possible to have an explanation of this system not intended for specialists? I have tried to read these reports and I do not understand a word. Or were there some diagrams I have missed?
> > 
> > 2. I feel Ptolemaic hieroglyphs should be completely omitted from this system as they are a total "niche market?. As I recall in Cambridge, we agreed we would concentrate on the basic set of characters and minimise extensions to it. Do remember that the hieroglyphica extended set was only really developed for the IFAO producing typeset texts of Ptolemaic inscriptions.
> > 
> > Nigel
> > 
> > 
> > On 5 Aug 2016, at 00:50, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk> wrote:
> > 
> > > On Thursday 04 Aug 2016 21:06:52 Serge Rosmorduc wrote:
> > >> On a practical level, due to the size of the gap, it?s also the 
> > >> one where the lack of a proper mechanism hurts most. I guess 
> > >> using PastedGraphic-4.pdf
> > >> 
> > >> instead of
> > >> PastedGraphic-5.pdf
> > >> 
> > >> does not hurt scholars sensitivity as much as [...]
> > > 
> > > I see what you mean with 4 and 5.
> > > 
> > > But have you considered the raised arms (kA) ? Lots of groups can be put within the raised arms. 
> > > If  a horizontal group, or even a vertical group is being 
> > > inserted, and one wants to do this using vertical grouping + JOIN, 
> > > there is no guarantee the result will be close to what one expects 
> > > (the group being actually inside the bounding box of the raised arms). For me, it feels right to fit the Hm sign inside kA using VERT+JOIN, which might well 'stick out' above.
> > > But not say the 't', which one expects properly inside, and which 
> > > moreover is being read phonetically after the kA (if that means anything).
> > > 
> > > This is why I think we should reconsider using insert-inside for 
> > > such cases. Then also the cobra could be seen in a new light.
> > > 
> > > For the syntax without brackets, see attachment. I'm not sure that 
> > > for simple machinery this is any easier to process than a bounded 
> > > number of bracket nestings. Note there are 12 binding values hidden in this model.
> > > 
> > > I have left open the exact notation for operator precedence. I see 
> > > at least four possibilities, as listed in the document.
> > > 
> > > Mark-Jan
> > > <paper.pdf>_______________________________________________
> > > Egyptian mailing list
> > > Egyptian at evertype.com
> > > http://evertype.com/mailman/listinfo/egyptian_evertype.com
> > 
> > 
> > _______________________________________________
> > Egyptian mailing list
> > Egyptian at evertype.com
> > http://evertype.com/mailman/listinfo/egyptian_evertype.com
> 
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com


_______________________________________________
Egyptian mailing list
Egyptian at evertype.com
http://evertype.com/mailman/listinfo/egyptian_evertype.com