Re: [xmlvm-dev] Generating Java iOS API

[Aaron V. <gru...@gm...>]

There's the problem though that String.getBytes() returns different
bytes depending on the "the platform's default charset".  I'm not
immediately sure what that even refers to in using xmlvm to generate
objc code.

This gets ugly pretty quickly, but at the moment I don't see a real
solution for this.  Sticking with byte[] does sound like the best bet
for now.

Just to add a few more details, here's what the Java code would look
like to correctly convert draw some text to a CGContext...

myCGContext.selectFont(myFontName.getBytes(Charset.forName("US-ASCII"),
12, UIKit.CGEncodingMacRoman);
byte[] bytes = myText.getBytes(Charset.forName("MacRoman"));
myCGContext.showText(bytes, bytes.length);

The font name is required to be a "postscript name", although it
doesn't specifically say what the encoding should be (I'm guessing
ASCII here).  The text passed to showText needs to be in the encoding
specified by the third argument to selectFont.  (The only two choices
are MacRoman or FontSpecific--not particularly helpful.)

The C backend is going to be cross-compiling the Apache Harmony, is
the correct?  Hopefully that includes an implementation of the
MacRoman Charset, which is not required to be implemented by every
Java platform.

Maybe in practice it won't be that big of a deal, but I'm sure some
xmlvm user down the road is going to be thrown for a loop by this.

Again, I don't have any other solution to offer, but I think it's
interesting to stay aware of this.

Cheers,
--Aaron V.

On Mon, Oct 10, 2011 at 4:32 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
>> ----------------------------------
>> CGContext.java:
>>       /**
>>        * void CGContextSelectFont(CGContextRef c, const char *name, CGFloat
>> size, CGTextEncoding textEncoding) ;
>>        */
>>       public void selectFont(byte[] name, float size, int textEncoding)
>>
>> I'd really like to see (const char*) parameters changed to String
>> instead of byte[], although I wonder if it will be possible to do this
>> conversion automatically in the C wrappers in a way that will work in
>> all cases.  (There are many instances of this.)
>
>
> I understand, and I absolutely disagree :)
> The reason is that char* is NOT a String, it is a byte[].
> String is a unicode stream of (Java's) char, while char is 2-bytes variable instead of 1-byte C's char.
> In English language there is no real difference, but for every other language this is a serious problem (including my mother tongue).
> I wanted with the API to make clear that "char* is not a String - if you want to do something like this, do it with your own responsibility".
>
> Having said that, it would be indeed nice to have functions that the developer can call and convert between byte[] and String - oh wait, here they are! :)
> http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html#String%28byte[]%29
> http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html#getBytes%28%29
>