JSesh sign placement

A technical note by Serge Rosmorduc About JSesh 6 sign placement is now available on the JSesh website via jsesh.qenherkhopeshef.org/en/node/3112. The document sketches some aspects of how JSesh organises hieroglyphs into clusters/quadrats for rendering. Some JSesh users may find this informative.

The note does not discuss when to use special features for sign placement so I'll give some practical guidance here.

In common with other first generation hieroglyphic editing software, the primary purpose of JSesh is to generate images of hieroglyphic text, typically for inclusion in word processing documents as illustrations. The JSesh sign placement extensions over basic MdC (Manuel de Codage) focus on this application. It is possible to get away with an inelegant or incorrect transcription so long as the image looks ok although hacking solutions can prove to be fools gold so avoid where at all possible.

A secondary, and increasingly useful, application is to use JSesh to encode hieroglyphic data in an MdC (Manuel de Codage) style format intended for processing in other software applications such as databases and other MdC-like editors. Here, elements of JSesh sign placement may be unsupported, irrelevant, or misleading. Incorrect or inefficient transcriptions are unacceptable.

This means the golden rule is to keep a JSesh encoding as simple as possible and only use the more complex features when essential.

For instance ntt is normally written MdC n:t*t. However technically it could be written in JSesh as n:(t*t) or n{{0,10,110}}**t{{0,800,98}}**t{{600,800,99}} even though these alternative forms make no apparent sense and should be avoided.

In order of complexity (least first) you should try to transcribe a quadrat using:

1. Regular '*' and ':' operators (preferred option).
2. Ligature system (if regular quadrat doesn't work)
3. Absolute positioning (only if all else fails, e.g. ligature doesn't work).

In some cases you may find a need for brackets. This is ok but keep usage to the minimum of what is essential.

When it seems absolute positioning is essential for a JSesh transcription, you may want to consider inserting MdC comments at the the top of the JSesh data file. For instance:

++JSESH6: anx\R30{{0,357,51}}**G5{{194,0,97}} is used because anx\R30^^^G5 renders the ankh too small.+s
++JSESH6: R7{{0,612,55}}**bA{{101,0,98}}**Z1{{953,69,79}} is used because R7^^^bA&&&Z1 default scaling of R7 is unsatisfactory (although R7\50^^^bA&&&Z1 is not bad). Note in some MdC systems R7&bA&Z1 looks fine.+s

I personally use this commenting approach with JSesh data so I know what to do if improvements appear in a later release of JSesh or I want to create generic MdC or Unicode data.

One pernicious use of absolute positioning I've observed is 'new signs from old'. For instance combine A50 ('noble') with S45 ('flagellum') instead of using the preformed A51 sign. Always use a preformed sign when available in the Hieroglyphica/JSesh set.

The current MdC analysis for Unicode Repertoire Extensions web app is not designed to process absolute positioning but provides an easy way to highlight absolutes and ligatures used in MdC-coded data. I find it useful to help spot JSesh transcription errors.

A related topic is conversion between Unicode and JSesh data. The most important consideration related to this process is that new Unicode fonts define sign placement in the font itself  (allowing the user to work in many generic applications from Word Processors to Web Browsers). Each font can take its own approach to sign placement. A topic I hope to return to fairly soon.

Bob Richmond