About unicodeToMacRoman

Hello list,

that's just a detail, but I do not much like Character>>unicodeToMacRoman.

Why?
Because a Character does not explicitely carry encoding information.
On the contrary, Character are implicitely considered as unicode
encoded in 99% of code.

So, pretending a Character can change encoding is just a hack for a
small portion of code...
...and IMO a ugly one because a Debugger for example would be fooled
and its user too (ego quoque).
I bet most usages of this message will be (someCharacter
unicodeToMacRoman charCode),
so the pretended MacRoman encoded Character does not really need to exist...
(Shame on me, I have not downloaded a recent image, I'm just picking
changes here and there).

If what I say is true, wouldn't a Character>>macRomanCharCode be more clean?

Nicolas

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

To follow up, I downloaded a more recent Pharo and analyzed senders of
#unicodeToMacRoman

Most are in FreeType but one in unused message TTFontReader>>#winToMac:
FreeType mostly use this pattern:
    aCharacter unicodeToMacRoman asUnicode asInteger
except: FreeTypeFont>>#linearKerningLeft:right:
-> which further calls FT2Face>>#kerningLeft:right:
-> -> which further apply (self primGetCharIndex: leftCharacter asInteger)

So the two patterns I see for #unicodeToMacRoman usage are:
    aCharacter unicodeToMacRoman asUnicode asInteger
and for Kerning:
    aCharacter unicodeToMacRoman asInteger

Note that (asUnicode asInteger) seems to be a workaround for kind of
old bug/mess like
http://bugs.squeak.org/view.php?id=6395

The other message #macRomanToUnicode has a single sender
TTFontreader>>#macToWin: which uses the pattern i announced
     macRomanCharCode asCharacter macRomanToUnicode charCode

So, as announced, I conclude there is no use in forming a Character
when we only need a charCode in a specific encoding...

QED

Nicolas

2009/4/1 Nicolas Cellier <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier wrote:

> So, as announced, I conclude there is no use in forming a Character
> when we only need a charCode in a specific encoding...

Thanks for the analysis.

What I basically did was a simple rename of the old squeakToMac etc
selectors, without really analyzing the usage too much. So basically the
freetype maintainer could change the caller sites and remove the then
obsolete methods.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/4/1 Nicolas Cellier <[hidden email]>:
Err...
For some leadingChar ~= 0, encoding IS NOT unicode.
Encoding is specified by leadingChar.

x := (1 << 22 + 16rE4) asCharacter.
x asUnicode hex.  -> 'FF29'
x charCode hex.  -> 'E4'
EncodedCharSet charsetAt: x leadingChar. -> JISX0208

Beware not to print such a Character, it might fail with never ending
notifier poping up

Nicolas

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

who is the freetype maintainer?

Stef

On Apr 2, 2009, at 3:06 PM, Michael Rueger wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project