«

On Sunday, July 22, 2012 11:31:04 AM UTC-7, markspace wrote:
> On 7/22/2012 10:37 AM, Philip Brown wrote:
>
> > step 1: copy (jre)/lib/fontconfig.properties.src to
> > fontconfig.properties step 2: modify the line
> >
> > sequence.allfonts=alphabetic/default,dingbats,symbol
> >
> > to be sequence.allfonts=alphabetic/default,dingbats,symbol,japanese
>
>
> Thanks for reporting your solution back to us, it helps out everyone.
> However I'm concerned that you may have, or have now, a defective
> installation. Here's my file; there's already a different line for
> Japanese script set. Is your file very different from mine?
>
>

I'm not sure what you mean by "japanese script set".
Please identify the specific line you mean.

If you mean, "Hey there are lines in here that reference japanese, so it should work already"..
well, yes, that was exactly my first impression, too! but I found it was neccessary to make the above tweak.

I'm going to reference my full source code in a followup post.

On 7/22/2012 10:37 AM, Philip Brown wrote:
>
> step 1: copy (jre)/lib/fontconfig.properties.src to

I found some more info, which I think I'll archive in this thread.

Some older documentation on the fontconfig.properties file:


http://docs.oracle.com/javase/1.5.0/...ontconfig.html


This software is referenced by the Java 7 release notes, apparently for
building fontconfig files.

http://www.freedesktop.org/wiki/Software/fontconfig

http://docs.oracle.com/javase/7/docs...cements70.html

On Sunday, July 22, 2012 10:37:13 AM UTC-7, Philip Brown wrote:
>
> Yeah, I figured.
> The good news is, I found a solution to get the JRE working properly in windows, so it can work as well as MacOS.
>
>

fyi, if anyone is curious as to what exactly my program is doing:

I thought I had lost the source code, which made me very sad but I found an ooold version of it.

For the terminally curious, I've made it available at

http://www.bolthole.com/jdrill/jdrill-2.0-src.tar.gz

Warning: It was written in 1999, and in AWT

It's rather long, so for anyone interested, I'll suggest that you look at the GamePanel class (which is the main window), and specifically the (Label) MAIN_B object, which is the object that initially comes up with a Kanji char in it.

It should be noted that it does "set a font"; however, it just grabs the generic "dialog" font. Paraphrasing the code a bit:
font = new Font("dialog", 0, 24);

This gets its label string set to a value cached from a
KanjiDicLine obj, either from obj.getEnglish or obj.getKanji

The Kanji object is a regular String object, populated by an operational chain that looks something like
BufferedReader(InputStreamReader(file, "EUCJIS")).readLine
->String ->StringBuffer ->char[] -> String
(mostly in parseKDLine(). which is used to parse a line from the dictionary file "KanjiDic", a small version of which is in the source code tarfile)

So basically, it is a raw unicode string.
Which is supposed to be handled by java transparently, I thought.

I set the Label's label to be a raw unicode string, and expect it to "do the right thing".

On MacOS, it does the right thing. On windows, it doesnt, unless I do that hack.



> step 1: copy (jre)/lib/fontconfig.properties.src to fontconfig.properties
> step 2: modify the line
>
> sequence.allfonts=alphabetic/default,dingbats,symbol
>
> to be
> sequence.allfonts=alphabetic/default,dingbats,symbol,japanese
>

Philip Brown wrote:
> Lew wrote:
>> Philip Brown wrote:
>> I'm hoping someone can tell me the magic to get java [sic] (6 or 7) to display unicode [sic] chars under ms-windows [sic]?
>>
>> This is really an OS question.
>>
>> Java will emit characters using the target OS's encoding by default.
>>
>> The fact is that Java is already displaying Unicode characters. However it is
>> Windows that is failing to render them.
>>
>> Do you set the encoding explicitly in your program.
>
> I think I did.

Then show us the line of code where you did.

You don't need to guess. Look at the code. You either will see an encoding
specified or you won't.

> If I didnt, wouldnt it fail under macos [sic]?

Not if the default encoding of the platform and available fonts just
coincidentally happen to be what you want.

> It works under macos [sic], as I said.

Yes, and that's not relevant.

> Similarly, if I failed to set the encoding properly... wouldnt it just display gibberish chars?

No. It will either display the characters that correspond according to its own
encoding, or the placeholder for characters that it doesn't recognize or for
which it doesn't have an appropriate font.

And what do you mean by "gibberish"?

> Instead, its displaying the old empty square "no font mapping for this char" glyph.

Eh, so absent your answer about what encoding you specified, I can only guess
that either the Windows encoding doesn't give you what you want, which
historically has been an issue with Windows but I don't know about your
version, or you don't have the fonts you need.

Since you won't confirm your encoding choices, or even show the code you
vaguely describe with respect to the fonts you select, it's a little difficult
to take the answer any further.

> Similarly.. when it attempts to display a char, it is displaying ONE empty-square.
> If the encoding was not set, it would display two empty chars, since it's displaying a 2-byte "widechar"

Maybe. Maybe not. It depends on what the default platform encoding is.

> Not to mention that the same program has worked under earlier versions of windows and jre.
> (And by "same program", I mean *same* program)

OK, whatever.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg