[Egyptian] Consensus and Compromise on controls - discussion document

[Simon Schweitzer]

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
>