Can't use japanese character.

[hibiarata]

In the view layout window, Japanese is not displayed collectly. all character are replaced ?.

1. Please check DbSchema Help / Output logs for errors.

2. Please include the DbSchema version, operating system and used database 8.2.7

3. The steps to reproduce this issue

[wise-coders]

Hello, Could you please add a screenshot of the layout window ? I am not sure if this is the diagram or a the layout dialog. I tried to reproduce this with the diagram and it works fine for me.

[hibiarata]

In the Sample SQL Editor.

[wise-coders]

Thank you for the pictures. I think we have few issues here:

1. the InvokereHelper error is because of issues with Java. I think the installer is grabbing the wrong Java. DbSchema already include its own Java, therefore is the best if you can download the kits from today from website. The dmg, exe or sh are the including the OpenJdk 13. Please let me know if using one of this solves this issue.

2. From the second picture, I see some table written in Japanese is not recognized. Can you please check the SQL query on the left, in the SQL History pane, is the name correct there ?

We have open a similar issue with typing Korean characters in the SQL editors. By them is so that pressing multiple keys on the keyboard will produce a single character, and this has issues in DbSchema. Is maybe the same issue with Japanese ? We are working on this.

[wise-coders]

We have more tests with Japanese text. I think the error is because of issues with Java. Please download the actual DbSchema 8.2.9 from website, preferrable an exe, dmg or sh kit ( it has OpenJdk 13 included ). Then look in Help / About dialog. Is the Java version indicated there the one from the DbSchema installation folder ? Here a screenshot of our latest tests:

[335]

Thank you for the pictures. I think we have few issues here:

1. the InvokereHelper error is because of issues with Java. I think the installer is grabbing the wrong Java. DbSchema already include its own Java, therefore is the best if you can download the kits from today from website. The dmg, exe or sh are the including the OpenJdk 13. Please let me know if using one of this solves this issue.
2. From the second picture, I see some table written in Japanese is not recognized. Can you please check the SQL query on the left, in the SQL History pane, is the name correct there ?

We have open a similar issue with typing Korean characters in the SQL editors. By them is so that pressing multiple keys on the keyboard will produce a single character, and this has issues in DbSchema. Is maybe the same issue with Japanese ? We are working on this.

A few months ago I reported that there was a problem with the Korean input method of the SQL editor. This problem seems to be about normalization handling. Check out the sample code below.

import java.text.Normalizer;

public class NormalizerTest {  
    private void printIt(String string) {
        System.out.println(string);
        for (int i = 0; i < string.length(); i++) {
            System.out.print(String.format("U+%04X ", string.codePointAt(i)));
        }
        System.out.println();
    }

    @Test
    public void test() {
        String han = "한";
        printIt(han);

        String nfd = Normalizer.normalize(han, Normalizer.Form.NFD);
        printIt(nfd);

        String nfc = Normalizer.normalize(nfd, Normalizer.Form.NFC);
        printIt(nfc);
    }

}

Results

한

U+D55C

ㅎㅏㄴ

U+1112 U+1161 U+11AB

한

U+D55C

[dprutean]

Thank you very much for your feedback. We have to say that is great if you can help us to debug this issue, as we may miss knowledge in the text normalization area. The SQL Editor is implemented by ourself, therefore we may do something wrong with the text. The issue can be generated by two different aspects:

1. We do something wrong when we read the keyboard event. You can verify this by saving the DbSchema model file, then open it with Notepad++ or similar and look if the text is fine. I add also the code we use to process KeyTyped events at the bottom. It would be great if you can test this, as our tests by adding a keyboard layout to the standard EN or DE layout are working fine. Right now we do not use

2. We do something wrong when we display the text on the screen. We use a Canvas and the GraphicContext for this. I paste here the code we use for this. Maybe we should switch to string.codePointAt(i) instead of charAt(i) ? I am not sure if we need Normalization at all. If you think this is correct, we can create a beta version in 1 day, so we can test.

   for (int i = 0; i < textLine.length(); i++) {
   char ch = textLine.charAt(i);
   graphicContext.fillText( "" + ch, x, y );
   }

private void processKeyTyped(KeyEvent event ){
if ( noControlKeys.and(e -> isLegal(e.getCharacter())).test( event )){
         if ( noControlKeys.
                and(e -> isLegal(e.getCharacter())).
                and(e -> !Character.isSupplementaryCodePoint( e.getCode().getCode())).
                test( event )){
            insertCharIntoBuffer( event.getCharacter());
        }
}

 private static boolean isLegal(String text) {
        int n = text.length();
        for(int i = 0; i < n; ++i) {
            if(Character.isISOControl(text.charAt(i))) {
                return false;
            }
        }
        return true;
    }

    private final Predicate<KeyEvent> noControlKeys = e ->
            // filter out control keys
            (!e.isControlDown() && !e.isMetaDown())
                    // except on Windows allow the Ctrl+Alt combination (produced by AltGr)
                    || (isWindows && !e.isMetaDown() && e.isAltDown());

[dprutean]

We created today a version where we use textLine.getCodePointAt(i) instead of .charAt(i). Here the download link: https://dbschema.com/beta.php It would be great if you can write back if this works fine for you. Please test also typing text. We tried also to test, but for some reason, I think some of them are working fine for us but not for you.