Dokuwiki EBook

Foreword

You are currently using JSesh, which is both an editor for hieroglyphic texts and a toolset for manipulating hieroglyphic texts in Java. As a user, you are probably more interested in JSesh editing and printing capabilities.

JSesh covers most of the Manuel de Codage and can read files coming from a number of other softwares, as Winglyph and Tksesh. Macscribe compatibility has not been tested, and is probably not full.

The manuel de codage[1] is a standard which was created in 1984 for describing hieroglyphic texts in ASCII. It's a bit old by now, and there are various suggestions to improve it (or replace it). JSesh will propose a number of extensions. JSesh also allows you to edit hieroglyphic texts, either by typing manuel de codage codes, or by a more intuitive menu system. Some manuel de codage features are not available yet through the menus, but you have always the possibility of writing the code directly.

JSesh has a number of output capabilities. It can print a file, or save it in various interesting graphic formats : pdf, jpg, or even as set of html files. Among the possible outputs, one must note the WMF (windows metafiles output). Metafiles are vector images, which means they are well suited for printing. WMF files can be read by almost all word processors.

JSesh, contrarily to tksesh, is not primarily a text database. The text database capabilities of tksesh will be added to JSesh in the future, but I thought it would be better to provide a nice editor/displayer first, in order to involve people.

Overview of the JSesh Window

(pre-5.4 version)

Currently, JSesh's working space contains a menu, a main editing window (the “hieroglyphic window” above), and a number of fields. The field termed “Manuel de Codage field” contains the Manuel de codage code for the current line of text (the one pointed by the cursor). You can modify directly this code ; the field termed “current sign code” is used in interractive editing to show the code for the currently edited text. the field directly right to it is a message field. It isn't of much use currently.

Editing texts

Mouse Editing[2]

Keyboard Editing[3]

Direct Manuel de Codage Entry[4]

Glossary Editor[5]

Specific Editing Problems[6]

Mouse Editing

Editing with the mouse is a very simple, but slow process. Usually, you will mix it with one of the two others.

Setting a cursor position

To set the current cursor position, simply click on the hieroglyphic panel.

Inserting signs with menus and palette

The faster way to insert signs is to use the keyboard [the section called “Keyboard editing”], and type either manuel de codage codes or translitteration. However, it is possible to select the signs from either a menu or from the sign palette

The Sign Button

The sign button only list the basic signs, from the usual Gardiner categories (with the extra category Ff for signs taken from hieratic. This category was used in the original Gardiner fonts). The sign button is placed in the lower part of JSesh windows.

The Sign Palette

The sign palette was created to propose a better solution than the menu. It can display all available signs without any problem, and it features advance search options.

To open the sign palette, use the menu Tools/Hide Show Hieroglyphic Palette.

The basic usage of the palette is quite simple: you select the family of signs you are interested in (using the dropdown list (b)), and then you double click on the sign you want to insert in the panel (e).

Not all signs are displayed (normally, the palette doesn't display variant signs). To display all signs from a family, check the “show all” box (h). If you click only once on a sign, the sign will be selected.Information about the sign (its code, its values, etc.) will be displayed in the panel (i). More information will be available if you select the “Sign Description” tab (a).

Please note that most information in JSesh in here for searching purposes. In particular, details about what the values means are not fully displayed. For instance, we use “bin” as a value for G37, but only because it is a convenient mnemonic. In reality, the internal format of JSesh allows to store more information about what the values are. Another example is Y1; for this one, we will keep the “sS” mnemonic, and add the probably better “sXA”. More scientific information on the sign will belong to the “Sign Description” (which is quite empty right now).

Advanced controls

b The “family selector” holds two special families: “user palette” and “last used signs”. See below for more information on user palette. “Last used signs” contains all signs selected by the user in the palette during this session. It's supposed to be usefull if the same signs appears often.

c The “sub family” control allows to restrict the listing to the signs which share certain characteristics. For instance, if you have selected the “God” family, you can restrict the search to “hawk-headed” gods.

d the translitteration filter allows to look for signs using their translitteration. The translitteration used may be the phonetic value of a sign (for phonograms and ideograms), or may be a value typical of a word the sign appear in. If you check the “show all” box, all values known to JSesh will be used (TO BE COMPLETED).

f User palette selector. If you check this box, the currently selected sign will be added to the user palette.

g If you click on the “part of” button, Jsesh will display all signs that contain the currently selected sign (well, if he knows). in the future, it may use the “select all” box to choose how far to go. Each further click will extend the set of displayed signs (the next one will list parts, and parts of parts, etc.)

j select known variants of the current sign. The term “variant” is here used quite loosely. It may be real linguistic variants (as Z7 is a variant of G43, for instance), or it may means “signs which are graphically based on another one”. For instance, A17A is a variant of A17 in this meaning, even if its linguistic uses are quite different. Each further click will extend the set. A second click would add variant of variants, etc…

User palette

The user palette allows a user to compose his own list of prefered signs. Adding a sign in the palette is simple: you simply select the sign, and check the “user palette control” (f) in the bottom part of the palette. The content of the user palette is automatically saved, so you will get your palette back next time you start JSesh. Removing a sign from the palette is as simple as selecting it and unchecking the “user palette” control.

All signs selected for inclusion in the user palette will be displayed when the “user palette” special family is selected.

You can help

You will find a description of the files used by the palette as an appendix to this documentation. If you have a good knowledge of hieroglyphs, you can help improving JSesh by extending the informations it uses. Mail the author (serge.rosmorduc AT qenherkhopeshef.org) for more information.

Selecting a zone

The selection stands between the cursor, and what is called the mark. The whole selection is drawn in light blue. Some operations are possible only if a zone of text is selected.

To select a zone of text, you can use a number of ways :

Mac style : shift-click on a point in the text ; the whole text between this point and the cursor will be selected ;

Unix style : same, but using right-mouse button. This might change one day if I decide to use contextual menus.

keyboard selection : shift + left or right arrow selects and move.

mouse dragging

Adding a sign chosen from a menu

The hieroglyphs menu gives access to the signs of the standard Gardiner list. Simply select a sign, and it will be added at the cursor position.

Grouping signs

This is done using the “Text manipulation” menu. You can group signs into vertical or horizontal groups, by selecting the signs (or quadrants), and choosing either “group horizontal” or “group vertical”. Note that you can break the groups with the menu “explode group”. All kinds of groups can be “exploded”.

“Group Horizontal” has the keyboard shortcut “Ctrl-h”

“Group Vertical” has the keyboard shortcut “Ctrl-g”

Ligatures

JSesh knows a number of “special groups”, or ligatures, which are beyond the capabilities of “square” quadrants. For instance, “w” and “t” will likely be arrange like that: . To achieve such a layout, select the signs you want to ligature, and use the menu Text manipulation/Ligature elements.

However, JSesh doesn't know how to ligature all groups, even though it knows some rather “sportive” ones: ligaturing gives .

Complex ligatures

Some ligatures can be considered as the ligature of a sign and a group.

Let's consider the group . It can be understood as a ligature between the sign and the group . Such ligatures can be built with the menus Text manipulation/Ligature group with hieroglyph or Text manipulation/Ligature hieroglyph with group. In the first case, the group is “in front” of the hieroglyph, in the second case (which corresponds to our example, the hieroglyph stands “in front of” the group.

For each sign, JSesh tries to find two areas. One for “front” ligatures, and one for “back” ligatures. Some sign have their “ligature area” already set. For other signs, it is computed automatically. To tell the whole truth, JSesh tries to see if it can fit a rectangle in the bottom-left area of signs (for left-to-right orientation). This area would be the “start” area. For the “end” area, two places are examined. First, the top-right corner of the signs (like in the ligature, and then a large area in the bottom left, like in the case. Signs creator can provide other areas, like in .

Please note that a sign can be ligatured at the same time with a group before it and with a group after it.

Editing groups

When you meet a very specific group, one-of-a-kind type, in which you want to place the signs exactly where you want, you can select the edit group menu entry. The edited group will be either the selected group, if there is a selection (overlined in blue), or the last group before the cursor, if there is no selection.

It will open the following window :

You will be able to move the signs, to scale them, and to rotate them. Note that scaling and rotations are triggered by two buttons. To move a sign, click on it and drag it where you want. To rotate or scale it, click and drag one of the small red boxes around the currently selected sign.

Keyboard Editing

Entering hieroglyphs

To enter signs with the keyboard, click in the main window (the one that displays the actual hieroglyphic text, not in the one with the so-called “Manuel de codage”). When you type a letter or a number in the main window, this letter or number appears in the small panel in the bottom left panel of JSesh. This allows you to type “Manuel de Codage” codes.

Lots of signs have phonetic codes, which correspond to their translitteration;

all signs are accessible through their code in Gardiner's grammar. To find the code, you can look at the “hieroglyphs” menus.

Once the code is typed, you must validate it. To validate, type one of space, ':', '*', '-', enter

The sign will be added to the hieroglyphic text.

Phonetic codes can correspond to more than one sign. For instance, iw corresponds to one of ,, , and . The “official” sign for iw is according to the manuel . However, you might want another sign. In this case, it's quite simple : press the space bar, and the system will circle through the possibilities, one at a time.

Your last choice will be retained the next time you type the code in this session.

Phonetic codes

The uniliteral signs have the following codes, which are also used when typing transliteration:

Code | Letter
A | ꜣ (aleph)
i | i҆ (yod)
y | y
a | ꜥ (ayin)
w | w
b | b
p | p
f | f
m | m 
n | n
r | r
l | l
h | h
H | ḥ
x | ḫ
X | ẖ
z | z
s | s
S | s
q | ḳ
k | k
g | g
t | t
T | ṯ
d | d
D | ḏ

W is also used for Z7, M for Aa15, and N for S3.

Grouping signs

The sign you type when validating can be used to group the hieroglyphs. Both 'space' and '-' have the simple effect that the next sign will be added in a new cadrat.

':' and '*' will add the next sign respectively below and besides the last sign entered.

'enter' has two consequences : it validates a sign (if there is one), and it adds a new line.

If no code has been entered (that is, if the code window is entered), the previous grouping sign type will group the last two cadrats. It looks a bit strange, but you will see that it's quite natural. you can use it to group signs as an afterthough.

Exempli gratia

If you want to type the word , you can :

type 'p', then '*', 't', ':', 'pt'

type 'p', 't', then , space (which, in sort, validates the ), pt, ':', and space.

Direct manuel de codage entry

When a text is displayed, the manuel de codage codes for the current line are shown in a text field

This field is not here just for the sake of the Manuel beauty. In fact, you can edit its content, and the text in the hieroglyphic window will be modified accordingly when you validate (by typing the Enter key). Note that incorrect Manuel de codage code will be refused.

Glossary Editor

The glossary editor allows you to create precomposed groups (even words or sentences) and retrieve them easily for quick typing.

Suppose you would like to be able to type the article pꜣ in its hieratic form, which is G41-A1, simply by typing “pA”. Here is what you need to do: type the text for the group you want. select it, and call “Edit/Add Selection to glossary”

the glossary editor window opens, and all you need to do is to type the code you want to use, and then push the “add” button.

as soon as the group has been added, you can insert it by typing its code, just like you type the code of a sign. In this precise case, as we used “pA” as code, and “pA” allows to type G41 and G40, the space bar will allow you to cycle through all solutions.

Complements

you can remove entries by clicking the “remove” button which follows them in the glossary editor.

you can open or close the glossary editor by using the “Window/Glossary” menu entry.

Specific editing problems

Shading/Hatching

Shading/Hatching

Shading/Hatching is currently a bit complex. The bad news is that it will become worse.

As an option (look at File/Document properties), shading can be either the classical “cross-line shading” you can see in old publications, or a light gray background. Although many users prefer the first one out of tradition, the second is indeed typographically superior. Cross-line shading makes signs difficult to read, which is not the case of the light gray background.

Shading comes in a number of flavors. This is due to the Manuel de Codage's history.

A good summary is available in the JSesh sample document (the one which appeareared when you started JSesh, and which is now included in the JSesh text library (in the next version, that is)).

But, to tell the whole story:

Originally, there where two shading systems. The first one shaded a whole part of a text. It's the shading you get when you ask “shade zone”. In JSesh, it works on the selected text.

The second shading system used shading symbols, used exactly as hieroglyphs. In the original manual, cadrats where shaded by overwriting them with the corresponding shading symbols. You get them from the “shading symbol” menu entry. Thus, ﻿ can be obtained by typing “wn”, then adding a shading symbol, and stacking both verticaly. JSesh understands this kind of shading since the beginning, but a menu to use is was only made available in version 2.10.

then, around 1994, a new shading system was proposed, which covered most simple cases. It's the one you get with the “Shading” menu. It applies to the current group (the group in front of the cursor), and can be used to shade any quarter of a group.

MacScribe is able to shade quarter of individual signs. In MacScribe, “p##13*p:pt” would have the “p” sign half shaded. A variant of this system is understood by JSesh. The external MacScribe converter[7] software understands this.

A “free” shading system would be nice too. In this case, the outline of the shaded zone would be freely drawn. I plan to add it too (taking advantage of the group editor). But currently, if you need to be that precise, the only option JSesh gives you is to export your file in some convenient format (for instance SVG) and to modify it there.

Shading part of a quadrant

The menu entry in Text Manipulation/Shading can apply to a selection. That is, you can shade the top part of all groups in a selection in one operation (previously, you had to shade each group individually).

More, for people who type texts with lots of lacunas, I have added a popup menu. If you press the ”#” key on your keyboard, this menu will appear. You can navigate in it with the keyboard or select entries by a specific letter.

Here is an example. I have selected a part of the text and pressed ”#”. The popup

Now I can select the shading I need by various means (it depends on your computer system). For instance, I can type “3”, move in the menu with the keyboard arrows or select the menu item with the mouse. Then, the whole selected text is shaded:

Current options to do some tricky shading

If you want, for instance, to add a shaded zone over the middle of a sign, you can now do it. In fact, it's the reason why I added a menu to retrieve the “old” shading symbols. Let's say you want to create . You first need to enter both signs. The shading is added through the menus :

Then, you simply need to use the group editor:

You should probably enter the shading symbol first, and then the glyph. This way, if your final output format doesn't understand transparency, you will still have a correct rendering.

(By the way, ecdotic marks like [ … ] are also glyphs. As such, they can be moved in the group editor).

Document presentation

JSesh allows you to make a number of choices about the way the document will be displayed. You can change line spacing, sign sizes, and so on.

From JSesh 5 onward, most display information are saved with each document. Changing them will only modify the currently edited text.

Document preference

New document preferences

Copy/Paste[8]

Printing[9]

Exporting PDF[10]

Exporting JPEG and PNG Pictures[11]

Exporting RTF[12]

Word processor specific issues[13]

As of version 5 and later, copy and paste can be used to transfer data between Jsesh and other applications. You can :

Copy/paste between different windows in JSesh itself.

Copy text and signs to a word processor (it works with both openoffice and Word)

Graphical copy and paste : configuration

Often, one needs two sizes of signs in an application: one for main text, and a smaller one for footnotes. JSesh allows one to keep two configurations for copy and paste. The current size can be selected in the edit menu : simply choose “copy: small size”, “copy: large size” or “copy: wysiwyg” (the latter should be used if you want the copied glyph to retain the same disposition as the original ones).

Format choice

A cut and paste involves two softwares : JSesh and your word processor (Word, Openoffice, etc.) Now, JSesh will propose a number of different *formats* to your word processor, letting it pick the one it likes the most. To control what will be proposed by JSesh, you can use the Format Choice dialog (in the preferences).

RTF : probably the most versatile choice for now. Works everywhere and give reasonable results, especially for hieroglyphs mixed with alphabetic text.

PDF : currently the most acurate choice. As far as I know, only Mac OS X supports PDF cut and paste, and few softwares understand it. For instance, Word 2004 doesn't. Word 2008 does, however. Textedit has the bad idea of accepting the PDF cut and paste, but transforming the result into a bitmap.

bitmap : gives a (currently) low resolution bitmap, suitable for web pages for instance.

plain text : will copy the Manuel de Codage encoding to the clipboard.

For information specific to your word processor, see the chapter on word processor issues[14]

Fine settings

The settings for “large size/small size/wysiwyg” can be changed in the preferences. There are two tabs, one for “small” and the other for “large” size. The “wysiwyg” mode uses the “large size settings”.

“Cadrat height” changes the size of the pasted hieroglyphic text. “Export mode” allows you to chose how hieroglyphic text will be pasted in RTF exports. There are three options:

as one large picture The whole selected text will be pasted in your word processor as a single picture. This is fine for text in columns, for instance, or if you want to keep the graphical layout. It also seems that most word processor prefer to handle large pictures than lots of small ones.

grouped cadrats Adjacent hieroglyphic cadrats will be grouped in one picture. The resulting text will alternate normal text and large pictures.

one picture per cadrat The pasted text will contain normal text and pictures for the hieroglyphic text. But then, each cadrat will be rendered as one picture. This is fine for line-cutting, and might be interesting if you mix text and hieroglyphs.

Cut and paste limitations

Due to technical issues, we have put a limit on cut and paste. It's not possible to paste very long texts in a word processor (you can “export as RTF instead”). We will try to improve it, but we think it's a minor nuisance, as one typically paste small parts of hieroglyphic texts rather than whole large document (the limit is currently 1000 cadrats).

Don't hesitate to write to the author at rosmord@iut.univ-paris8.fr[15] about this (or other problems with JSesh).

Advanced "copy" menu

Normally, in JSesh, you chose the format you want for copy/paste in the preferences menu. But in some cases, you might want to copy your text in a specific format which is not the one you chose. Instead of going back to the preferences, you can use the “Copy As” menu. It allows you to copy the selected text in PDF, RTF or Bitmap.

Possibility to paste hieroglyphic back text to JSesh

Principles and problems

(I'm sorry, this part is a bit technical. If someone is able to write the same explanations in a clearer way, it would be a welcome contribution to JSesh's site)

On windows (and on Mac OS prior to Mac OS X), there is a feature called “Object linking and embedding”, wich is more or less an intelligent cut and paste. You copy/paste a document from your hieroglyphic editor into Word, and then if you double click on the pasted picture, it will open the hieroglyphic editor, so that you can change the text.

This is not possible with JSesh, as this kind of capabilities are very system-specific (If you really need it, I understand that it's well supported in Inscribe). However version 2.11 of JSesh provides a poor man's version. Basically the trick (also used in a few other hieroglyphic editors, like MacScribe) is to use the comment field available in some picture formats (like PDF or EMF), and to put the manuel de codage text in this comment field. When the picture is pasted into JSesh, one can simply extract the code.

Of course, this is more or less automatic. But I needed to explain it, because it depends on a number of factors:

the picture format must support comments, and I need to write the corresponding code. This is currently done only for EMF and PDF.

the word processor must accept the pasted picture “as is”, and not modify it. Modifications usually suppress the comment. For instance, on a Mac, you can paste a PDF picture in MS/Word 2008. But Word

will (I guess) transform the picture into its own format, and lose the comment in the process.

All those explanations to tell you that this system won't function with all word processors… and especially not with MS/Word (at least not with Word 2008 on a mac). I'm sorry for that.

Now for the possible solutions

Mellel/Nissus writer and PDF

If you use Mellel or Nissus writer, and if you configure your cut and paste option to use the PDF format ), you will be able to paste back your hieroglyphs into JSesh.

Simply select the hieroglyphs in your text processor (e.g. Mellel) and copy them…

Then go to JSesh, and select File/Import/Import from Pasted PDF.

The result will replace your current JSesh document:

NeoOffice (Openoffice) and RTF text

This chapter describes manipulations made on a macintosh using Neooffice as word processor. It works also with Openoffice on Windows and Linux (but it seems to fail with Openoffice 3.1.1 on Mac).

If you configure your cut and paste option to use the RTF format and if you chose EMF as the picture format (see above), you will be able to paste back your hieroglyphs into JSesh.

First, you must select “EMF” as the copy format to use.

Text pasted in EMF in Neooffice can then be pasted back in JSesh:

Now, there is a little problem. We want Neooffice to send RTF text (with the picture embedded in it). This won't happen if you directly select the picture:

Note that in the “good” selection, the picture is outlined in black.

The direct selection of a picture will result in an (innocuitous) error message:

Now, the correct way to select the picture is to click in front of it in the text and to drag with the mouse. Alternatively (and with less dexterity), you can select the picture by moving the text cursor in front of it and then pressing “shift” and one of the keyboard arrows (it's way simpler to do it than to describe it).

Note that you can select more than one picture:

And you will get one line by picture in JSesh:

Please note that this only works if your pictures have been pasted from version 2.11 or more of JSesh, and in the correct format.

Others

I would be very interested to know if other configurations work

Printing

Currently, printing doesn't work, and is *not* a priority. Use PDF or SVG export instead, and print from Acrobat Reader or Inkscape.

Exporting PDF

To export your text as a PDF, choose export PDF. Explore the various renderings for best results. There might currently be problems with the latin and translitteration fonts.

Exporting as JPEG or PNG

Pictures on computers come in two flavours: *bitmaps* and *vector* pictures. For a quick idea of which is which, let's say that bitmaps are usually edited with softwares like photoshop (or gimp if you use free software), and vector pictures are edited using softwares like Adobe Illustrator (or Inkscape). Most softwares can display and read bitmaps, so they tend to be easier to share. Their main problem is that you can't zoom well on them. A bitmap fit for screen display will probably print poorly. However, sharing vector pictures is quite difficult (for no good reason, but it's a sorry state of affairs), so you might end up sending high-resolution bitmaps for printing.

To export a bitmap, choose the “File/Export As/Export as Bitmap” menu entry.

You can export a jpeg or png version of your text. If no text is selected, the whole text will be rendered. If there is a selection, only the selected text will be drawn.

Exporting RTF

RTF (Rich Text Format) is a portable document format that can be read by most word processors (for instance, MS/word and Openoffice).

To export an rtf text, choose the “File/Export/Export as RTF” menu entry.

Word processor specific issues

Alas, alas, alas, copy/paste and graphic embedding are much more complex than they should be, due to a generalized lack of cooperation between the main actors of the domain. Thus we discuss here the issues related to specific word processors (and similar softwares).

Format choices for Mac applications

As of today (july the 24th, 2009)

Apparently, Word 2011 for Mac doesn't accept copy/paste of RTF texts containing pictures (the “standard” way for JSesh to perform copy/paste). Hence, the only solution is to select PDF copy/paste. Go to the preference menu, select “clipboard preference”, and check “PDF” (and only PDF).

On word 2008, usable formats are RTF and PDF, PDF giving the best results. It seems that you can use “EMF” pictures in the RTF export. EMF gives much better results than Mac Pict.

On word 2004, only RTF is reasonable. It should be configured to use MacPict pictures

On Nissus and Mellel, one can use either PDF or RTF. As the PDF keeps its comments, it will be possible in the (near) future to cut and paste to and from JSesh. For RTF, you need to use MacPict as output format.

On Openoffice/NeoOffice, PDF doesn't work yet, so one needs to use RTF. The possible picture formats are MacPict (for maximal compatibility with word) and EMF (with better graphical results). Neoffice 3.1.1 seems to have a bug in EMF support. I stick to 3.0.2 for the moment.

Format choices for Windows applications

(to be completed)

Format choices for Linux applications

(to be completed)

Tips and tricks on hieroglyphic text encoding

Before describing the manuel de codage itself, I'd like to make a point or two about how one should encode a hieroglyphic text.

Typically, you have a source, which might be a) a printed source, with typeset hieroglyphs, b) a photograph or an acurate facsimile of the original text, or c) handwritten hieroglyph from an egyptological publication (for instance, the Urkunden).

You must decide how faithfull to the original you must be, and it's not a simple question. The first point is that you can be sure that your Manuel de Codage text can't be a facsimile, so, one way or another, it will betray the original. If the text is ultimately a hieratic text, you are already creating something completely different anyway.

Now, when you have a sign, should you look for the most precise variant for it, or use a somehow standardised one? To answer this, you should wonder if this variant is relevant, in the text, and in the use you intend to make of it. For instance, in the Kanaïs texts by Sethi the Ist, the first person pronoun uses many variants of A40 (). If you intend the ltext to be for grammatical study, it's not very relevant. If you wonder whether it's a free play to add diversity to the text, then you may take the time to encode the variants. As a rule, if you are a beginner in Egyptian, I'd advise you to encode the “standard” sign, as it will force you to read the text, not to copy signs. The problem you have when you want to be very accurate is that you will find many cases of variants which have no encoding anyway, and you take the chances to mislead your readers by giving a false impression of accuracy.

When your source is an handwritten version of a text, like in the Urkunden, beware of one point: unless a sign is very particular, an egyptologist will usually draw his glyphs in the easiest way. That means, for instance, he will use V23A () instead of (V22) which is the normal hieroglyphic sign. You must understand that, and when a sign selection is simply caused by the individual hand of the author, render it with the “standard” sign. On the other hand, when the author has drawn a very specific sign form, it might be worthwhile to give it more consideration.

Encoding hieratic texts

The above rule is even stronger for hieratic texts. There is no point in making a distinction between and , as both are rendered the same in hieratic!

Now, there are a number of peculiarities of hieratic which deserve more care. Those have been pinpointed by sir Alan Gardiner in his article “The Transcription of New Kingdom Hieratic”, JEA 15 (1929), p. 48-55. The rendering of hieratic texts should hint at the way the original signs are placed, in order to allow the reader to understand the reason for the rendering, and to go back to the original when necessary. JSesh includes a number of signs which are usefull for rendering hieratic texts:

Sign | Code | Use
| Ff1 | a sign particular to Ramesside texts, which serves as a kind of “wildcard”. this is different from sign Z5 (). You can get it in JSesh by typing ”,” (comma) and then the space key.
| Ff100 | a non-standard sign, “dot space filler”. Use it to render the various dots a scribe may use, when they are not a ponctuation.
| Ff101 | a non standard sign, horizontal space filler. Use it to render various meaningless horizontal sign the scribe may use to fill voids.

JSesh includes also specific signs for numbers in hieratic texts. In those texts, the “determinative” Z1 is often smaller than the “digit” Z1. Careless rendering might cause to be read hrw 3 whereas the original has , which is clearly hrw 2.

Sign layout

Use the various “ligature” capabilities of JSesh, and if everything else fails, go for the “group editor”.

A few interesting points:

In the group “M17-M17”, the signs should often be closer than the standard spacing of JSesh allows (actually, this is already stated by sir A. Gardiner in the catalogue of his fonts). If one writes i*i:k (that is, two yod grouped horizontally, and a “k” below them), the group JSesh creates is . To obtain the better layout: is simple: you only need to ligature the two yods (type “i” ”&” “i”, for instance).

Transliteration

Editing transliteration should be a simple affair. After all, it only use a few alphabetic signs. Alas, it isn't. In the MdC, a simple, ASCII-based standard was used. But this standard requires special fonts, where “a” are not “a” but “ayin”. This lead to many problem when texts where exchanged. Passing from Mac to PC was a real problem, and publishers were very unhappy. Hundreds of hours of unnecessary work was spent converting files - or re-typing them.

Normally, Unicode should solve all those problems¹⁾. So, currently, JSesh proposes choices to the user. Your personal choice will depend on what you want to do with your texts. It's quite likely that unicode is needed for most publications, for instance.

You can choose the way transliteration will be dealt with from the Preference menu.

Using a unicode font

To use a unicode font, you need to have a font with the correct signs. Currently, the possible free fonts are:

EgyptoSerif[16], my own transliteration font. The signs are not very good looking, but they are in the correct place.

Gentium Plus

New Athena Unicode (see the exact details)

You should open the “Preferences” menu (on the Mac, it's in the “JSesh” menu; elsewhere, it's under the “Edit Menu”).

Go to the “Font Preferences” Tab.

Select a font for transliteration

open the “advanced option”, and check “Unicode Transliteration fonts”

Current problems with unicode fonts

The current support in operating system and softwares for the transliteration fonts is not good. Even Java on the Mac - and hence, JSesh - has problems.

The real problems are H̱ and yod

Capital H̱

On some systems, H̱ (as in the ram-god H̱nmw) displays poorly. It depends on the font and on the software and on the system. In most cases, it's ok. One annoying exception is that it doesn't give a good result with JSesh on Mac OS X. Apparently, the rendering system gives better results on Windows. Note that, if you paste your text in a word processor, you will probably get a good result anyway.

Yod

Unicode gives you a number of choices. I selected the two best solutions (the third one, using a kind of half circle of the yod accent, is simply reproducing a trick used when people had typewriters, and hand-made their yods with “c” letters). The problem is that, technically, the support for those solution is lacking.

The yod is supposed to be coded with a “i” (a dotted i, not a dotless one) and an accent. The font should contain enough information to display those signs correctly. The problem is that lots of softwares don't look at the font content, and work on their own. The result is that the dot is not removed on many system (including JSesh on the Mac). The positionning of the accent in front of the capital “I” is another problem.

With a correct configuration, it's possible to get good results with OpenOffice and Word.

The two possibilities for yod are

U+0313 As i + “comma above” is already used in other languages, its chances to be correctly supported are better. The only problem is that in the normal display of this combination for capital “I”, the accent is supposed to be above the I. As you know, the correct display for capital yod has the accent in front of the “I”. If you can live with that, this solution is the safest one. It gives good results in most cases (but not with Java and Mac OS X, so JSesh display on the Mac is not correct).

U+0486 this accent has the interesting feature of not being used for anything else on latin letters. So a font is free to place it in front of capital “I”. In theory, this is the good solution. In practice, it works with some, but not all, softwares. OpenOffice gives good results, and the plain TextEdit software on the Mac too. I could succeed with Word on the Mac by enabling all ligatures.

JSesh doesn't support the current IFAO/Unicode system. This standard was a temporary “patch” using available unicode signs, done when no encoding was available for Egyptian transliteration. Now that “Aleph” and “Ayin” have code, I want to encourage (well, enforce) their use.

References

* Wikipedia article on transliteration and unicode[17]

Not using unicode

You can select a font with a MdC-compatible encoding. In this case, JSesh does not deal with capital letters. You can choose your own font, if you have one, or use the default JSesh transliteration font. A version of this font is embedded in the software, but you can install it on your system (to use with a word processor, for instance). A copy of this font is available in the font folder of JSesh installation.

Easy way with the old font

You should open the “Preferences” menu (on the Mac, it's in the “JSesh” menu; elsewhere, it's under the “Edit Menu”). Go to the “Font Preferences” Tab, and click the “use old transliteration font” button.

That's it. For your own Word (or OpenOffice…) documents, you can find the font in the JSesh application folder (in the “font” folder).

Using your own MdC-compatible fonts

If you have a font compatible with the MdC (that is, the “a” represents an ayn, the “A” represents an aleph, etc…), you can use it too.

Simply select your font (using “Choose font” in front of the Transliteration font), and then, in the advanced options, select “MdC (non Unicode) Transliteration font”.

¹⁾ as I have written elsewhere, I feel that Unicode for Hieroglyphs is a whole different business

JSesh Menus Explanation

Menus

- Application menu (mac only)[18]

- File[19]

- Edit[20]

- Group[21]

- Sign[22]

- Windows[23]

- Base Hieroglyphs[24]

Extending the sign list

Introduction

From version 2.0beta onward, users of JSesh can create their own signs. A sign editor and an elaborate database system are planned in the future, but, on a more practical sign, it was decided to allow one to import signs created with various softwares.

So : a) JSesh has currently no sign editor but b) JSesh can import signs from :

true type fonts (see fontforge for a free editor) ;

SVG files : SVG is a relatively recent format for vector graphics. It's very powerfull and complete. Currently, JSesh understands SVG files if the sign is drawn in black over white. You can edit SVG files with a number of programs; one of the best free ones is Inkscape, which has the advantage of being multi-platform.

For compatibility with my previous software (tksesh), it can also read:

font files exported from tksesh (.tml files)

font files from the GNU font utils (.bzr files). Both types of files can be edited with the fontedit software, included in tksesh. But this is of little interest for the generic user.

Content

Importing new glyphs[25]

Creating a sign with Inkscape[26]

Advanced Informations in Inkscape[27]

Parts of SVG understood by JSesh[28]

Creating a sign with Inkscape

Introduction

JSesh doesn't include a hieroglyphic editor yet. However, it can include signs drawn with a number of other softwares, like fontforge and inkscape. Even if a sign editor is added, this functionality will be kept.

In this tutorial, I show how to use the Inkscape software to create a new hieroglyph.

Drawing a new sign is a rather long and tedious task. It requires a basic understanding of vector graphics (Inkscape, adobe illustrator…), which is not trivial, and it also requires a lot of work anyway. Not only should you draw nice signs, but those signs should blend with the other fonts.

A few notions about vector drawing

Drawing vectorial pictures requires some understanding of what it's all about. We will write something about it later (except if some kind soul can contribute a nice free-of-right tutorial). Requirement for JSesh-usable signs : you should draw your signs as black filled contours on a white background. The JSesh import module can read non filled contours, but the import will give better results with filled contours with zero width. Inkscape is able to convert curves into contours, so it's not a very heavy requirement.

Creating a background image

You can start by getting a picture of the glyph you want to create. This picture might be a line-drawing, or a photograph from an actual glyph. You want the black lines of your sign to be readable, so change the colors if needed (for instance, if you have a line drawing of the sign, color it in light gray). Our example will be a low resolution rendering of sign C102 (seated Ptah with wꜣs) from Israel stela. The original bitmap is . With a drawing program, we have dimmed the picture to get

Draw the outline

We now start Inkscape, and import the bitmap drawing in it. Create a new layer, call it “work”. That way, we won't disturb the bitmap drawing. We are then going to draw a rough outline of the sign's shape. As we are not great drawers, we use the “Bezier curve” tool to do it. We get the following result:

Note that we have selected “no fill” and a small contour width. We have also left the “Was” sign alone.

Fit the outline

Straight line segments won't make a great sign. So we convert some of them to curve, we add new points if needed, etc… We start with the head…

And here is the result:

Working on details

We want our signs to be readable at small size, so we won't fill to much details.

Ptah's beard

The outline of Ptah's body will be enlarged to make the final sign. But we would like the beard to be filled¹⁾. Hence, we must separate it from the rest of the drawing. This is done by selecting the control points which separate the beard from the body:

And then selecting the “Break apart” entry in the “Path” menu, which gives us two objects : the beard and the rest of the body. We can then fill the gap we have just created (and give Ptah a chin .

Now, the beard should also be closed. We edit the fill and stroke characteristics of the beard, and we give it a solid black filling, and no stroke. If the beard is too thin, we will be able to dilate it with the “outset” action of the path menu.

Ptah's necklace counterpoise

For this one, the original scan is a bit rough. We dig some iconography, and we come with a two parts necklace counterpoise.

The necklace is made of two parts: a string, and the counterpoise itself. The string is a simple curved stroke, and the counterpoise is a filled path.

We want to join them into one object, which will be a filled path. To do this, we first convert the string into a stroke.

We then select the two parts of the necklace, and use the “union” operator in the “path” menu.

Choosing the right line width

At this stage, you might want to save your work twice. Once as a backup, and, one, of course, as your working file. Now, select the main drawing, and choose a reasonable stroke width for it. It should mix well with the rest of the fonts. It might be interesting to zoom out in order to see the sign as it will be rendered.

Uniting everything

Now, get sure all strokes are transformed to path, and use the union operator on them. You should get:

I strongly suggest you keep a backup version of your sign in which strokes are not tranformed to path, it will allow you to rework your sign more easily, or to reuse it as part of other signs. That's what I do for my Ramesside fonts.

Adding other details

Using the same techniques, we get to the final result:

which we save under the name C102.svg .

Final comments

From a rather low resolution picture, we can get a decent-looking glyph. Remember that the sign will be rather small, and don't add too many details (giving the possibility to increase the sign's details with its size is an interesting option, which is used in the Gardiner's lead fonts). Try to mix with the existing signs.In fact, if you have SVG sources for similar signs, try to reuse them.

The sign given in this example is not too good an example. The “Wꜣs”, for one, is too high, and the sign won't mix well with the existing fonts. So we should make the scepter shorter. In general, our Ptah is too lean compared with the other signs. Keeping intermediate stages of your work will allow you to correct things more easily. For instance, if the strokes are too fat, if you have kept a version of the sign where the strokes are still strokes, and have not yet been replaced by paths, the correction is very easy.

¹⁾ in this case, we gave Ptah an osirian beard, which is an error

Advanced Informations in Inkscape

Introduction

JSesh has now a relatively advanced ligature mechanism, which is not as good as the one in RES, but give reasonnable results in most cases. In many cases, JSesh is able to “guess” where ligatured groups should fit, but it can also do with some extra help. This help can be provided in the sign's SVG file itself, and we decided to use the mechanisms of inkscape for that.

Ligature zones

For each sign, JSesh will try to compute two ligature zones, one for ligatures of groups before the sign, the other for ligatures of groups after the sign. Those zones can be computed automatically, but the sign author can also provide them.

to create one of the two ligature zones in inkscape, do the following:

create a rectangle where the group should fit. Note that the whole group will be scaled to fit there, so draw it large enough. I usually draw these rectangles in red, but it's only a convention.

open the contextual menu for the rectangle (right-click over the rectangle), and select object properties . You will get the object properties window ( Figure “Zone Properties” below.) Define the Id as either “zone1” or “zone2”. Don't forget to click on the Define button to validate your modification. Also clear the label (more on this in the section called “Ligature zones gravity” ).

Admitedly, we are using the id and label information in a way they are not supposed to be used. The reason for this is purely pragmatic. It's far easier to do things that way, as the sign creator has no need to know about the inner organization of the XML format.

Ligature zones gravity

The ligatured group will go somewhere in the ligature zone. But where exactly ? It can stand in the middle of the area, or stick to one of its sides. In fact, the behaviour of the layout algorithm is not always the same. In , the “w” tends to fit on the bottom left of the rectangular area. In , the U36 sign is more or less centered, both horizontally and vertically. JSesh allows signs authors to design the behaviour of “ligature zones”, in the following way. Remember the label of the previous paragraph? You can set it to

gravity: gravity specifications.

where gravity specifications can contain

“s” or “e” to ask the group to stick to the start side or to the end side of the zone¹⁾. If neither “s” nor “e” is specified, the group will be horizontally centered.

“t” or “b” to ask the group to stick to the top or bottom of the zone. If neither “t” nor “b” is specified, the group will be vertically centered.

“Zone Properties”, gravity:te means that the group which would be ligatured in zone1 (in front of the “child” sign) would stick to the top of the red rectangle, and stay near the sign, for instance .

¹⁾ start and end are taken from M.-J. Nederhof's RES, and avoid the use of “left” and “right”, which are not really usable for hieroglyphs!

Parts of SVG understood by JSesh

JSesh does not understand SVG fully.

@doc@en@introduction.html

[1] http://jseshdoc.qenherkhopeshef.org/doku.php?id=mdc

@doc@en@edition.html

[2] http://jseshdoc.qenherkhopeshef.org/doku.php?id=mouseediting
[3] http://jseshdoc.qenherkhopeshef.org/doku.php?id=keyboardediting
[4] http://jseshdoc.qenherkhopeshef.org/doku.php?id=mdcentry
[5] http://jseshdoc.qenherkhopeshef.org/doku.php?id=glossaryeditor
[6] http://jseshdoc.qenherkhopeshef.org/doku.php?id=specificproblems

@doc@en@specificproblems@shading.html

[7] http://jsesh.qenherkhopeshef.org/software/MacScribeImporter.zip

@doc@en@exports.html

[8] http://jseshdoc.qenherkhopeshef.org/doku.php?id=copy_paste
[9] http://jseshdoc.qenherkhopeshef.org/doku.php?id=printing
[10] http://jseshdoc.qenherkhopeshef.org/doku.php?id=export_pdf
[11] http://jseshdoc.qenherkhopeshef.org/doku.php?id=export_bitmap
[12] http://jseshdoc.qenherkhopeshef.org/doku.php?id=export_rtf
[13] http://jseshdoc.qenherkhopeshef.org/doku.php?id=word_processor_issues

@doc@en@copy_paste.html

[14] http://jseshdoc.qenherkhopeshef.org/doku.php?id=word_processor_issues
[15] mailto:rosmord@iut.univ-paris8.fr

@doc@en@transliteration.html

[16] http://jsesh.qenherkhopeshef.org/files_jsesh/JSeshFont.ttf
[17] http://en.wikipedia.org/wiki/Transliteration_of_Ancient_Egyptian

@doc@en@menus.html

[18] http://jseshdoc.qenherkhopeshef.org/doku.php?id=doc:en:menus:application
[19] http://jseshdoc.qenherkhopeshef.org/doku.php?id=doc:en:menus:file
[20] http://jseshdoc.qenherkhopeshef.org/doku.php?id=doc:en:menus:edit
[21] http://jseshdoc.qenherkhopeshef.org/doku.php?id=doc:en:menus:group
[22] http://jseshdoc.qenherkhopeshef.org/doku.php?id=doc:en:menus:sign
[23] http://jseshdoc.qenherkhopeshef.org/doku.php?id=doc:en:menus:windows
[24] http://jseshdoc.qenherkhopeshef.org/doku.php?id=doc:en:menus:hieroglyphs

@doc@en@newSigns.html

[25] http://jseshdoc.qenherkhopeshef.org/doku.php?id=importingglyphs
[26] http://jseshdoc.qenherkhopeshef.org/doku.php?id=inkscape
[27] http://jseshdoc.qenherkhopeshef.org/doku.php?id=inkspapeadvanced
[28] http://jseshdoc.qenherkhopeshef.org/doku.php?id=svg