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]

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[7]

Printing[8]

Exporting PDF[9]

Exporting JPEG and PNG Pictures[10]

Exporting RTF[11]

Word processor specific issues[12]

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[13], 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[14]

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)[15]

- File[16]

- Edit[17]

- Group[18]

- Sign[19]

- Windows[20]

- Base Hieroglyphs[21]

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[22]

Creating a sign with Inkscape[23]

Advanced Informations in Inkscape[24]

Parts of SVG understood by JSesh[25]

@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@exports.html

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

@doc@en@transliteration.html

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

@doc@en@menus.html

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

@doc@en@newSigns.html

[22] http://jseshdoc.qenherkhopeshef.org/doku.php?id=importingglyphs
[23] http://jseshdoc.qenherkhopeshef.org/doku.php?id=inkscape
[24] http://jseshdoc.qenherkhopeshef.org/doku.php?id=inkspapeadvanced
[25] http://jseshdoc.qenherkhopeshef.org/doku.php?id=svg