Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

Re: Correct wat to Draw strings (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: RB's unicode new features
Next thread: Re: class extensions ...


Re: Plugins website   -   Troy A. Dix
  Re: Correct wat to Draw strings   -   Theodore H. Smith
    Correct wat to Draw strings   -   Einhugur Software
     Re: Correct wat to Draw strings   -   Joseph J. Strout
      Re: Correct wat to Draw strings   -   Einhugur Software
       Re: Correct wat to Draw strings   -   Joseph J. Strout

Re: Correct wat to Draw strings
Date: 06.06.02 20:48 (Thu, 6 Jun 2002 21:48:53 +0200)
From: Theodore H. Smith
> Wouldn't it have been logical to select one good and solid encoding and
> switch entirely to it ?? Having multiple in the same data type
> is a prone to
> slow string handling. And speed in a programming language certainly is
> something that users are concerned with.

I'd say so. Seeing as you want to combine binary and unicode data, you
might want utf8 as your default encoding. This way you can use many
same string functions on the same two. This is because utf8
never contains
a chrb(0), and nothing < 128 unless it is ASCII. Sometimes you can use
binary string functions fine on utf8. Not always though.

Although for speed of processing, you'll want UTF32. But then that means
there are lots of 0's in the data, and RAM wasted, and its compatible
with all string functions.

So you might have to have split code, or use utf8. Or do both.

Personally, I'm splitting code by dealing with UTF32 and letting RB
deal with the bytes. It does waste a lot of RAM, but these days
RAM is cheap, especially with OSX, and CPU is *never* cheap.

> Look at .NET there is all Unicode, and if some component needs
> something
> different than unicode then the datatype is called something
> else than a
> string like if you convert to ASCII then it goes to a Bytes
> variable rather
> than a String variable. Having to check each time what you get
> is a good
> path to get things very slow, both for string drawing and any string
> manipulation.

I agree.

> Also I believe if the strings have gotten so complicated that
> its impossible
> to explain how to correctly draw them in a safe way then maybe
> its time to
> consider providing a string render method from REALbasic.

You mean plugin method? I agree. Drawstring should be available
to plugins.
That means RS should provide also stringwidth, substringwidth (for OSX),
stringheight, etc, for plugins. Because we can't do a drawstring
correctly
without them.

Does graphics.drawstring handle UTF32? Is there a UTF32 encoding that
RB recognises?

Also I'd hope that we get a drawstring to characters, via a pointer to
some text and a length. If not, I may consider hacking it by temporarily
altering my string pointers. Its bad, but it will work. I hold my data
in something that isn't an RB string, you see. RB strings are not 0
aligned, and that would ruin my UTF32 string handling's speed (PPCs
dont' like non 4-aligned longs).

Correct wat to Draw strings
Date: 06.06.02 23:31 (Thu, 06 Jun 2002 22:31:38 +0000)
From: Einhugur Software
>REALGetStringEncoding PPC OSX Win
>RB 4.5b1
>
>This function returns the text encoding associated with the given string.
>Typical values are kTextEncodingUnknown (0xFFFF), kCFStringEncodingASCII
>(0x0600), kCFStringEncodingUTF8 (0x08000100), and kCFStringEncodingUnicode
>(0x0100). Note that this is the encoding that is known to REALbasic; it may or
>may not match the user's intended encoding.

Now what is the correct, fast and safe way to draw string now days into a
QuickDraw Port from a plugin ?? (Taking into account all those encodings)

Thanks
--  
______________________________________________________________________
Björn Eiríksson <email address removed>
Einhugur Software <email address removed>
http://www.einhugur.com
______________________________________________________________________
Einhugur Software has sold its products in 39 countries world wide.
______________________________________________________________________
For support: <email address removed>
For bug reports: <email address removed>
To post on the maillist: <email address removed>




- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: Correct wat to Draw strings
Date: 06.06.02 23:42 (Thu, 6 Jun 2002 15:42:16 -0700)
From: Joseph J. Strout
At 10:31 PM +0000 6/6/02, Einhugur Software wrote:

> >REALGetStringEncoding PPC OSX Win
> >RB 4.5b1
>>
>>This function returns the text encoding associated with the given string.
>>Typical values are kTextEncodingUnknown (0xFFFF), kCFStringEncodingASCII
>>(0x0600), kCFStringEncodingUTF8 (0x08000100), and kCFStringEncodingUnicode
>>(0x0100). Note that this is the encoding that is known to
>>REALbasic; it may or
>>may not match the user's intended encoding.
>
>Now what is the correct, fast and safe way to draw string now days into a
>QuickDraw Port from a plugin ?? (Taking into account all those encodings)

Ah, that's quite hard. The answer is "use ATSUI" but that takes a
largish amount of code to get right. Second-best is to use a Text
Encoding Converter to convert the string from whatever it is, to
something you know how to draw (e.g., the script associated with the
font you're about to draw in -- see FontScript and FontToScript for
that).

HTH,
- Joe

Re: Correct wat to Draw strings
Date: 06.06.02 23:58 (Thu, 06 Jun 2002 22:58:33 +0000)
From: Einhugur Software
on 6.6.2002 22:42, Joseph J. Strout at <email address removed> wrote:

>>
>> Now what is the correct, fast and safe way to draw string now days into a
>> QuickDraw Port from a plugin ?? (Taking into account all those encodings)
>
> Ah, that's quite hard. The answer is "use ATSUI" but that takes a
> largish amount of code to get right. Second-best is to use a Text
> Encoding Converter to convert the string from whatever it is, to
> something you know how to draw (e.g., the script associated with the
> font you're about to draw in -- see FontScript and FontToScript for
> that).
>
> HTH,
> - Joe

This is VERY bad news I guess !! This probably means that all of the Grid
controls will brake, and even if I do find the magical way to do it then
it still will probably draw way slow because it has to ask for each and
every string of what encoding it is.

Wouldn't it have been logical to select one good and solid encoding and
switch entirely to it ?? Having multiple in the same data type is a prone to
slow string handling. And speed in a programming language certainly is
something that users are concerned with.

Look at .NET there is all Unicode, and if some component needs something
different than unicode then the datatype is called something else than a
string like if you convert to ASCII then it goes to a Bytes variable rather
than a String variable. Having to check each time what you get is a good
path to get things very slow, both for string drawing and any string
manipulation.

Also I believe if the strings have gotten so complicated that its impossible
to explain how to correctly draw them in a safe way then maybe its time to
consider providing a string render method from REALbasic.

--  
______________________________________________________________________
Björn Eiríksson <email address removed>
Einhugur Software <email address removed>
http://www.einhugur.com
______________________________________________________________________
Einhugur Software has sold its products in 39 countries world wide.
______________________________________________________________________
For support: <email address removed>
For bug reports: <email address removed>
To post on the maillist: <email address removed>




- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: Correct wat to Draw strings
Date: 07.06.02 02:11 (Thu, 6 Jun 2002 18:11:54 -0700)
From: Joseph J. Strout
At 10:58 PM +0000 6/6/02, Einhugur Software wrote:

>This is VERY bad news I guess !! This probably means that all of the Grid
>controls will brake, and even if I do find the magical way to do it then
>it still will probably draw way slow because it has to ask for each and
>every string of what encoding it is.

No, it means nothing of the sort. You can ignore the "encoding"
parameter if you wish and do exactly as you've always been doing. Or
you can pay attention to it, and do even better. But nothing will
stop working just because we now have this extra information
available.

>Wouldn't it have been logical to select one good and solid encoding and
>switch entirely to it ??

No, because that would force a conversion in a lot of places where
that's not really necessary.

But the basic idea is good. There is, however, only one encoding
that fits the bill: Unicode. No other encoding can represent all
text. And the only way to draw Unicode decently on the Mac is via
ATSUI, which is what I already suggested as option 1.

So, if that is unappealing, you should be thankful that we're not
forcing all strings to be Unicode. Existing apps getting data in
existing ways will continue to have their strings in MacRoman,
MacJapanese, etc., and you can draw these with QuickDraw as you've
always been doing.

> Having multiple in the same data type is a prone to
>slow string handling. And speed in a programming language certainly is
>something that users are concerned with.

Yes, that's why we don't convert text until we really need to (as
that's expensive).

>Having to check each time what you get is a good
>path to get things very slow, both for string drawing and any string
>manipulation.

On the contrary, the time required for the check is microscopic. But
converting a string before you need to -- especially since you often
don't need to at all -- is extremely wasteful. This is a "lazy"
approach and it's a widely recognized technique for gaining
performance.

>Also I believe if the strings have gotten so complicated that its impossible
>to explain how to correctly draw them in a safe way then maybe its time to
>consider providing a string render method from REALbasic.

Well, that's a sensible idea. But I think it would have to render to
a REALgraphics object, not to an arbitrary grafport.

Cheers,
- Joe