Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > MIDP MIDlet: which characters are supported in the phone font?

Reply
Thread Tools

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

 
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-11-2004
Darryl L. Pierce wrote:
>>>> What *are* a "country's displayable characters"?
>>>
>>> Take, for example, the font used to display Korean characters.

>>
>> 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?


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".

>>> 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.


> 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.






 
Reply With Quote
 
 
 
 
Darryl L. Pierce
Guest
Posts: n/a
 
      12-11-2004
Michael Borgwardt wrote:
>>>>> What *are* a "country's displayable characters"?
>>>>
>>>> Take, for example, the font used to display Korean characters.
>>>
>>> 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?

>
> 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.

>> 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.


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?

--
Darryl L. Pierce <(E-Mail Removed)>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard
 
Reply With Quote
 
 
 
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-14-2004
Darryl L. Pierce wrote:
>> 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*.


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.


>>> 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.

>
> 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.


>> 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?


"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.


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

>
> 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?


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

>
>
> 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.
 
Reply With Quote
 
Darryl L. Pierce
Guest
Posts: n/a
 
      12-15-2004
Michael Borgwardt wrote:
>>> 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*.

>
> 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.

>> 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.


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.

<snip>
> 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.

>> 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?


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).

>> 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?


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.

>> 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.


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.

>> 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.


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

>>>> 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.

>>
>> 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?

>>> 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?

>
> "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?

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

>>
>> So?

>
> 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?

>> 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?


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

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

>>
>> Again, so?

>
> 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...

>> 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.


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.

--
Darryl L. Pierce <(E-Mail Removed)>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Free Phone to Phone Calling.. From any phone to any other anywhere coolguy17111987 Cisco 0 07-01-2007 07:27 AM
MIDP-only phone that supports raw audio recording? And how to find out... CharlesW Java 0 09-27-2006 03:45 PM
J2ME, MIDP 2.0 and detecting phone number Vagif Abilov Java 12 08-21-2006 07:48 PM
java.lang.NullPointerException at com.sun.kvem.midp.MIDP.run(MIDP.java:651) Fahad Java 1 08-08-2005 02:11 PM
Will application J2ME MIDP 2.0 based of one device run another J2ME MIDP 2.0 device? nishadixit Java 5 06-01-2005 05:40 AM



Advertisments