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

My humble 2 cents.
Fonts require a complete refactoring:
- in a ways how font interacts with canvas
- in a ways how font interacts with primitives (if any)
- use more simplified approach for rendering

On 21/03/2008, Andreas Raab <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
> My humble 2 cents.
> Fonts require a complete refactoring:
> - in a ways how font interacts with canvas
> - in a ways how font interacts with primitives (if any)
> - use more simplified approach for rendering

I disagree. Look at AbstractFont and tell me what is complicated about
it, or how it should interact differently with canvas or how it could
use a "more simplified" approach for rendering. Fonts in Squeak are
trivial - they have a tiny protocol to install, measure and display text
and that protocol is fundamentally sound. It is *very* easy to create a
new subclass of Font and have it your way. What is messed up in Squeak
isn't fonts, it's TextStyle, Paragraph, and CharacterScanner.

Cheers,
   - Andreas

On 21/03/2008, Andreas Raab <[hidden email]> wrote:
Of course, i didn't meant fonts alone.

What i don't like in fonts protocol in particular, is that it's main method

displayString: aString on: aDisplayContext from: startIndex to:
stopIndex at: aPoint kern: kernDelta baselineY: baselineY

assuming that DisplayContext is a BitBlt instance, which bounds us
only to one glyph rendering target/technique - rasterisation.
Which is very suboptimal in case if we want to render vector font to a
device witch capable to render vectors, not just pixels. See how
TTCFont implemented , and see that #formOf: should be used only if
device is incapable to render glyph represented by filled beizer shape
or polygon.

It's also unclear, if i'd like to have own kind of DisplayContext ,
what protocol i should implement to be sure that it will be used
correctly by fonts?
Obviously, i don't want to fully implement bitblt only because there
is a chance that future fonts will use methods from it.
So, at least we need a class DisplayContext (or like) to represent an
abstraction layer for fonts rendering. Or if not, then use canvas
instead, and let font render itself by passing commands to canvas.


--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
Yes, that is an unfortunate side effect of some of the (unfinished) m17n
work. If you look at the origins of it (which can be found in
StrikeFont) the original implementation double-dispatched into the
display context for precisely this reason:

displayString: aString on: aBitBlt from: startIndex to: stopIndex at:
aPoint kern: kernDelta baselineY: baselineY
        "Draw the given string from startIndex to stopIndex
        at aPoint on the (already prepared) BitBlt."
       
        ^aBitBlt displayString: aString
                        from: startIndex
                        to: stopIndex
                        at: aPoint
                        strikeFont: self
                        kern: kernDelta.

The idea was exactly not to have assumptions about the backend rendering
in the font itself.

> It's also unclear, if i'd like to have own kind of DisplayContext ,
> what protocol i should implement to be sure that it will be used
> correctly by fonts?

I think the correct way to dispatch it is in Tweak/Croquet where
DisplayScanner dispatches into the canvas and the canvas can do
additional transformations. This was needed precisely for the reasons
you outline above (it allows font substitution for the canvas which is
extremely handy if you don't like the implementations by the fonts).

For example, check out CTransformCanvas>>displayString: aString from:
startIndex to: stopIndex at: aPoint font: aFont kern: kernDelta which
deals properly (but inefficiently ;-) with rotated fonts.

> Obviously, i don't want to fully implement bitblt only because there
> is a chance that future fonts will use methods from it.
> So, at least we need a class DisplayContext (or like) to represent an
> abstraction layer for fonts rendering. Or if not, then use canvas
> instead, and let font render itself by passing commands to canvas.

See above. The only piece that's *really* missing in the protocol is a
select operation, e.g., a way to ask a canvas for the closest matching
font to a given spec.

Cheers,
   - Andreas

Andreas Raab wrote:
It is just a fix. Why should StrikeFonts break with more than 1 bpp?
BTW, if there is some bug left, it should be fixed, shouldn't it?
>
> 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.

I don't agree. The "assumption" that StrikeFonts are 1 bpp is not
documented. And it doesn't make sense anyway.
I don't see in what they differ from StrikeFonts.
>
> Cheers,
>   - Andreas
>
>
>

Cheers,
Juan Vuletich

Juan Vuletich wrote:
> Andreas Raab wrote:
>> 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).
>
> It is just a fix. Why should StrikeFonts break with more than 1 bpp?

Because they weren't designed to work with anything but 1bpp. Otherwise
you might as well ask "Why should the Squeak VM break with Java
bytecodes? It's just bytecodes after all." A nonsensical argument.

>> 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.
>
> I don't agree. The "assumption" that StrikeFonts are 1 bpp is not
> documented. And it doesn't make sense anyway.

Oh, well if you want to make everything in Squeak that's "not
documented" mean undefined you might as well start over ;-)

I do.

Cheers,
   - Andreas

John M McIntosh ha scritto:
> 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.
>

Speaking of Rome, why don't we include it in the next Squeak release?

        Giovanni

On Friday 21 March 2008 1:52:32 am Bert Freudenberg wrote:
> 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.
Current font-based approaches will not scale for the fifteen languages used in
the language panel of an Indian Rupee (cf. wikipedia), let alone the world
languages. The problem of rendering multilingual text is analogous to the
problem of generating optimized machine code given a set of high level
language instructions. Imagine compiling code with a set of tables containing
translations for 'typical' instructions and a small set of rewrite rules!

I liked the part in Viewpoints NSF proposal where a glyph can be edited like a
morph and then have the changes propagated to the whole document. The
font-based renderer can be replaced with a renderer that generates glyphs on
the fly from a set of basic shape definitions and transform rules both of
which are editable. New glyphs can be generated at any time by adding or
modifying underlying rules or basic shapes.

Subbu

Andreas Raab wrote:
A closer (actually related) argument would say: "Why should BitBlt work
with anything but 1bpp? It was designed for that". Fortunately Dan
didn't see it that way, and we have Squeak and not just Smalltalk-80.
Well, you said "It makes clear where the assumptions are". It doesn't
make it clear at all, unless it is said somewhere. I can tell!

Cheers,
Juan Vuletich

Juan Vuletich wrote:
But where did Dan ever claim that extending BitBlt to handle more than
1bpp was "just a fix"? As a matter of fact "Back to the Future" states
explicitly: "EXTENSIONS of BitBlt to handle color of any depth" (see
http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html; emphasis mine).

Look, maybe you're not getting my point here but what I am questioning
is your assertion that "this is just a fix" and "as such it should be
part of the main Squeak image". I'm saying it's an extension and should
therefore be treated with caution.

Cheers,
   - Andreas

Andreas Raab wrote: I think you made your opinion clear. And so did I. Nothing else to add.

Cheers,
Juan Vuletich