Bugs in JSesh, corrected or not

PDF export problem (not copy/paste)

When using export as pdf, some latin text (accented text mainly) does not appear correctly.
The problem does not show with quick pdf export or copy/paste (but in fact, the text is rendered as drawing in those cases, so it's not that significant.)

I'll try to see if it's a problem with Itext or with the way I use it.

It seems to be because the font used does not have the said characters, so I need to use the user-selected font in latin pdf output.

Temporary Workaround

Bug in the palette

In recent versions of JSesh, when a sign is selected in the palette by using a "phonetic" code, the software freezes when one clicks on the hieroglyph in the palette in order to insert it in JSesh.

This bug is probably quite old (as old as JSesh 6.2.0 probably). Again, don't hesitate to signal me bugs you find in the software.

Please, be accurate : a bug I can easily reproduce is probably a dead bug. So : instead of telling me
* "JSesh crashes on my new computer"

tell me :

* "When I type S42 and then "n" in the palette and select the water-sign, everything freezes."

(It's not a reproach, just a guide to speed up things. In real life, I got first the first report, then the second. And I would not have got the second without the first, so better a bad report than no report at all).

Because I can't do much about the first report (I don't have *your* computer in front of me, but, with the second description, I can try, and finally understand that the problem occurs when a) typing phonetic code in the palette and b) inserting them in the text.

Temporary Workaround

avoid using phonetic codes in the palette ? (or await the bug fix, next week).

(Solved in 6.3.3)

Bug in java 1.7 on the mac

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).

Temporary Workaround

(probably solved... If you meet the bug with JSesh 6.3.3 or later, please tell me). However, the folder selector is ugly.
Meanwhile, you can select a file instead of the folder, and then remove the file name.

Graphical format in RTF export preferences is not correctly recorded

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).

Temporary Workaround

get JSesh 5.8.

PDF output problem for a very specific case of shading

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.

Temporary Workaround

Solved in version 5.7 for free groups, which were the actual problem pointed out to me: shading is always placed below the rest (forgot to test it for m##//).

A possible solution is to draw the shading first, like this : //##m, or to use other kinds of shadings (the quadrant shading and the "sign" menu shading work fine).

PDF copy/paste size bug

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 :-)

Temporary Workaround

Use normal PDF export if you need PDF. The bug should be fixed in the next version.
Solved in 5.6/5.7

Copy/Paste bug with Word on Mac

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).

Temporary Workaround

Select "PDF" as your copy/paste format. it works.

problem with '-' in line numbers

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.

Temporary Workaround

For users, a possible temporary solution now would be to use some alternate character, for instance "EM DASH" — (unicode character 2014). Those characters are usually available through some kind of character palette on your system (well, I know for sure there is one on linux and on Mac).

Bug in Preference panel

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

This should be corrected in the next version.

Temporary Workaround

Simply click in any other field after making a change and before clicking "ok".

Caret placement after a ligature

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

Temporary Workaround

not a show-stopper. Simply move the caret.