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.

There are really two bugs:

Due to an old bug in linux versions of openoffice (http://www.openoffice.org/issues/show_bug.cgi?id=66718) the system I have created for JSesh 2.11.5 won't function on linux. It's fixed in 2.11.6.

The system doesn't function with Openoffice 3.1.1 on Mac OS X neither. For now, you should use Neooffice instead.

I discovered a second bug, but linked to a very particular case (beta version of Openoffice 3.1 on Ubuntu).
There's a bug in one beta version of Openoffice 3.1 for Ubuntu, which seems to have a different idea of EMF files size than JSesh. So when pasting text from JSesh in ubuntu's openoffice, the EMF picture doesn't appear. In fact, the picture is there, but is too large (well in fact, the version I tested seems to have problems with EMF files it created, so this is really a bug).The official openoffice 3.1 from http://www.openoffice.org works just fine, so it might be a bug in the Ubuntu version. The "normal" 3.0 version distributed with Ubuntu has no problem.

I have accidentally used features of java 1.6 in the latest version of JSesh. Mac OS X tiger (and of course leopard) doesn't support this version of Java. I will fix it, but let's say that it's a bit difficult to remain polite considering Apple's policy for java version. Java 1.5 could still be installed on Windows 98... Java 1.6 can't run on a two years-old Mac.