MIDP MIDlet: which characters are supported in the phone font?

[Jens]

Which unicode characters does a phone support? Is this defined
somewhere? Does a phone support pi and math symbols and arrows?

Jens Martin Schlatter

 

[Darryl L. Pierce]

Which unicode characters does a phone support? Is this defined
somewhere? Does a phone support pi and math symbols and arrows?

It supports whatever locale(s) are on the phone.

 

[owwtemdczruw]

What is a "locale" and in which locale is "pi"?

 

[Darryl L. Pierce]

What is a "locale" and in which locale is "pi"?

A locale is the region supported by the virtual machine, which will
include such things as the character set, money and date/time
formatting, etc.. I don't know which locale has "pi" in it.

 

[Michael Borgwardt]

A locale is the region supported by the virtual machine, which will
include such things as the character set, money and date/time
formatting, etc.. I don't know which locale has "pi" in it.

I don't think the locale is in any way relevant to the question.
The charset is used for converting between bytes and characters,
but it's not supposed to restrict which characters you can use.

What you need to display mathematical symbols is most importantly
a *font* that supports those symbols, and I'm pretty sure there
are very few (if any) mobile phones that have fonts which support
them.

 

[Darryl L. Pierce]

I don't think the locale is in any way relevant to the question.
The charset is used for converting between bytes and characters,
but it's not supposed to restrict which characters you can use.

What you need to display mathematical symbols is most importantly
a *font* that supports those symbols, and I'm pretty sure there
are very few (if any) mobile phones that have fonts which support
them.

In the US? Probably not. But, rest assured that in each country there
are phones available that support that country's displayable characters.

 

[Michael Borgwardt]

In the US? Probably not. But, rest assured that in each country there
are phones available that support that country's displayable characters.

What *are* a "country's displayable characters"? I don't think there is
a formal standard for that, and it's certainly not technically implemented
in the Locale class. It depends entirely on the font rendering subsystem.

 

[Darryl L. Pierce]

What *are* a "country's displayable characters"?

Take, for example, the font used to display Korean characters.

I don't think there is
a formal standard for that, and it's certainly not technically implemented
in the Locale class.

Who said anything about the Locale class?

 

[Michael Borgwardt]

Take, for example, the font used to display Korean characters.

And do what with it?

Who said anything about the Locale class?

What else did you mean when you said "It supports whatever locale(s)
are on the phone."?

 

[Darryl L. Pierce]

And do what with it?

It's an example of a displayable characters for a specific country's
language. Are you interested in information or argument?

What else did you mean when you said "It supports whatever locale(s)
are on the phone."?

Locale is not exclusive to the set of Java APIs. The word locale, as I
used it above, means "[a] geopolitical place or area, especially in the
context of configuring an operating system or application
program with its character sets, date and time formats,
currency formats etc." (dictionary.com)

An example of a local supported by a phone would be those phones
manufactured in Korea which have only Korean characters displayed by the
font set on the phone.

Do you understand now? If not, please feel free to ask questions.

 

[Michael Borgwardt]

It's an example of a displayable characters for a specific country's
language. Are you interested in information or argument?

No, I'm interested in giving a helpful answer to the specific question,
and I think your answer is more likely to confuse the original poster
than help him.

The key word you used was "font". The font is what determines which
characters can be displayed on a Java system. Not a "locale".

What else did you mean when you said "It supports whatever locale(s)
are on the phone."?

Locale is not exclusive to the set of Java APIs. The word locale, as I
used it above, means "[a] geopolitical place or area, especially in the
context of configuring an operating system or application
program with its character sets, date and time formats,
currency formats etc." (dictionary.com)

The Locale class is Java's implementation of that concept, and it has
nothing to do with "displayable characters". If you use the word to mean
something else on this NG, that's rather misleading.

An example of a local supported by a phone would be those phones
manufactured in Korea which have only Korean characters displayed by the
font set on the phone.

I rather doubt any of them do not also display latin letters.

Locales are not the key to answering the original poster's question.
Fonts are. Of course, the fonts available on a device will contain
some or all of the characters commonly used on the locales it supports,
but that's not really relevant in regard to mathematical symbols,
because most of them are not part of any natural language.

In fact, I very much doubt any java-enabled mobile phone out there
supports a wide range of mathematical symbols out of the box, since
they have to make the most of their limited memory. There may be
some that allow updating / changing the fonts.

 

[Darryl L. Pierce]

No, I'm interested in giving a helpful answer to the specific question,
and I think your answer is more likely to confuse the original poster
than help him.

Sorry, what exactly was confusing about what I replied with?

The key word you used was "font". The font is what determines which
characters can be displayed on a Java system. Not a "locale".

Sounds more like my answer confused *you*. The font used is determined
by the locale where the phone is meant to be used. A locale is a
location, and regarding a mobile it's a location where that phone is
meant to be used. You won't find a phone with Big5 or Traditional
Chinese being sold widely in the US because that would be the wrong
locale for using such a device....

Who said anything about the Locale class?

What else did you mean when you said "It supports whatever locale(s)
are on the phone."?

Locale is not exclusive to the set of Java APIs. The word locale, as I
used it above, means "[a] geopolitical place or area, especially in the
context of configuring an operating system or application
program with its character sets, date and time formats,
currency formats etc." (dictionary.com)

The Locale class is Java's implementation of that concept, and it has
nothing to do with "displayable characters". If you use the word to mean
something else on this NG, that's rather misleading.

Then perhaps, in future, you should devote just a *wee* bit of time to
the topic of the person's question. There is *no* Locale class in the
MIDP. And, I said nothing *about* the Locale class. I said:

"It supports whatever locale(s) are on the phone. "

In response to the original poster's question:

"Which unicode characters does a phone support? Is this defined
somewhere? Does a phone support pi and math symbols and arrows?"

And the answer was *very* clear. Nothing about classes not available on
mobile phones. I said that the characters displayed on the phone are
going to be for what ever locale the phone was made to support.

I rather doubt any of them do not also display latin letters.

Where did I say anything about Latin? Are you interested in an argument,
then? You seem to want to argue over some slight only you perceive here...

Locales are not the key to answering the original poster's question.
Fonts are. Of course, the fonts available on a device will contain
some or all of the characters commonly used on the locales it supports,

Oh, so now *you* are saying that the characters supported on the device
are based on the locale? But, before you said "[t]he font is what
determines which characters can be displayed on a Java system. Not a
'locale'" when *I* said it depends on the locale. So, which is it?

but that's not really relevant in regard to mathematical symbols,
because most of them are not part of any natural language.
So?

In fact, I very much doubt any java-enabled mobile phone out there
supports a wide range of mathematical symbols out of the box, since
they have to make the most of their limited memory.

Then you *might* want to spend a bit of time looking into the subject
matter before telling someone who's been in the Java mobile industry for
over 5 years what's what. Sound reasonable?

There may be
some that allow updating / changing the fonts.

Again, so? Rather than itching for a Usenet fight, why not look into the
subject matter or ask someone to clarify their posts rather than
unnecessarily posturing yourself like you've done in this thread?

 

[Michael Borgwardt]

Sounds more like my answer confused *you*.

Not, it seems very much to me like you are the one who is
confusing things.

The font used is determined
by the locale where the phone is meant to be used.

Not in a way that helps answering the OP's question. The phone's *maker*
determines the font that will be used. The locale is going to be his
most important consideration in that decision, but not the only one.
He'll want to choose a font that can display all the characters used in
that locale, but may not be able to - early mobile phones were too limited
in their display resolutions, memory and entry methods to display all the
characters used in Japanese, so they supported only the tiny subset of
syllabic characters. OTOH there will often be a number of characters added
that are not formally part of the "locale" but used anyway.

Therefore there *is no* direct, one-to-one mapping from "locale" to a
set of characters displayable by any or all phones meant for that
locale.

A locale is a
location, and regarding a mobile it's a location where that phone is
meant to be used. You won't find a phone with Big5 or Traditional
Chinese being sold widely in the US because that would be the wrong
locale for using such a device....

And what have *character encodings* to do with this debate?

Then perhaps, in future, you should devote just a *wee* bit of time to the
topic of the person's question. There is *no* Locale class in the MIDP.

Can you be sure the original poster is aware of that?

And,
I said nothing *about* the Locale class. I said:

"It supports whatever locale(s) are on the phone. "

In response to the original poster's question:

"Which unicode characters does a phone support? Is this defined
somewhere? Does a phone support pi and math symbols and arrows?"

And the answer was *very* clear.

It was useless and misleading.

Nothing about classes not available on
mobile phones. I said that the characters displayed on the phone are
going to be for what ever locale the phone was made to support.

Which is a truism and doesn't answer the question because neither
your notion of "locale" nor "be for" is defined formally in a way
that would yield the desired set of displayable characters.

Where did I say anything about Latin?

You said "phones [...] which have only Korean characters". Well, there
is no such beast. Because Korean phones also display non-Korean, e.g.
Latin characters.

Oh, so now *you* are saying that the characters supported on the device
are based on the locale?

"based on" is a very fuzzy non-technical expression, pretty useless when
seeking answers to clear-cut technical questions. That's why I'm *not*
saying that. And that's why I'm trying to avoid the word "locale",
becuase the way you're using it, it's equally fuzzy.

But, before you said "[t]he font is what
determines which characters can be displayed on a Java system. Not a
'locale'" when *I* said it depends on the locale. So, which is it?

Both. The characters displayable on a phone are determined unequivocally
by the font. If a character is not in the font, the phone cannot display
it, if it is in the font, the phone can display it. The font contains
any and all of the characters displayable by the phone.

The choice of font is *influenced* by the locale, but not determined
in an unequivocal way, especially since your concept of "locale" is
also fuzzy. Whatever a locale is, not all phones made for it have the
same set of displayable characters.

So?

The original poster asked specifically about mathematical symbols.

Then you *might* want to spend a bit of time looking into the subject
matter before telling someone who's been in the Java mobile industry for
over 5 years what's what. Sound reasonable?

Argument from authority?

Again, so?

A statement that's probably far more useful to the original poster than
anything else said in this thread.

Rather than itching for a Usenet fight, why not look into the
subject matter or ask someone to clarify their posts rather than
unnecessarily posturing yourself like you've done in this thread?

I tried to be helpful and clear up things. It appeared to me that
you were doing the opposite, but obviously you had the same impression
of me.

 

[Darryl L. Pierce]

Not, it seems very much to me like you are the one who is
confusing things.

Dude, you're going on about the Locale class and saying that my using
the word locale, but then *YOU* used the word locale in *exactly* the
same way *I* did. WTF? If you don't see your confusion, that's not my
problem. I was quite clear.

Not in a way that helps answering the OP's question.

That's why I didn't say *anything* about the font, and only mentioned
the *locale*. Jaysus, what's your problem?

The phone's *maker*
determines the font that will be used.

What an unnecessary hair to split. Are you just itching for an argument?
The OEM determines what locale is going to be supported by a handset
model, and provides the appropriate font to support that locale.

Therefore there *is no* direct, one-to-one mapping from "locale" to a
set of characters displayable by any or all phones meant for that
locale.

When did I say there was a "one-to-one mapping from 'locale' to a set of
characters"? Seems I said, quite clearly and simply, the characters that
will be displayed will depend on what locale(s) the phone was meant to
support. A phone manufactured for Korea is not going to support Big5.

You really are sounding like someone who said something foolish,
realized it and is now just going to keep arguing nonsense like the
above "it's the phone manufacturer" bit. Move on, get over your mistake.

And what have *character encodings* to do with this debate?

They're referred to as *fonts*, the thing which you previously said was
important and not the locale (when I mentioned the locale), right before
you turned around and said that the locale was what determined the font
(which was what I said originally).

Can you be sure the original poster is aware of that?

Since I never brought up the Locale class, nor mentioned it, there was
no need to do so. That was *you* who made that mistake, but now refuse
to own up to it.

It was useless and misleading.

How? It answered specifically what the OP asked. It said that the
characters supported on the phone are going to be determined by what
locale(s) the phone supports; i.e., what region the phone was programmed
to support. As I've said twice now, an example is a Korean phone that
will definitely not display Big5 of Simplified Chinese characters
because that's a different *locale*.

Now, you'll want to take special care and notice that I used a lower
case /l/ when I said "locale" *each time*. I said nothing about a Locale
class, since the Locale class is not related to the subject at hand. Do
*you* understand? 'Cause it seems to me the OP isn't asking questions
about the Locale class so I'm going to guess here that s/he didn't see
my single sentence with the lower case /l/ as saying what *you*
mistakenly read into it.

Which is a truism and doesn't answer the question because neither
your notion of "locale" nor "be for" is defined formally in a way
that would yield the desired set of displayable characters.

Oh, jaysus but you're just drooling for a fight aren't you?

Where did I say anything about Latin?

You said "phones [...] which have only Korean characters". Well, there
is no such beast. Because Korean phones also display non-Korean, e.g.
Latin characters.

Do they? Is that a "truism"? Do all Korean phones display non-Korean
characters? Can you name some of those phones, please? Which ones
specifically display Korean *and* Latin characters?

"based on" is a very fuzzy non-technical expression, pretty useless when
seeking answers to clear-cut technical questions.

So, now the OP asked a "clear-cut technical question"? Oh, this is RICH!

That's why I'm *not*
saying that. And that's why I'm trying to avoid the word "locale",
becuase the way you're using it, it's equally fuzzy.

The way I'm using it, since I've also *defined* it, is quite clear. You
seem to be the *only one* who latched onto the Locale class and are
confused.

But, before you said "[t]he font is what determines which characters
can be displayed on a Java system. Not a 'locale'" when *I* said it
depends on the locale. So, which is it?

Both.

So, what I said original was correct? Then what's your problem?

The characters displayable on a phone are determined unequivocally
by the font.

Which is determined by the locale(s) the phone is meant to support. QED.

If a character is not in the font, the phone cannot display
it, if it is in the font, the phone can display it. The font contains
any and all of the characters displayable by the phone.

And the font selected is based on what locale the OEM intends for the
phone to be used.

The choice of font is *influenced* by the locale, but not determined
in an unequivocal way, especially since your concept of "locale" is
also fuzzy.

What part are you having a problem with? Maybe you were too busy looking
for something to argue about to read where I posted that a locale is
"[a] geopolitical place or area, especially in the
context of configuring an operating system or application
program with its character sets, date and time formats,
currency formats etc."

Notice the "character sets" part of the definition, which I posted *last
week*. But, you go right ahead and continue to call my usage "fuzzy" if
that makes you feel like you're not bickering about nothing...

Whatever a locale is, not all phones made for it have the
same set of displayable characters.

And is that another OEM truism? Just like the above bit where you said
that Korean phones will also have Latin characters?

The original poster asked specifically about mathematical symbols.

Which are not necessarily going to be available on the phone. But, if
the character set (also called a font) on the phone (as determined by
the locale(s) supported) has them, then they'll be there.

You've really got nothing better to do with your time than to waste it
in this useless debate of yours?

Argument from authority?

Argument from experience. Arguments from false authority are when one
invokes a PhD in philosophy's opinion on the subject of evolution.

A statement that's probably far more useful to the original poster than
anything else said in this thread.

Except that there are very, very few (if *any*) phones that allow you to
update the font on the phone, and that telling someone such a thing
would be beyond misleading since 99.9% (or more) mobiles don't have this
ability. Can you name even *one*? Oh, and let's not forget that even if
the phone *did* allow you to upgrade the font, the MIDP *doesn't let you
specify the font* so it would still be a pointless thing to say.

Tell me, do you actually have any experience with the MIDP? Because this
is at least the second thing you've said that indicates to me that
you're not very well versed in the subject...

I tried to be helpful and clear up things.

And you ended up confusing yourself and making things worse, at least
from your perspective. Perhaps it's time you just bowed out before you
say anything else. I don't know what your problem is, but you should
just save us all the trouble.

It appeared to me that
you were doing the opposite, but obviously you had the same impression
of me.

Yes, I did, because you seemed to bark based on your misunderstandings
rather than asking me questions about what I said. You would have
cleared up a whole lot of your own misconceptions early on if, rather
than jumping to your conclusions, you had just asked for clarification.