OK, seeing some odd behaviors on Window using Java/VTK 6.3 (but also with 8.1.2 as well).
Any thoughts on what is going on here?
VTK 8.1.2 doesn’t support unicode, so extended characters depend on your locale CODE_PAGE setting.
Have you tried the latest build of VTK from master? It uses utf-8 strings. Displaying text/labels has not been addressed yet; however, since it appears to be working on Mac/Linux, the changes might resolve your issue.
Sadly, we can’t run with the master because VTK (or should I say the JOGL library, I think) is horribly broken on Mac for the OpenGL2 pipeline code (at least with how we use it in our code), so we haven’t been able to test with anything beyond VTK 8.1.2.
I’m not sure what CODE_PAGE is - is that a build switch when compiling VTK? What are the possibilities?
Here’s some information on setting the code page on Windows. https://docs.microsoft.com/en-us/cpp/c-runtime-library/code-pages?view=vs-2019
You could try altering your code page to see whether it affects the output. Even if that works, this approach is flawed since it breaks on any machine with a different code page setting.
Another option is to build VTK with Freetype. I haven’t had success with this either due to problems with the search paths in CMake on Windows, but I understand there is a superbuild for Paraview which compiles properly. My preliminary investigations suggest that Freetype will render the correct characters provided the correct font file is provided.
Please detail the steps to reproduce this issue. It would make a good test case for the UTF-8 support in VTK 8.2+ Perhaps the fix can be back-ported later.
You could also try setting the ActiveCodePage property in the manifest file for VTK 8.1.2, if you’re using Windows 10 (1903)
See some recent discussion here What is state of the art: Unicode file names on Windows
@Gilthalas I’m going to ask again. Please outline the steps to recreate this bug. Otherwise it won’t get fixed.
I’ve been hard at work getting the build for vtk8.2 to work, which I am glad to say I have been successful at.
I am glad to report that it seems like the vtkPNGWriter flip problem has gone away, so that’s good!
The degree symbol still doesn’t render correctly in vtk 8.2. Are the utf-8 features only in the master branch? We still have some issues getting that to build, but now knowing what I do on how to build 8.2, I may be able to get master to compile.
My other concern was that the degree symbol may be deeper than vtk - it can clearly handle it on the Mac and on Linux, so I’m wondering what makes the Windows build not able to handle it.
More information as a I get it on using the master branch.
The utf-8 changes are only in the master branch but they affect file and path names, so that probably won’t help you. Are you using Windows 10? Did you try setting the code page to UTF-8 in the application manifest?
I’m also interested in rendering labels/text with extended characters which is the next step in the Unicode compliance fixes. I suspect the Linux/Mac builds are using a system API for the rendering which handles utf-8 text, whereas Windows does not so it requires explicit handling in VTK.
What I’m asking for is some simple steps to reproduce this problem; a few lines of code. I still have no clue what classes/methods you’re using.
Where is the caption text coming from? Is it a string literal in your code? Is it being typed into a dialog? Is it being read from a file?
It looks something like this:
String deg = String.valueOf(Character.toChars(0x00B0));
String captionLabel = String.format(fmt, lon / Math.PI * 180) + deg;
vtkCaptionActor2D caption = new OccludingCaptionActor(intersectPoint, null , smallBodyModel);
caption.SetCaption(captionLabel);
caption.BorderOff();
caption.SetAttachmentPoint(intersectPoint);
captionActors.add(caption);
Where the “deg” string contains the unicode for the degrees symbol. The text just doesn’t render at all (the degree symbol and the surrounding text) on Windows The line connecting the caption to the attachment point does render, however.
In Java a string takes a UTF-16 representation. Unfortunately that is most likely a little-endian, LE, form on Windows and a big-endian, BE, form on Linux/Mac; or vice versa. So the byte order is swapped.
The simple solution is to only pass UTF-8 bytes to VTK char* parameters. Try this
caption.SetCaption(captionLabel.getBytes(StandardCharsets.UTF_8));
Thanks! I will try that out when I get a chance - may not be for a few days though. Will let you know.
Actually you can’t pass a byte array to the SetCaption() method, so that won’t work either.
I’ve looked at the java wrapper code now and there is a bug converting a java String to C++ char* due to the JVM Charset.defaultCharset() setting. On Mac/Linux it defaults to UTF-8, whereas on Windows it depends on the locale. That is the reason you’re seeing correct rendering on Mac/Linux.
The conversion to UTF-8 needs to be handled explicity in VTK. I will push a MR for the fix to the master branch shortly.
Thanks! Looking forward to the merge request. Send a link to the MR when you have it - I may bring it into my forked version of 8.2 I have with some other changes.
No I never did - life got in the way of me working on this, and then before I knew it 9.0 was out the door - is the change in there as well?
I know the feeling. We live in a time of great upheaval. I believe the changes made it into VTK 9 @ben.boeckel?
It has the 9.0 tag, so it made it (I removed the milestone from MRs that didn’t make it a while ago because they kept showing up in my “find 9.0 MRs that aren’t actually there” script; most of those have links to the MR where they did land in 9.0).