Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-4963

Non ASCII characters not displayed correctly

    • Icon: Bug Report Bug Report
    • Resolution: Won't Fix
    • Icon: L3 - Default L3 - Default
    • 7.4.x
    • 7.4.0-alpha2
    • cockpit, dmn-ui
    • None

      My DMN decision table uses German umlauts in it's label, e.g. like this:
      <input id="Bedingung_1" label="Länge">
      Rule file attached.

      In Camunda Cockpit this label is not displayed correctly as the column header of the condition. It is displayed correctly when looking at the instance values.
      See attached screenshot.

        This is the controller panel for Smart Panels app

          1. camunda_cockpit_dmn.png
            camunda_cockpit_dmn.png
            122 kB
          2. DT_neu_40000.dmn11.xml
            58 kB
          3. screenshot-2.png
            screenshot-2.png
            85 kB

            [CAM-4963] Non ASCII characters not displayed correctly

            Frank Langelage created issue -
            Frank Langelage made changes -
            Attachment New: screenshot-2.png [ 21062 ]

            Using "Navigate to deployment" the umlauts in the column headers are displayed correctly.

            Frank Langelage added a comment - Using "Navigate to deployment" the umlauts in the column headers are displayed correctly.
            Robert Gimbel made changes -
            Fix Version/s New: 7.4.0 [ 13505 ]
            Robert Gimbel made changes -
            Assignee New: Sebastian Menski [ sebastian.menski ]

            Hi langfr,

            how did you create the DMN table? Did you manually edited it or used the modeler at http://camunda.org/dmn/demo-stage?

            Cheers,
            Sebastian

            Sebastian Menski added a comment - Hi langfr , how did you create the DMN table? Did you manually edited it or used the modeler at http://camunda.org/dmn/demo-stage? Cheers, Sebastian
            Thorben Lindhauer made changes -
            Comment [ Hi Frank,

            How did you deploy the model? As part of a process application deployment, via REST or Java API? If via Java API, which code did you use?

            Cheers,
            Thorben ]

            The XML file attached was created by another application.
            The file is read into an byte[] fileContent and then deployed using the Java-API:

                    DeploymentBuilder deploymentBuilder = this.repositoryService.createDeployment();
                    deploymentBuilder.enableDuplicateFiltering( true );
                    deploymentBuilder.addInputStream( fileName, new ByteArrayInputStream( fileContent ) );
                    deploymentBuilder.name( fileName );
                    Deployment deployment = deploymentBuilder.deploy();
            

            But as the umlauts are there on different views in camunda cockpit (lower part of screenshot 1 and screenshot 2) it cannot be a problem of deploying.

            Frank Langelage added a comment - The XML file attached was created by another application. The file is read into an byte[] fileContent and then deployed using the Java-API: DeploymentBuilder deploymentBuilder = this .repositoryService.createDeployment(); deploymentBuilder.enableDuplicateFiltering( true ); deploymentBuilder.addInputStream( fileName, new ByteArrayInputStream( fileContent ) ); deploymentBuilder.name( fileName ); Deployment deployment = deploymentBuilder.deploy(); But as the umlauts are there on different views in camunda cockpit (lower part of screenshot 1 and screenshot 2) it cannot be a problem of deploying.

            Hi sebastian.stamm and roman.smirnov,

            does anybody know a reason why we should get the DMN XML encapsulated in a JSON object in the history view? If not I would propose a binary endpoint for the decision definition xml like the binary data endpoint for deployment resources. This way the encoding would be preserved.

            Cheers,
            Sebastian

            Sebastian Menski added a comment - Hi sebastian.stamm and roman.smirnov , does anybody know a reason why we should get the DMN XML encapsulated in a JSON object in the history view? If not I would propose a binary endpoint for the decision definition xml like the binary data endpoint for deployment resources. This way the encoding would be preserved. Cheers, Sebastian

            I do not see a reason why we would need it wrapped in JSON. When we introduce a binary data endpoint to retrieve the XML, we should do this for the process definition, too (I assume we have a similar problem there).

            Sebastian Stamm added a comment - I do not see a reason why we would need it wrapped in JSON. When we introduce a binary data endpoint to retrieve the XML, we should do this for the process definition, too (I assume we have a similar problem there).

              Unassigned Unassigned
              langfr Frank Langelage
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: