There is a bug in the latest version of Java on the mac, which cause problems when one wants to select
a folder in JSesh (for instance for hieroglyphic fonts).

The folder selector doesn't allow to select a folder, if java is java 1.7: http://bugs.sun.com/view_bug.do?bug_id=7161437

(Short history: java used to be adapted by Apple for the Mac. Now, Oracle does the work, and apparently did not integrate all the code provided by Apple, so we lose functionalities).

It seems that, even though some version of Java 1.7 integrate a bug fix, the official line by Oracle does not.

I do hope they won't behave in the same way for Mac Look and feel in general. So, I did write a bug fix, which should appear in a future version of JSesh (say, JSesh 6.4).

JSesh 5.7 (probably from a version or two) doesn't record correctly the graphical format (WMF, EMF, MacPict) chosen for RTF export preferences.

So, when starting JSesh, the previous choice is not remembered. The bug has been identified and will be fixed in the next version
(mea culpa, it is due to the use of copy/paste from the line which read another preference).

MdC code like
m##//

won't render correctly in PDF output, with "gray" shading (you should get a shaded owl, and you get a gray square).

This code is made with a owl sign, with a shading sign from the "shading symbol" menu over it.

The problem is that in the PDF output, I avoid transparency (for preserving CMYK colours), and the gray square is drawn over the owl.

Note that the other shading systems, quadrant based or sign based, don't have this problem.

I will fix this problem when possible.

There is a bug in PDF copy/paste. Apparently, some dimensions are not right (mainly when cartouches are involved). This bug is at least as old as JSesh 5.4. (it doesn't appear in normal PDF export from the file menu).

I'm going to find the source of the problem (I suspect that the correct dimensions are not sent to the clipboard). I take advantage of this occasion to remind users that "strange" behaviour of JSesh can be a bug, and I need to know that there is a bug to correct it :-)

It's not a real bug with JSesh, but the latest versions of Word on the Mac no longer understand when a mix of texts and drawings is copied to them (technically, they only take the text part when you perform RTF copy/paste operations). This behaviour is not only specific of JSesh.

The problem is of course that the default way for JSesh of performing copy/paste is by using RTF. This simply won't work (unless microsoft does something about it).

When a line number contains a '-' , for instance "3-4" JSesh currently produces the following code:
|3-4-...
which is wrongly interpreted when the text is reread.

Hence, we need to produce some non-standard code, like |3\-4- ... and read it.

In the "Drawing preference" tab (at least), the value of the last edited field is ignored.

This should be corrected in the next version.

After using "&" to ligature two elements, the caret is placed *one* quadrant after the new ligature (instead of just after the ligature).

Solved In 5.1 and later

Pictures copied from JSesh in "wysiwyg" mode, and pasted into openoffice, don't contain the correct information for pasting them back in JSesh. In fact, they are always in Pict format.

Version 2.10.5 has a problem when ran with old versions of Mac OS X (10.2). Download version 2.10.6 to solve the problem.

I won't make it a regular distribution until I have had some reports. Other users: the only change is that some files are ignored by Mac OS if Mac OS is too old to understand them. Anyone who doesn't use MacOS or has at least tiger doesn't need this distribution.