Fonts for dummies

Hello all,

What is the best way to create/access fonts?  So far, TextStyle defaultFont seems to work.  I was about to write that I was feeling lost otherwise when I recalled setting fonts by name in Migrate, and a comment therein reveals that I stole some preferences from Lukas who used LogicalFont.  Perhaps specifying the family name following his example (with cues from exploring LogicalFont all) is the answer?

What about what Microsoft (sorry...) calls font metrics?  By involving a device context (canvas in our world), one can find out how big a particular string will be on the target device's resolution, and allowing for kerning.

So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which means they know nothing of the intended device, and do not (obviously anyway) seem to know about kerning.  Are there glaringly missing features here, or is this simply an consequence of printing being done via PostScript and therefore still in terms of point sizes?

Bill




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

On Apr 19, 2010, at 4:16 25PM, Schwab,Wilhelm K wrote:

>
> What about what Microsoft (sorry...) calls font metrics?  By involving a device context (canvas in our world), one can find out how big a particular string will be on the target device's resolution, and allowing for kerning.
>
> So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which means they know nothing of the intended device, and do not (obviously anyway) seem to know about kerning.  Are there glaringly missing features here, or is this simply an consequence of printing being done via PostScript and therefore still in terms of point sizes?
>
> Bill

StrikeFonts take their glyphs from a bitmap, thus will have constant pixel sizes. (decentKern is used for italic glyphs though)
As far as I know, kerning is not done for StrikeFonts, the only related use is of ascentKern when making a bitmap for italic derivatives of basefonts.
Changing StrikeFonts to include kerning info will mean rewriting the string-rendering primitive, so I wouldn't get my hopes up it is likely to happen anytime soon.


For FreeTypeFonts, getWidthOf: uses AbstractFont>>pixelSize, which again uses TextStyle>>pointsToPixels: , which relies on TextStyles>>pixelsPerInch.
pixelsPerInch _could_ be set based on information gathered at startup about resolution and screen size, but is not done currently, so a default of 96 is used.
FreeTypeFont>> widthOfString:from:to: returns a width which takes kerning into account. (in theory, see the comment for clarifications)

In essence, if those features are important to you:
- Use FreeTypeFonts.
- Set TextStyle pixelsPerInch: to a computed value at startup.

Cheers,
Henry



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

On 19 April 2010 17:16, Schwab,Wilhelm K <[hidden email]> wrote:
> Hello all,
>
> What is the best way to create/access fonts?  So far, TextStyle defaultFont seems to work.  I was about to write that I was feeling lost otherwise when I recalled setting fonts by name in Migrate, and a comment therein reveals that I stole some preferences from Lukas who used LogicalFont.  Perhaps specifying the family name following his example (with cues from exploring LogicalFont all) is the answer?
>
> What about what Microsoft (sorry...) calls font metrics?  By involving a device context (canvas in our world), one can find out how big a particular string will be on the target device's resolution, and allowing for kerning.
>
> So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which means they know nothing of the intended device, and do not (obviously anyway) seem to know about kerning.  Are there glaringly missing features here, or is this simply an consequence of printing being done via PostScript and therefore still in terms of point sizes?
>

I think there is a _glaringly missing features here_.
The fonts in squeak seems evolved from being a simple raster bitmaps,
and don't quite well resembling a functionality beyond this.



--
Best regards,
Igor Stasenko AKA sig.

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

On Apr 19, 2010, at 4:47 17PM, Henrik Johansen wrote:

>
> StrikeFonts take their glyphs from a bitmap, thus will have constant pixel sizes. (decentKern is used for italic glyphs though)
> As far as I know, kerning is not done for StrikeFonts, the only related use is of ascentKern when making a bitmap for italic derivatives of basefonts.
>

Arr. Correction; the only place StrikeFonts use something with a name related to kerning is when doing something with Italics, can't remember exactly how, why, or what methods. :) In any case it's not the kerning you are looking for.

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

That will take some (re)reading, but is much appreciated.  The fact that the Canvas is not involved is deeply discouraging: one should not have to edit a class method in order to involve a higher-resolution output device :(

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Johansen
Sent: Monday, April 19, 2010 9:47 AM
To: [hidden email]
Subject: Re: [Pharo-project] Fonts for dummies


On Apr 19, 2010, at 4:16 25PM, Schwab,Wilhelm K wrote:

>
> What about what Microsoft (sorry...) calls font metrics?  By involving a device context (canvas in our world), one can find out how big a particular string will be on the target device's resolution, and allowing for kerning.
>
> So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which means they know nothing of the intended device, and do not (obviously anyway) seem to know about kerning.  Are there glaringly missing features here, or is this simply an consequence of printing being done via PostScript and therefore still in terms of point sizes?
>
> Bill

StrikeFonts take their glyphs from a bitmap, thus will have constant pixel sizes. (decentKern is used for italic glyphs though) As far as I know, kerning is not done for StrikeFonts, the only related use is of ascentKern when making a bitmap for italic derivatives of basefonts.
Changing StrikeFonts to include kerning info will mean rewriting the string-rendering primitive, so I wouldn't get my hopes up it is likely to happen anytime soon.


For FreeTypeFonts, getWidthOf: uses AbstractFont>>pixelSize, which again uses TextStyle>>pointsToPixels: , which relies on TextStyles>>pixelsPerInch.
pixelsPerInch _could_ be set based on information gathered at startup about resolution and screen size, but is not done currently, so a default of 96 is used.
FreeTypeFont>> widthOfString:from:to: returns a width which takes
FreeTypeFont>> kerning into account. (in theory, see the comment for
FreeTypeFont>> clarifications)

In essence, if those features are important to you:
- Use FreeTypeFonts.
- Set TextStyle pixelsPerInch: to a computed value at startup.

Cheers,
Henry



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

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

I'm not sure how to read "it's not the kerning you are looking for."  What I am trying to discover is how to get the exact pixel size of '0xFFFF' and of 'suffix AV' - the latter will potentially involve more kerning than the former.

If this were being done correctly, one would need not only the output device and the font, but also the exact text.  It appears there is room to grow.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Johansen
Sent: Monday, April 19, 2010 9:50 AM
To: [hidden email]
Subject: Re: [Pharo-project] Fonts for dummies


On Apr 19, 2010, at 4:47 17PM, Henrik Johansen wrote:

>
> StrikeFonts take their glyphs from a bitmap, thus will have constant
> pixel sizes. (decentKern is used for italic glyphs though) As far as I know, kerning is not done for StrikeFonts, the only related use is of ascentKern when making a bitmap for italic derivatives of basefonts.
>

Arr. Correction; the only place StrikeFonts use something with a name related to kerning is when doing something with Italics, can't remember exactly how, why, or what methods. :) In any case it's not the kerning you are looking for.

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

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

On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote:

> That will take some (re)reading, but is much appreciated.  The fact that the Canvas is not involved is deeply discouraging: one should not have to edit a class method in order to involve a higher-resolution output device :(

which method?
open a clear bug entry or request for improvement
Stef


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

  On 19.04.2010 21:10, Schwab,Wilhelm K wrote:
> That will take some (re)reading, but is much appreciated.  The fact that the Canvas is not involved is deeply discouraging: one should not have to edit a class method in order to involve a higher-resolution output device :(
Please note, the "output device" in your definition, and a "Canvas" as
defined in Squeak/Pharo, are two different things.
A canvas does not know the physical dimensions of the display device its
raster will be displayed on.
Thus using it when rendering will not make any difference, but the
TextStyles>>pixelsPerInch setting does what you'd like (for FreeType fonts).

Repeated for clarity:
> In essence, if those features are important to you:
> - Use FreeTypeFonts.
> - Set TextStyle pixelsPerInch: to a computed value at startup.
The computed value here meaning: "Whatever you somehow manage to find
out is the correct physical proportion".

Cheers,
Henry

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

  On 19.04.2010 21:17, Stéphane Ducasse wrote:
> On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote:
>
>> That will take some (re)reading, but is much appreciated.  The fact that the Canvas is not involved is deeply discouraging: one should not have to edit a class method in order to involve a higher-resolution output device :(
> which method?
> open a clear bug entry or request for improvement
> Stef
It's not a class-method, it's a setting, set by f.ex:
TextStyle pixelsPerInch: 72. (Try changing it to something other than 96
while using a FreeType font somewhere, and you can see the text size
changing)

Ideally there'd be code which gathers this value from the system at
image startup, I'm not aware if such code exists though.
Cheers,
Henry

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

  On 19.04.2010 21:16, Schwab,Wilhelm K wrote:
> I'm not sure how to read "it's not the kerning you are looking for."
Read it as "if you meant kerning in the sense that the width of a string
~= width of each individual character" i.e., the ascent/descentKerns in
StrikeFonts are not used for this.
>   What I am trying to discover is how to get the exact pixel size of '0xFFFF' and of 'suffix AV' - the latter will potentially involve more kerning than the former.
When rendered by StrikeFonts, no, they will not, since it does not do
kerning.
For FreeTypeFonts, #widthOfString:from:to: does exactly what you ask.
It wouldn't be impossible to add kerning to StrikeFonts, but it's a
fairly major task as you'd need to:
- Update the StrikeFont class to include kerningInfo, and implement
kerningLeft:right: method
- Define font construction methods etc.
- Actually define useful kerning values for fonts in use.
- Update the displayString: primitive to take into account kerning info

Basically, the support is just not there at all at the moment for
StrikeFont kerning.

Cheers,
Henry

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

No argument, but I am saying that the Canvas *should* know the resolution of the device.  The current division of responsibility between form and canvas is not correct.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Sperre Johansen
Sent: Monday, April 19, 2010 2:38 PM
To: [hidden email]
Subject: Re: [Pharo-project] Fonts for dummies

  On 19.04.2010 21:10, Schwab,Wilhelm K wrote:
> That will take some (re)reading, but is much appreciated.  The fact
> that the Canvas is not involved is deeply discouraging: one should not
> have to edit a class method in order to involve a higher-resolution
> output device :(
Please note, the "output device" in your definition, and a "Canvas" as defined in Squeak/Pharo, are two different things.
A canvas does not know the physical dimensions of the display device its raster will be displayed on.
Thus using it when rendering will not make any difference, but the
TextStyles>>pixelsPerInch setting does what you'd like (for FreeType fonts).

Repeated for clarity:
> In essence, if those features are important to you:
> - Use FreeTypeFonts.
> - Set TextStyle pixelsPerInch: to a computed value at startup.
The computed value here meaning: "Whatever you somehow manage to find out is the correct physical proportion".

Cheers,
Henry

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

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

A good short to mid term goal would be get the flow or responsibility to allow kerning to work; then somebody with interest might have pity on us and fill in the details.  As things are now, the division between Canvas and Form is not correct, so anyone trying to add kerning would have to fight both battles.

BTW, I don't really care about kerning itself; I care that the system design does not anticipate it and in fact fights it.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Sperre Johansen
Sent: Monday, April 19, 2010 2:52 PM
To: [hidden email]
Subject: Re: [Pharo-project] Fonts for dummies

  On 19.04.2010 21:16, Schwab,Wilhelm K wrote:
> I'm not sure how to read "it's not the kerning you are looking for."
Read it as "if you meant kerning in the sense that the width of a string ~= width of each individual character" i.e., the ascent/descentKerns in StrikeFonts are not used for this.
>   What I am trying to discover is how to get the exact pixel size of '0xFFFF' and of 'suffix AV' - the latter will potentially involve more kerning than the former.
When rendered by StrikeFonts, no, they will not, since it does not do kerning.
For FreeTypeFonts, #widthOfString:from:to: does exactly what you ask.
It wouldn't be impossible to add kerning to StrikeFonts, but it's a fairly major task as you'd need to:
- Update the StrikeFont class to include kerningInfo, and implement
kerningLeft:right: method
- Define font construction methods etc.
- Actually define useful kerning values for fonts in use.
- Update the displayString: primitive to take into account kerning info

Basically, the support is just not there at all at the moment for StrikeFont kerning.

Cheers,
Henry

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

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

You got me :)  However, setting vs. class-variable is merely an implementation detail.  The sad reality is that it is in the wrong place: it is global rather than being in Canvas and hence settable each time/place graphics are rendered.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Sperre Johansen
Sent: Monday, April 19, 2010 2:43 PM
To: [hidden email]
Subject: Re: [Pharo-project] Fonts for dummies

  On 19.04.2010 21:17, Stéphane Ducasse wrote:
> On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote:
>
>> That will take some (re)reading, but is much appreciated.  The fact
>> that the Canvas is not involved is deeply discouraging: one should
>> not have to edit a class method in order to involve a
>> higher-resolution output device :(
> which method?
> open a clear bug entry or request for improvement Stef
It's not a class-method, it's a setting, set by f.ex:
TextStyle pixelsPerInch: 72. (Try changing it to something other than 96 while using a FreeType font somewhere, and you can see the text size
changing)

Ideally there'd be code which gathers this value from the system at image startup, I'm not aware if such code exists though.
Cheers,
Henry

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

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