PhiHo,

 What a leverage, 12KB of C# code
(TrueTypeTextStyle.cs ;-)
bring 73MB of fonts to my Squeak
(that's how small my 'windows\Fonts'
directory is).

It even works with VI4 :-)

Thank you for trying it. My WINDOWS\Fonts folder has a lot more of .ttc files that are loadable as well:-)

Would you please put it on SqueakMap.

Now I have to confess that I need to learn how to do this...

-- Yoshiki

Hi Yoshiki,

Unfortunately, I haven't yet looked at the code, but here's something that might be of help. For >= 8 bpp you can use rule 34 (this is what Balloon uses). There is one gotcha though since rule 34 expects *prescaled* rgb in the source. Meaning that the encoding for rule 34 needs to be like what you see in #scaledPixelValue32 (that's what this method is for). This will perform alpha blending regardless of destination depth but it's pretty clear that the results will be less than optimal for 8bpp. However, for 16bpp (which is the most likely use) you even get a very reasonable ordered dither for free.

Cheers, - Andreas

Craig,

...

Thanks!

After trying it, I'm wondering if you have any particular optimizations planned. On my machine (550 MHz), typing speed and menu performance are noticeably decreased (using 13-point Verdana). Are there still some relatively easy speedups possible?

You're using it for code pane(s) with some hundreds of characters in it? Yes, it can be slow. The purpose of mine was pretty much for the Presentation slides where typical slide only has dozens of characters.

Regarding the optimization, I can suggest a few things:

• First of all, if you don't use any fancy background colors,

  TTFontReader>>installTTF:asTextStyle:sizes:

  should be good enough. For a single colored background, you don't have to worry about the anti-alias fringe of pre-rendered bitmaps with alpha channel.

• I was thinking to render the glyphs on 32 bit form and draw them onto the destForm with combination rule=24. But this only works when the destForm is 32 bit depth as well. I was trying this approach, but didn't get to a point where I'm happy with the result for some reason... If I remember correctly, it was related to the black/transparent pixels (Balloon engine renders black as 16rFF000000, instead of 16rFF000001 and because it is 32 bit form, I can't map colors easily) or something like that. It is worth to investigate again. Anyway, I even wrote the simple LRU bitmap font cache handling mechanism for the multi-octet character set.

• It may be possible to store the "cached" bitmaps as 8-bit grayscale, map the grays to the alpha value and render them. But still the restriction for the destForm applys.

• The minor point is that the glyphs are stored upside down and it is flipped every time. It wouldn't save too much, but you can flip the all glyphs by calling #flipAroundY beforehand.

As you know, it is mostly about Andreas' code, so let's wait for his opinion:-)

-- Yoshiki

Hi Yoshiki,

The cached TTF rendering rocks!!! It is not only a zillion times faster but also fixes some weird problems with the raw bezier rendering (when I turned it on I sometimes got it overlayed with menus on top and at other times it looks like the AA "got lost" someplace). It's beautiful and fast - this is great!

Thank you so much.

Cheers, - Andreas

-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Yoshiki.Ohshima@acm.org Sent: Sunday, December 01, 2002 10:04 AM To: squeak-dev@lists.squeakfoundation.org Cc: craig.latta@netjam.org; Andreas.Raab@gmx.de Subject: Re: TrueType based TextStyle

Hello,

...

Unfortunately, I haven't yet looked at the code, but here's

something that

...

might be of help. For >= 8 bpp you can use rule 34 (this is

what Balloon

...

uses). There is one gotcha though since rule 34 expects

*prescaled* rgb in the

...

source. Meaning that the encoding for rule 34 needs to be

like what you see in

...

#scaledPixelValue32 (that's what this method is for). This

will perform alpha

...

blending regardless of destination depth but it's pretty

clear that the

...

results will be less than optimal for 8bpp. However, for

16bpp (which is the most

...

likely use) you even get a very reasonable ordered dither for free.

I tried the rule 34 and it works for 16bpp and 32bpp destinations! Attached is the revised version of change set. File it in and you'll see 'ComicSansMS' and 'RenderedComicSansMS' styles in the font list menu.

A little nice to have feature is to map the translucent anti-aliased fringe color to the specified color. Namely, if the user specifies some color other than black, it would be nice if we can simply change the color of previously rendered bitmaps. Right now, it always flushes the internal bitmap cache when it is requested to change the text color.

I haven't done any serious performance evaluation. It'd be higly appriciated:-)

Hello,

After releasing the previous versions, I've got a vocal user of this TrueTypeTextStyle thing:-) and had a chance to improve it one more round. Now the code is cleaner and faster.

The attached one is intended to be filed into vanilla 3.2 or 3.4a images.

Any suggestions and comments are welcome.

Thank you,

-- Yoshiki

Phil,

Thank you for the feedback. I looked at your code.

TTCFont.class.PH.1.cs looks fine. I didn't think about the FileList action, but it makes sense. It would be nice for now if there is a way to create the true type banner which supports the rotation. Of course, in the future, TTTextStyle should be able to support it.

I'm wondering if there is a bit more generic solution for the ProgressBarMorph.PH.1.cs, such as modifying the logic around DisplayText. Namely, how about if DisplayText>>form returns 32bpp forms if the TTCFonts are used, and DisplayText>>displayOn:at:clippingBox:rule:fillColor: renders it via a temporary created FormCanvas?

-- Yoshiki

Phil and everyone,

I do think you are correct, a more generic (and lower-level solution) would be more appropriate--and in the locations you've identified. Presently, I do not yet have the skills to make such a change, as the mysteries of how Squeak renders to the screen (especially how Morphic renders to the screen on top of all the BitBlt / Display stuff from earlier Smalltalks).

It is sometimes mystery to me, too.

One observation: Display>>form doesn't do much work, but Display>>composeForm does, and (in the case of Morphic) it strangely first creates a TextMorph of the text, gets an image from that with a depth of 1, then builds a ColorForm on which it draws that image. Don't know why all of that work--seems like just one really good rendering on an appropriately configured form or canvas should have done the trick, but, as mentioned, I don't yet grok Squeak's rendering architecture.

Me neither, but take a look at my "version 4" code on SqueakMap. It supports this, as well as other faces (bold, italic, and bold italic). I tested it in MVC projects and it seems working, too.

-- Yoshiki

Le 2002/12/02 à 20:23, Markus Fritsche Fritsche.Markus@gmx.net écrivait:

Which raises another problem: Is there an apropriate font chooser? For instance, the "system fonts"-menu is too small to handle this amount of fonts.

There is the FontMover from Jean-Marie Zajac

Hello,

Okay, I give up: why is that--now that I've changed my default font to be a CachedTTCFont rendering Arial from an MS Windows TTF--that various "announcers" (e.g., the text appearing near the cursor when filing in a changeset, loading a package from SqueakMap, filing in a TTCFont, etc.) all render there text as white on white background (or transparent on white background, I can't tell). Except for this disappearing text bit, I'm quite pleased with this contribution towards a better looking Squeak! :)

So, "CachedTTCFont" must be more natural than "CachingTTCFont":-) I should change the name along with some other tweaks.

The problem you mentioned must be in DisplayText>>composeForm. When it trys to create a 1bpp form, it becomes a form with all "0" because there is not pure black pixels in the rendered result.

Anyway, I didn't mean it to be used for the default fonts. I'm glad to know it works ok, though.

Regarding the cache strategy, the extent of the default placeholder Forms should be 1@1 or even 0@0 instead of 16@16 to save memory. Also, for a charset smaller than 256, it doesn't make much sense to do LRU caching. It can be a simple table indexed by the char code to avoid the LRU management cost.

Lastly, for better looking Squeak, you might want to try Henrik's sub pixel rendering stuff. The look of his one should be better than mine. The advantage of mine is that it works for the text on non-white background...

-- Yoshiki