I'm trying to localize a Swing application with Hebrew punctuation
But Shva (U+05B0) is displayed wrong, should be displayed as:
System.out.println("\u05D9\u05B0\u05E6\u05B4\u05D9\u05D0\u05B8\u05D4");
Will print correctly the first letter with Shva punctuation:
יְצִיאָה
But when added to Swing application using messages.properties file
It display \u05B0 same as \u05B4 (HIRIQ)
יִצִיאָה
I tried other Unicode option but it didn't work, does anyone have a reason or is there a known limitation ?
It shows the as main menu option it looks OK, as a sub menu (can't enlarger component) it look wrong
Related
I'm trying to see if there is a difference between making the text you entering to be underlined or struck through and the text you already enter to make it this way.
I'm working with Java and HTML.
In the Android Studio I can see that the HTML being written to the JTextPane is something like this:
<body>
<strike></strike>
</body>
but trying to type an 'a', does not produce a struck through 'a' symbol.
However, trying to type 'a', select it and then make it a strikethrough works as expected.
I'm checking for the presence of the HTML.Tag.S style in the HTML in order to see if the strikethrough is present or not in addition to the <strike> tag.
Also, if I refresh the window the text appears as it should, i.e. struck.
Changing the style of the font to become 'bold' also works as expected from the first time regardless if I select the existing text or I select the 'bold' and start typing the text.
Does anyone have an idea where should I look?
I was doing some pdf text extractions.
I have attached screenshot of a scenario where i faced the problem.
Why the eclipse console failed to print the word "specification"?
Instead it is printed as "speci?cation".
I can see the characters overlapped.
But during debugging the code, the same text is shown without a "question mark".
Is there any way to print the same text to the console?
Please help.
The problem is the "fi" ligature ("overlapping letters") that is a single character in Unicode. In the debugging view the Windows methods for drawing text are used; these know about Unicode and can render the ligature correctly.
The console view uses a certain encoding. When used with Windows the default is "cp1252", Codepage 1252, or ISO 8859. These encodings do not know this specific letter and cannot print it, so the question mark is used as substitute.
You can set the encoding for Eclipse in general via Window > Preferences, General > Workspace, Text file encoding. While I think it is a good idea to use UTF-8 everywhere it may lead to problems with existing files.
You can set the encoding per project in the project properties, category Resource.
If you just want to set the encoding for the console view, the least immersive solution, it is not exactly intuitive. The console view encoding is a property of the runtime configuration you use for running your project. Run > Run Configurations..., your run configuration, Common.
When you use one of these methods to set the encoding to UTF-8 then the ligature will be printed correctly to the console view.
Of course the more general settings only have effect if not overwritten by more specific ones (Workspace, Project, Run Configuration).
I'm surely getting all the terminology wrong here, but the PDF is probably using a glyph for the "fi" combination that isn't part of the ASCII character set. Thus it renders in the console as "?". Notice in the middle part of the window that the "i" in "fi" is closer to the "f" than it would be if it were the ASCII sequence "f" followed by "i" and that the "i" is also missing the dot.
I've got an assignment in a class about user interfaces and usability testing. I have to do something that I'm sure I can figure out how to do programatically, but I have no experience with swing so I have no idea what components to use to do the job. My background is in C# so I'm fumbling at times trying to find the right component to use in NetBeans.
Based on the description below, can anybody recommend what kind of text field will do the job? I was thinking jFormattedTextField (based on the name) but I can't seem to figure it out.
Thanks
Submit a Java program that will run on the Linux installation in the general lab (EN-2036).
Provide the following functionality:
load the output of the last command (from a file) into a text viewing area that
allows the user to browse the data
bold all login names only (not the whole line)
bold all occurrences of a user-specified login name
bold all occurrences of a user-specified set of login names
Use JEditorPane or JTextpane, these allow you to add style to text inside them
Tutorial Link
This is similar to my own previous question, but that solution didn't work here.
As mentioned in the previous question, I'm working on a cross platform(Windows/Ubuntu) application that has to transliterate English into one of several official Indian languages. The application has a custom input method, and typing in English and pressing space will transliterate the typed text into the specific local language. Urdu is different from the others in being right to left, like Arabic/Hebrew.
I managed to find an open licensed Urdu font that has both English and Urdu glyphs, but when I type characters in English, nothing shows up.
I don't understand whether it's a font painting issue, or related to the input method. So far, if I disable the custom input method (InputMethod.dispatchEvent() ) for this language, I am able to see the English text (but of course no transliteration takes place).
My findings:
Change font to one of Windows' built in Arabic fonts - same result.
Instead of using ComponentOrientation to align text in the text field, I used setHorizontalAlignment for when the locale is Urdu. Same result.
Decompiled the JDK's default input method provider on Windows (sun.awt.windows.WInputMethod). Here I see the dispatchEvent() makes a native call to the OS for handling IME. I can't do that here.
Found a custom IM for Hebrew - my version of dispatchEvent() is essentially the same.
Stepped through code for JTextField in Eclipse - wasn't able to find anything in the AbstractDocument and subclasses. The AbstractDocument.insertUpdate() method checks for and updates bidirectional text input, but there wasn't anything else significant.
I'm unable to understand what happens after the dispatchEvent() call. The characters are being registered, i.e. the transliteration engine is able to detect the typed characters and process them, but they just don't show up on screen.
Workaround
If I let the text field's orientation be as it is for regular left to right languages, I can see the English text. However, this would not be acceptable to an Urdu speaking user.
Can someone point me in the right direction?
I set the locale to ur_IN.
Sadly, ur_IN is not among the supported locales; I only see en_IN and hi_IN. In the example cited, I used the following code to get the image below:
spinner.setLocale(new Locale("hi", "IN"));
I have a JTextArea which displays HTML of an Arabic web page. So it's essentially a mix of English and Arabic. In the JTextArea, with columns set to 30, certain text just disappears instead of wrapping properly. The weird thing is that if I copy the invisible text and paste it into Notepad, then I can see it in Notepad. If I change the number of columns to 40, everything displays fine. Any ideas?
See this screenshot of the problem:
Elie, thanks for the response. Not sure I explained the problem properly though. On the left in the screenshot is the JTextArea. On the right is the selection from the JTextArea pasted into Notepad. Does this make more sense now?
Is it the 30th character which is disappearing? It's possible due to the script that the JTextArea cannot render the Arabic characters properly. So it's counting the characters correctly, but doesn't realize that they take up more space. Support for such fonts is not great, so you may want to write a custom renderer for your JTextArea to deal with this (so you can manually take into account the proper amount of space required per character in Arabic and adjust the line wrap accordingly).