[squeak-dev] How to compile FreeType Plugin (FT2Plugin)?

Hello,

I have a problem to build FT2Plugin by VMMaker. Does someone could
give me a hint?

In
FT2Plugin>>primitiveCopyToExternalMemory:
...
        rcvr := self primitive: 'primitiveCopyToExternalMemory'
                parameters: #(ByteArray)
                receiver: #FreeTypeExternalMemory.
...

When I generated FT2Plugin, SmartSyntaxPluginTMethod complains that
FreeTypeExternalMemory should be a Behavior, but there is no class
with such name.

I used Freetype-Base-be.70 and Freetype-Plugin-JMM.53 at
http://source.impara.de/freetype/. The image was based on
Squeak3.9alpha #7021 and the OS was Fedora Core 7.

I want to use FreeType for OLPC eToys, and I tested it with FreeType
Plus 0.4 and FreeType Plus (plugins installer) 0.13 on SqueakMap. It
worked pretty well with small change. That's a great job! But I want
to keep all vm source code at one place, so I need to build the plugin
by myself.  Any help is appreciated.

Cheers,
- Takashi

Mmm I thought I could answer this in 20 seconds or less, but it seems  
the last freetype plugin I build for Sophie was in april of 2007.
We've moved towards using the Rome plugin which delegates to the  
freetype library.


On Mar 12, 2008, at 6:25 PM, Takashi Yamamiya wrote:

> FreeTypeExternalMemory

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Hunting about shows in my plugin build image from last  year I have

FT2Handle subclass: #FreeTypeExternalMemory
        instanceVariableNames: 'bytes'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'FreeType-Base'


via I think

Name: FreeType-tween.203
Author: tween
Time: 13 August 2006, 5:17:57 pm
UUID: 215e168e-c4e1-cd47-80c0-fcfa8222932b
Ancestors: FreeType-tween.202

empty log message



On Mar 12, 2008, at 6:25 PM, Takashi Yamamiya wrote:

> FreeTypeExternalMemory

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

"John M McIntosh" <[hidden email]> wrote in message
news:[hidden email]...
Ah. I should have merged that class into Freetype-Base.
I've done that now, it's  Freetype-Base-tween.71.mcz  in source.impara.de

Cheers,
Andy

Hi,
"Takashi Yamamiya" <[hidden email]> wrote in message
news:[hidden email]... That's cool.
(try using Freetype-Base-tween.71.mcz  in source.impara.de, just in case you
didn't see my earlier post)

As well as installing the FT2Plugin, the plugins installer also installs a
modified BitBlt plugin.
This enables sub-pixel anti-aliasing and gamma (contrast) adjustment.

I haven't merged the BitBlt modifications into any VMMaker  package yet; but
I've attached them here - FreeTypeBitBltSimulation.1.cs

FreeType Plus 0.4 will work without the BitBlt modifications , but generates
errors when  displaying underline/strike-through text.
I have attached a patch to fix that problem -
FreeTypeFont-displayLineGlyphOnfromto.st

So, you should EITHER
    install FreeTypeBitBltSimulation.1.cs when building the VM and/or BitBlt
plugin.
OR
    build a standard VM, but load FreeTypeBitBltSimulation.1.cs after
loading FreeType Plus 0.4

Cheers,
Andy


>
> Cheers,
> - Takashi
>


--------------------------------------------------------------------------------


>
>

I build a plugin  a year back

BitBltPlugin.v1.0.0b1.FreeTypePlus.bundle.zip


See

http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-April/116342.html



On Mar 13, 2008, at 1:27 AM, Andrew Tween wrote:

>
> As well as installing the FT2Plugin, the plugins installer also  
> installs a modified BitBlt plugin.
> This enables sub-pixel anti-aliasing and gamma (contrast) adjustment.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Hi John, Andy,

Great! Now I could build it smoothly.

What I did is to load:

- FreeTypeBitBltSimulation.1.cs
- Freetype-Base-tween.71
- Freetype-Plugin-JMM.53

and edit platforms/unix/plugins/FT2Plugin/Makefile.inc like:
XCPPFLAGS=      $$(freetype-config --cflags) $$(freetype-config --cflags)/freetype
XLDFLAGS=       $$(freetype-config --libs)

It shows fonts very beautifully, and
FreeTypeSettings current clearBitBltSubPixelAvailable; bitBltSubPixelAvailable
answered true.

Thank you so much for many helps!

Cheers,
- Takashi

John M McIntosh wrote:

On Mar 13, 2008, at 23:28 , Takashi Yamamiya wrote:

That's not the right way to do it. Instead, you should use an autoconf  
macro like the DBusPlugin does. The package name is freetype2. Also,  
why does the "freetype" subdirectory have to be listed explicitly?

> It shows fonts very beautifully, and
> FreeTypeSettings current clearBitBltSubPixelAvailable;  
> bitBltSubPixelAvailable
> answered true.


OTOH the OLPC XO's unique display has no sub-pixels, so we do not  
actually want sub-pixel rendering. It's good to include nonetheless,  
but we need to make sure not to accidentally enable it when running on  
the XO, or if display scaling is enabled.

- Bert -

Hi,
...snip...
> OTOH the OLPC XO's unique display has no sub-pixels, so we do not
> actually want sub-pixel rendering. It's good to include nonetheless,  but
> we need to make sure not to accidentally enable it when running on  the
> XO, or if display scaling is enabled.

Good point.

In addition to the BitBlt VM changes, the sub-pixel anti-aliasing also
requires the optional FreeType Plus (sub-pixel anti-aliasing) package to be
loaded.
(that is FreeTypeSubPixelAntiAliasing-tween.3.mcz , or later). As long as
this package is not loaded, sub-pixel anti-aliasing will never happen.

However the BitBlt changes also give gamma / contrast adjustment, which
might be useful on the XO's display.
I am guessing here, but it is possible that using different contrast
settings for monochrome and colour modes may give good results.

I got to see an XO machine , for the first time, last Saturday and fell in
love with it.
It's the flip up 'ears' that do it for me, so cute :)

Cheers,
Andy

Hi Bert,

Actually this was what I was about to ask you next;)

On Fri, Mar 14, 2008 at 2:48 AM, Bert Freudenberg <[hidden email]> wrote:
I made acinclude.m4:
PKG_CHECK_MODULES(FREETYPE,freetype2,,AC_PLUGIN_DISABLE)
AC_PLUGIN_DEFINE_UNQUOTED(FREETYPE_CFLAGS,$FREETYPE_CFLAGS)
AC_PLUGIN_DEFINE_UNQUOTED(FREETYPE_LIBS,$FREETYPE_LIBS)

and Makefile.inc:
XCPPFLAGS= [FREETYPE_CFLAGS]
XLDFLAGS=  [FREETYPE_LIBS]

in platforms/unix/plugins/FT2Plugin. I just did copy and paste from
RomePlugin (I'm curious why RomePlugin is here in olpc branch, but
this is a different topic).

But "[FREETYPE_CFLAGS]" was just copied to bld/FT2Plugin/Makefile
without substitution. I'm completely a beginner of autoconf, so could
give me a start point to learn about that? where did $FREETYPE_CFLAGS
come from, and how can I make it work?

> Also, why does the "freetype" subdirectory have to be listed explicitly?

Because freetype-config --cflags answers -I/usr/include/freetype2 but
tttables.h is /usr/include/freetype2/freetype.

FT2Plugin class >> declareCVarsIn:

cg addHeaderFile: '<ft2build.h>'.
cg addHeaderFile: '<tttables.h>'.
cg addHeaderFile: 'FT_FREETYPE_H'.
cg addHeaderFile: 'FT_OUTLINE_H'.
cg var: 'library' declareC: 'FT_Library library'.
cg var: 'errorCode' type: 'int'.

Thank you,
- Takashi

On Mar 14, 2008, at 21:50 , Takashi Yamamiya wrote:

Because it has the Pango primitives, which we actually wanted to use.  
Maybe one day Yoshiki finishes the image-side of things.

> But "[FREETYPE_CFLAGS]" was just copied to bld/FT2Plugin/Makefile
> without substitution. I'm completely a beginner of autoconf, so could
> give me a start point to learn about that? where did $FREETYPE_CFLAGS
> come from, and how can I make it work?

Did you remake the autoconf files? Type "make" in platforms/unix/config.

Then I guess this should be changed to

cg addHeaderFile: '<freetype/tttables.h>'.

- Bert -

Hi Bert,

Bert Freudenberg wrote:
>> (I'm curious why RomePlugin is here in olpc branch, but
>> this is a different topic).
>
> Because it has the Pango primitives, which we actually wanted to use.
> Maybe one day Yoshiki finishes the image-side of things.

That's interesting.

>> But "[FREETYPE_CFLAGS]" was just copied to bld/FT2Plugin/Makefile
>> without substitution. I'm completely a beginner of autoconf, so could
>> give me a start point to learn about that? where did $FREETYPE_CFLAGS
>> come from, and how can I make it work?
>
> Did you remake the autoconf files? Type "make" in platforms/unix/config.

Aha, It works. Thanks!

Yes, It is a good idea.

Cheers,
- Takashi

Isn't something like http://www.jvuletich.org/NiceFonts.html better for
OLPC? (and for most Squeak users, btw...)

Cheers,
Juan Vuletich
Bert Freudenberg wrote:
>
>
> OTOH the OLPC XO's unique display has no sub-pixels, so we do not
> actually want sub-pixel rendering. It's good to include nonetheless,
> but we need to make sure not to accidentally enable it when running on
> the XO, or if display scaling is enabled.
>
> - Bert -
>

José Luis Redrejo wrote:
> I've just tried it and the results are really wonderful. Bert said, OLPC
> does not have sub-pixels, but I've tried it also on an OLPC and it looks
> much better than the original image. Anyway, I have a some doubts:
> - I don't have a CRT monitor, do they look fine at it?
> - Any trick to generate new size/bold/italic fonts? automatically
> generated bold fonts look really ugly...
> - If there is no hidden problem behind this approach, why hasn't it
> already been implemented in the official images?

It's not scalable. Each font needs to be backed by a bitmap and if you
need, say, five fonts at five size (which is less than a regular Squeak
image ships with) you'll end up this:

totalForms := 5 "fonts" * 5 "faces" * 32 "derivedFonts".
totalMemory := 600 "width" * 300 "height" * 4 "depth" * totalForms.

The assumptions of memory consumption are based on the image that Juan
has on his website (approx. 600x300x32bpp). Larger font sizes will have
significantly larger memory requirement (due to geometric growth of the
area) so this is a conservative estimate.

By this estimate, supporting 5 fonts in 5 sizes and all combinations of
emphasis requires approx. 500MB of storage. Oops.

The approach will work well for a very small number of fonts but is not
a scalable solution in general. As a side note StrikeFonts get away with
a similar approach only by virtue of a) having originally 1/32 of the
memory requirements (by using 1-bit forms instead of 32-bit forms) and
b) being able to compute the derivative fonts on demand (so they don't
need to be cached).

Cheers,
   - Andreas

On Mar 20, 2008, at 15:34 , Juan Vuletich wrote:
> Isn't something like http://www.jvuletich.org/NiceFonts.html better  
> for OLPC? (and for most Squeak users, btw...)


No. OLPC eventually needs to support all scripts in the world. Even  
importing all glyphs in Bitstream Vera for regular, bold, italic, bold
+italic takes a huge amount of memory (the current truetype importer  
imports only the latin1 glyph outlines). And pre-rendering those  
glyphs would take even more space.

Rendering outline fonts on-the-fly is really the only option, and  
that's what the FreeType plugin is really good at, it has been in use  
for some time, so we'd like to deploy it asap.

However, even FreeType doesn't quite cut it, to support proper glyph  
shaping/combining like for Nepali we need something more advanced like  
Pango. The OLPC VM contains the RomePlugin with added Pango support,  
but this is still experimental. I heard Scratch uses Pango too, but I  
have not looked at it yet.

So FreeType is still only an interim solution, but way better than  
what we have now.

An issue that fonts embedded in the image solve nicely is that we  
would like to have identical rendering on all platforms. We have not  
yet decided how to tackle this with external fonts. Ideas appreciated.

- Bert -

Hi,
"Bert Freudenberg" <[hidden email]> wrote in message
news:[hidden email]...
FreeType can load a font from memory. So one option is to embed the font
file contents in the image, in a ByteArray.
I have done the work for this, but it may not be in FreeType Plus 0.4 ; it
is certainly in later versions on squeaksource.
In any case, I know for sure that it works.

The other option is to place the font files in a /Fonts sub-folder, relative
to the squeak image.
FreeType Plus will load them, in preference to any other fonts that it finds
which have the same name.
Then, ship the image together with the /Fonts folder.

In either case, the license for the font may prevent the font from being
embedded and/or from being distributed.

The other thing that could affect the rendering is the version of the
freetype libraries that are installed on a particular machine. But, unless
they are very old, it probably won't make much difference.

Cheers,
Andy

>
> - Bert -
>
>
>
>

Hi Andreas,

Thanks for your answer. While I agree with what you say, let me add a
few comments:

- The  memory consumption estimation you made was with the form that is
used to build the fonts. The forms actually stored in the fonts are
smaller. The fonts I included go from 1293 * 11 to 2917 * 33.

- My code is just a small fix to StrikeFonts. As such, I think it
belongs in any official release.

- There are four (that I know) advanced approach to fonts for Squeak:
TTCFont, FreeType, Cairo / Rome and Pango. It makes sense to me to
include StrikeFonts (including my 32bit fix) in a basic official image,
with a really small set of fonts. Then the developer can choose an
advanced font package if needed, taking into account that TTCFont needs
way more memory than 32 bit StrikeFonts (due to color glyph cache) and
that the other options need specific plugins.

Cheers,
Juan Vuletich

Andreas Raab wrote:

I see. Thanks for the answer.

Cheers,
Juan Vuletich

Bert Freudenberg wrote:

Juan Vuletich wrote:
> - The  memory consumption estimation you made was with the form that is
> used to build the fonts. The forms actually stored in the fonts are
> smaller. The fonts I included go from 1293 * 11 to 2917 * 33.

If we average this (is that fair?) it would come out to:

   2100 "width" * 22 "height" * 4 "depth" * 5 "fonts" * 5 "sizes" * 32
"derived"

=> 147,840,000

> - My code is just a small fix to StrikeFonts. As such, I think it
> belongs in any official release.

Uhm, no, not really. It's a new feature not a fix. As such, it should be
treated with some caution. I'm not saying that it can't be included but
there are some aspects about it that make me feel very uneasy (for
example the whole kadoodle in Grafport - I'm virtually certain that
there will be situations where this is wrong).

As a matter of fact I'd probably vote for leaving StrikeFont completely
alone and introduce a new font subclass for these guys. It makes clear
where the assumptions are and the extension points for fonts are by now
defined well-enough that these fonts could be one loadable option.

> - There are four (that I know) advanced approach to fonts for Squeak:
> TTCFont, FreeType, Cairo / Rome and Pango. It makes sense to me to
> include StrikeFonts (including my 32bit fix) in a basic official image,
> with a really small set of fonts. Then the developer can choose an
> advanced font package if needed, taking into account that TTCFont needs
> way more memory than 32 bit StrikeFonts (due to color glyph cache) and
> that the other options need specific plugins.

It makes more sense to me if your fonts are one of the loadable options
from Squeakmap. Then people can decide whether they want one, the other,
or both.

Cheers,
   - Andreas