[Pharo-project] 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
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
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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Monday, April 19, 2010 9:50 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Monday, April 19, 2010 2:52 PM To: pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Monday, April 19, 2010 9:47 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Monday, April 19, 2010 9:47 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Monday, April 19, 2010 2:43 PM To: pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Monday, April 19, 2010 2:38 PM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 19 April 2010 17:16, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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.
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Henrik Johansen -
Henrik Sperre Johansen
-
Igor Stasenko -
Schwab,Wilhelm K -
Stéphane Ducasse