[ANN] Yet Another TrueType support for Squeak

Yoshiki.Ohshima at acm.org Yoshiki.Ohshima at acm.org
Tue May 6 16:39:47 UTC 2003


  Arjen,

> >   The primitive that uses a 8bit form as alpha is something I want to
> > have.  Thanks.  I'm not sure we want to have yet another scanning
> > primitive, but of course, you can always fall back to the backup code.
> >
> The scanning primitive was needed  to support real advances and not the
> width of a glyph, I think this way the text looks much better. Maybe we
> can do away with the scanning primitive all together I don't know if this
> is fast enough...

  Yes, but it still could be done at the Squeak-level code by adding
a primitive that returns the (fractional) advance width of a character
or something.

  The reason I like the Squeak-level code is that it gives us more
flexibility.  To compose some wierd scripts such as Japanese, you want
to have some "programmability" in scanning.

> >> * No bold or italics support
> >
> >   This can be done in Squeak-level code,
> I know, but this didn't look very good and therefor I moved the font to a
> subclass of abstarctfont and not strikefont. I would like to use different
> font files for bold and italic (if supported by the font). This is not
> very hard.

  That is what I meant by Squeak-level code.  I didn't mean the
automatic distortion of fonts, but just organize the different font
files and map them to the existing emphasis management code in Squeak.
It might be worth to take a look at the TrueTypeTextStyle code.

> >> * No real knowledge of font-familys
> >
> >   once you have a way to get this info.
> Yes we have ways to do this but I meant high level support (like reading a
> couple of font directories and extracting font family info, composing one
> font out of different true type files that can handle such thing as bold
> italic etc).

  Ok.  Sounds good.

> >> * Not Unicode
> >
> >   What do you mean by this?
> The primitives go only to 256 characters as well as the font reading and
> converting it would'nt be too hard to support more chars but this would
> depend on fall-back code.

  The hard part is the scanning rule implementation, I think.

-- Yoshiki



More information about the Squeak-dev mailing list