Hi Juan -
This is mostly to Juan but others might be able to help as well. I noticed that the Cuis fonts disagree in their pixel sizes significantly with that we get from the plain DejaVu true type fonts in Squeak. A bit of math reveals that at the (assumed) screen resolution of 96dpi a 12pt font should result in 16px high font (12*96/72 see Eqn. 3 in [1]). The corresponding Bitmap DejaVu 12pt font, however, is 19px high which would mean a screen resolution of 114dpi (19*72/12).
Is this choice intentional? Unfortunately, none of the pixel sizes for Bitmap DejaVu correspond exactly to a point size when assuming 96dpi.
The reason this is causing me grief is that I am trying to set up a mechanism for allowing people to drop the DejaVu fonts into their images and have any glyphs not part of the cuis fonts rendered in DejaVu truetype instead. I can probably get the truetype rendering to spit out a precise pixel size to match it but I think it'd be good if we had clarity on how these pixel sizes came into being.
Any insights appreciated!
Cheers, - Andreas
Hi Andreas,
Andreas Raab wrote:
Hi Juan -
This is mostly to Juan but others might be able to help as well. I noticed that the Cuis fonts disagree in their pixel sizes significantly with that we get from the plain DejaVu true type fonts in Squeak. A bit of math reveals that at the (assumed) screen resolution of 96dpi a 12pt font should result in 16px high font (12*96/72 see Eqn. 3 in [1]). The corresponding Bitmap DejaVu 12pt font, however, is 19px high which would mean a screen resolution of 114dpi (19*72/12).
Is this choice intentional? Unfortunately, none of the pixel sizes for Bitmap DejaVu correspond exactly to a point size when assuming 96dpi.
The BitmapDejaVu 12 has the glyphs rendered by FreeType when requested for 12 pt. In those glyphs, the H (for example) is 12 pixels high. Max ascent for uppercase letters with Latin umlauts is 15 pixels. Max descent in those glyphs is 4. Therefore instances of BitmapDejaVu 12 StrikeFont answer 15 to #ascent, 4 to #descent and 19 (15+4) to #height.
I never found a clear specification of the meaning of '12 point', and I'm totally for making the fonts behave properly. So, the first question is: Are the glyphs correct? I mean, are the glyphs for DejaVu 12 rendered by Squeak TTF and Freetype the same size? If so, how does Squeak TTF fit glyphs that might need up to 19 pixels (15+4) in 16? I suspect that FreeType and Squeak TTF don't agree on the meaning of point size, but I don't have time right now for checking.
I'll have time for this on Monday. I guess the first thing to do is to understand what is the correct font for '12 point'. I mean, the correct ascent/descent and line grid, and the correct shape of the glyphs. Some specification of mean kerning / length of strings would be nice too. I'll read the link you sent. I want to understand and get this right!
The reason this is causing me grief is that I am trying to set up a mechanism for allowing people to drop the DejaVu fonts into their images and have any glyphs not part of the cuis fonts rendered in DejaVu truetype instead. I can probably get the truetype rendering to spit out a precise pixel size to match it but I think it'd be good if we had clarity on how these pixel sizes came into being.
BTW, when mixing TTF and StrikeFonts there might be differences in line spacing and kerning, besides mating the baseline, ascent and descent. These might be visible... and perhaps need fixing to to make it look nice.
Finally, any reason not to use FreeType? It looks like a good alternative for Unicode.
Any insights appreciated!
Cheers,
- Andreas
Cheers, Juan Vuletich
On Sat, Aug 29, 2009 at 12:18:18PM -0300, Juan Vuletich wrote:
I never found a clear specification of the meaning of '12 point', and I'm totally for making the fonts behave properly.
http://en.wikipedia.org/wiki/Point_(typography)
72 points = 1 inch
Dave
David T. Lewis wrote:
On Sat, Aug 29, 2009 at 12:18:18PM -0300, Juan Vuletich wrote:
I never found a clear specification of the meaning of '12 point', and I'm totally for making the fonts behave properly.
http://en.wikipedia.org/wiki/Point_(typography)
72 points = 1 inch
Dave
I know that, but those 12 points are the ascent? the height (ascent+descent)? the line grid (from a baseline to the next)? Why for Freetype, 12 points meanse 15+4 pixels?
Cheers, Juan Vuletich
On 29.08.2009, at 19:13, Juan Vuletich wrote:
David T. Lewis wrote:
On Sat, Aug 29, 2009 at 12:18:18PM -0300, Juan Vuletich wrote:
I never found a clear specification of the meaning of '12 point', and I'm totally for making the fonts behave properly.
http://en.wikipedia.org/wiki/Point_(typography)
72 points = 1 inch
Dave
I know that, but those 12 points are the ascent? the height (ascent +descent)? the line grid (from a baseline to the next)?
It's the size of the em square. The site linked by Andreas explains it quite well:
http://www.emdpi.com/emsquare.html
Why for Freetype, 12 points meanse 15+4 pixels?
It does not. It depends on both the font and the dpi settings. E.g. this is a sample of Helvetica, Times, and Zapfino, as rendered by Quartz 2D, at size 12:
As you can see, Times appears significantly smaller than Helvetica, while Zapfino appears much larger. However, the em square is the same. It's up to the font designer.
But the dpi setting is up to us. You should use TextStyle>>pointsToPixels: to get the em square size in pixels from the font point size. This defaults to 96 dpi but can be changed. Most of the system uses that, the only offender I'm aware of is TTCFontSet>>pointSize which hard-codes 96 dpi. And there might be some that use the size as is rather than properly converting.
- Bert -
I thought it was 72.27
Nicolas
2009/8/29 David T. Lewis lewis@mail.msen.com:
On Sat, Aug 29, 2009 at 12:18:18PM -0300, Juan Vuletich wrote:
I never found a clear specification of the meaning of '12 point', and I'm totally for making the fonts behave properly.
http://en.wikipedia.org/wiki/Point_(typography)
72 points = 1 inch
Dave
On Sun, Aug 30, 2009 at 10:12:06PM +0200, Nicolas Cellier wrote:
2009/8/29 David T. Lewis lewis@mail.msen.com:
On Sat, Aug 29, 2009 at 12:18:18PM -0300, Juan Vuletich wrote:
I never found a clear specification of the meaning of ?'12 point', and I'm totally for making the fonts behave properly.
http://en.wikipedia.org/wiki/Point_(typography)
72 points = 1 inch
I thought it was 72.27
Nicolas,
You are absolutely right. The discrepancy is apparently due to my having less than four significant figures worth of linear precision on my computer screen ;-)
Thanks for the correction, also noted in Subbu's excellent reply earlier today.
Dave
Am 2009-08-31 um 02:35 schrieb David T. Lewis:
On Sun, Aug 30, 2009 at 10:12:06PM +0200, Nicolas Cellier wrote:
[…]
http://en.wikipedia.org/wiki/Point_(typography)
72 points = 1 inch
I thought it was 72.27
Nicolas,
You are absolutely right. The discrepancy is apparently due to my having less than four significant figures worth of linear precision on my computer screen ;-)
Thanks for the correction, also noted in Subbu's excellent reply earlier today.
Didn’t know you were hot-metal typesetters ;) But, no kidding, an inch is both equal 72.27 _and_ equal 72 Point. Refer to the already mentioned Wikipedia article; TeX and hot-metal- (i.e. traditional) typesetting, are using a 72.27 pt = 1 in relation, whereas PostScript is using the rounded 72 pt = 1 in. The WP article states, that the latter is the now more common def- inition of a Point. By the way, which system is Squeak (Freetype?) using?
So Long, -Tobias
On 31.08.2009, at 08:28, Tobias Pape wrote:
Am 2009-08-31 um 02:35 schrieb David T. Lewis:
On Sun, Aug 30, 2009 at 10:12:06PM +0200, Nicolas Cellier wrote:
[…]
http://en.wikipedia.org/wiki/Point_(typography)
72 points = 1 inch
I thought it was 72.27
Nicolas,
You are absolutely right. The discrepancy is apparently due to my having less than four significant figures worth of linear precision on my computer screen ;-)
Thanks for the correction, also noted in Subbu's excellent reply earlier today.
Didn’t know you were hot-metal typesetters ;) But, no kidding, an inch is both equal 72.27 _and_ equal 72 Point. Refer to the already mentioned Wikipedia article; TeX and hot-metal- (i.e. traditional) typesetting, are using a 72.27 pt = 1 in relation, whereas PostScript is using the rounded 72 pt = 1 in. The WP article states, that the latter is the now more common def- inition of a Point. By the way, which system is Squeak (Freetype?) using?
The digital typography one, i.e., 72.
- Bert -
Juan Vuletich wrote:
Hi Andreas,
Andreas Raab wrote:
Hi Juan -
This is mostly to Juan but others might be able to help as well. I noticed that the Cuis fonts disagree in their pixel sizes significantly with that we get from the plain DejaVu true type fonts in Squeak. A bit of math reveals that at the (assumed) screen resolution of 96dpi a 12pt font should result in 16px high font (12*96/72 see Eqn. 3 in [1]). The corresponding Bitmap DejaVu 12pt font, however, is 19px high which would mean a screen resolution of 114dpi (19*72/12).
Is this choice intentional? Unfortunately, none of the pixel sizes for Bitmap DejaVu correspond exactly to a point size when assuming 96dpi.
The BitmapDejaVu 12 has the glyphs rendered by FreeType when requested for 12 pt. In those glyphs, the H (for example) is 12 pixels high. Max ascent for uppercase letters with Latin umlauts is 15 pixels. Max descent in those glyphs is 4. Therefore instances of BitmapDejaVu 12 StrikeFont answer 15 to #ascent, 4 to #descent and 19 (15+4) to #height.
I never found a clear specification of the meaning of '12 point', and I'm totally for making the fonts behave properly. So, the first question is: Are the glyphs correct? I mean, are the glyphs for DejaVu 12 rendered by Squeak TTF and Freetype the same size? If so, how does Squeak TTF fit glyphs that might need up to 19 pixels (15+4) in 16? I suspect that FreeType and Squeak TTF don't agree on the meaning of point size, but I don't have time right now for checking.
I'll have time for this on Monday. I guess the first thing to do is to understand what is the correct font for '12 point'. I mean, the correct ascent/descent and line grid, and the correct shape of the glyphs. Some specification of mean kerning / length of strings would be nice too. I'll read the link you sent. I want to understand and get this right!
According to http://www.emdpi.com/fontsize.html , the example *"Arial 12pt at 96 dpi:"*a 12pt font at 96 dpi should have a "font size" of 16 pixels, but a "font height" of 18 and not 16... I guess neither TTF nor FreeType got it right...
Cheers, Juan Vuletich
Juan Vuletich wrote:
I never found a clear specification of the meaning of '12 point', and I'm totally for making the fonts behave properly. So, the first question is: Are the glyphs correct? I mean, are the glyphs for DejaVu 12 rendered by Squeak TTF and Freetype the same size? If so, how does Squeak TTF fit glyphs that might need up to 19 pixels (15+4) in 16? I suspect that FreeType and Squeak TTF don't agree on the meaning of point size, but I don't have time right now for checking.
Okay, I figured it out. It turns out that for computing the line spacing one needs to use the OS/2 table from the truetype font if present. What confused me was that DejaVu Sans had a linegap (leading) of zero in its horizontal header table which *should* make things very easy. Except that in its OS/2 table it has a non-zero linegap/leading. If we use the values from that table we end up with the right sizes but it seems that for rendering we then need to use the "original" values (from the hhea table). With these issues addressed, the bitmap and the outline versions are virtually indistinguishable in size and spacing (see screenshot).
BTW, when mixing TTF and StrikeFonts there might be differences in line spacing and kerning, besides mating the baseline, ascent and descent. These might be visible... and perhaps need fixing to to make it look nice.
It looks quite reasonable in my tests. You can take a word and replace just one character with the corresponding font and it looks fine. I'm mostly interested in covering the glyph ranges that are outside Latin-1.
Finally, any reason not to use FreeType? It looks like a good alternative for Unicode.
No particular reason other than that I like this font stuff, and that I think that carrying 500k for a plugin out of which you only use the auto-hinter is kinda insane ;-) Seriously, if someone would port the auto-hinter we could make fonts that are every bit as good as Freetype.
But it's still an interesting idea and I should check it out to see how different (or not) things are.
Cheers, - Andreas
Hi Andreas,
Andreas Raab wrote:
Okay, I figured it out. It turns out that for computing the line spacing one needs to use the OS/2 table from the truetype font if present. What confused me was that DejaVu Sans had a linegap (leading) of zero in its horizontal header table which *should* make things very easy. Except that in its OS/2 table it has a non-zero linegap/leading. If we use the values from that table we end up with the right sizes but it seems that for rendering we then need to use the "original" values (from the hhea table). With these issues addressed, the bitmap and the outline versions are virtually indistinguishable in size and spacing (see screenshot).
Great! Anyway if you happen to find some problem with the StrikeFonts, I'll be happy to help.
BTW, when mixing TTF and StrikeFonts there might be differences in line spacing and kerning, besides mating the baseline, ascent and descent. These might be visible... and perhaps need fixing to to make it look nice.
It looks quite reasonable in my tests. You can take a word and replace just one character with the corresponding font and it looks fine. I'm mostly interested in covering the glyph ranges that are outside Latin-1.
Good!
Cheers, Juan Vuletich
Finally, any reason not to use FreeType? It looks like a good alternative for Unicode.
No particular reason other than that I like this font stuff, and that I think that carrying 500k for a plugin out of which you only use the auto-hinter is kinda insane ;-) Seriously, if someone would port the auto-hinter we could make fonts that are every bit as good as Freetype.
But it's still an interesting idea and I should check it out to see how different (or not) things are.
Cheers,
- Andreas
On Saturday 29 Aug 2009 8:48:18 pm Juan Vuletich wrote:
I'll have time for this on Monday. I guess the first thing to do is to understand what is the correct font for '12 point'. I mean, the correct ascent/descent and line grid, and the correct shape of the glyphs. Some specification of mean kerning / length of strings would be nice too.
In traditional typography, the point referred to the size of the metal block used to carve shapes (glyphs). The size of a Point depended on regional/political affiliations :-). Anglo-american point was about 72.27 points to an inch. Not all shapes would be contained within its metal block base. Some (see g in the picture http://ilovetypography.com/2008/03/23/sunday-type- bright-type/) would also extend (kern) beyond its base. String length would be the sum of metal block widths. The sum of shape widths in a run of characters could differ from the string length due to kerns.
Digital typography uses co-ordinate grids instead of a metal block. It defines Point (aka DTP point or Postscript point) as 1/72th of an inch. Grid size varies for different fonts. TTF uses grids of 512, 1024 or 2048. The point size used in font names are 'design size'. i.e. a modern 12pt TTF contains glyphs drawn inside a 2048x2048 grid that will *look like* a 12pt metal typeface when scaled to various digital canvases like a 96dpi screen or 1200 dpi printer.
Though we continue using the term 'glyph' (carving), images are computed on the grid using a 'pictal' process and then scaled to the target canvas. A Truetype font is actually a bytecode program interpreted by a font engine (e.g. Freetype) to scale glyphs at run time. Internally, glyphs are defined in terms of lines and curves in a grid (called em-square) of size 512, 1024 or 2048. Given a canvas (dpi, depth), a glyph code and a point size "hint", the font engine will scale a glyph and tweak them using 'hints' expressed in bytecodes. For instance, stretching a '(' vertically may scale only the middle part and leave the tips alone. The o in "xo" will slightly overshoot x for good visual flow.
However, aesthetic rendering requires a context and a run of characters. The spacing between one character to the next is dictated by kern and direction. Sometimes, adjacent glyphs may coalesce into a more compact or even different shape (e.g. ffi) called a ligature. Runs are handled by a text rendering engine (e.g. Pango, Qt, ghostscript). Of course, the ligated glyph shape should exist in the font.
Squeak's text printing algorithms only consider boxes and kerns - no ligatures, no hyphenation, no direction. Building a true multilingual layout engine is a non-trivial task. Mac and Wintel have only one shaping engine while Linux has multiple options (Pango, Qt, ICU, m17n, Graphite). Pango and Qt are widely used. Squeak should be able detect and load shaping engines on the fly on Linux or allow command line options to pick a wrapper plugin.
There is also the blue plane approach proposed in FoNC paper - treat text boxes like graphic objects. A Font engine is just a specialized vector graphic editor that avoids intensive geometric computations by caching precomputed shapes in a glyph table. Allow graphic objects to have class level editors. Then when a glyph is missing for a character code, open a glyph editor and allow a new shape to be defined on the fly or imported from a public font definition file. Beats displaying $?.
Subbu
Subbu,
Thanks for this excellent overview of fonts. I've never seen this topic explained clearly in one place before.
Dave
On Sun, Aug 30, 2009 at 04:13:00PM +0530, K. K. Subramaniam wrote:
On Saturday 29 Aug 2009 8:48:18 pm Juan Vuletich wrote:
I'll have time for this on Monday. I guess the first thing to do is to understand what is the correct font for '12 point'. I mean, the correct ascent/descent and line grid, and the correct shape of the glyphs. Some specification of mean kerning / length of strings would be nice too.
In traditional typography, the point referred to the size of the metal block used to carve shapes (glyphs). The size of a Point depended on regional/political affiliations :-). Anglo-american point was about 72.27 points to an inch. Not all shapes would be contained within its metal block base. Some (see g in the picture http://ilovetypography.com/2008/03/23/sunday-type- bright-type/) would also extend (kern) beyond its base. String length would be the sum of metal block widths. The sum of shape widths in a run of characters could differ from the string length due to kerns.
Digital typography uses co-ordinate grids instead of a metal block. It defines Point (aka DTP point or Postscript point) as 1/72th of an inch. Grid size varies for different fonts. TTF uses grids of 512, 1024 or 2048. The point size used in font names are 'design size'. i.e. a modern 12pt TTF contains glyphs drawn inside a 2048x2048 grid that will *look like* a 12pt metal typeface when scaled to various digital canvases like a 96dpi screen or 1200 dpi printer.
Though we continue using the term 'glyph' (carving), images are computed on the grid using a 'pictal' process and then scaled to the target canvas. A Truetype font is actually a bytecode program interpreted by a font engine (e.g. Freetype) to scale glyphs at run time. Internally, glyphs are defined in terms of lines and curves in a grid (called em-square) of size 512, 1024 or 2048. Given a canvas (dpi, depth), a glyph code and a point size "hint", the font engine will scale a glyph and tweak them using 'hints' expressed in bytecodes. For instance, stretching a '(' vertically may scale only the middle part and leave the tips alone. The o in "xo" will slightly overshoot x for good visual flow.
However, aesthetic rendering requires a context and a run of characters. The spacing between one character to the next is dictated by kern and direction. Sometimes, adjacent glyphs may coalesce into a more compact or even different shape (e.g. ffi) called a ligature. Runs are handled by a text rendering engine (e.g. Pango, Qt, ghostscript). Of course, the ligated glyph shape should exist in the font.
Squeak's text printing algorithms only consider boxes and kerns - no ligatures, no hyphenation, no direction. Building a true multilingual layout engine is a non-trivial task. Mac and Wintel have only one shaping engine while Linux has multiple options (Pango, Qt, ICU, m17n, Graphite). Pango and Qt are widely used. Squeak should be able detect and load shaping engines on the fly on Linux or allow command line options to pick a wrapper plugin.
There is also the blue plane approach proposed in FoNC paper - treat text boxes like graphic objects. A Font engine is just a specialized vector graphic editor that avoids intensive geometric computations by caching precomputed shapes in a glyph table. Allow graphic objects to have class level editors. Then when a glyph is missing for a character code, open a glyph editor and allow a new shape to be defined on the fly or imported from a public font definition file. Beats displaying $?.
Subbu
Thank you; you should put this on a wiki or a blog somewhere. If you don't have time, I would gladly do that for you (and of course put your name on it.) This is some really good writing, and I really appreciate the work. It's easy to lose track of historical context amongst all of the ones and zeros. Thank you.
On Sun, Aug 30, 2009 at 3:43 AM, K. K. Subramaniam subbukk@gmail.comwrote:
On Saturday 29 Aug 2009 8:48:18 pm Juan Vuletich wrote:
I'll have time for this on Monday. I guess the first thing to do is to understand what is the correct font for '12 point'. I mean, the correct ascent/descent and line grid, and the correct shape of the glyphs. Some specification of mean kerning / length of strings would be nice too.
In traditional typography, the point referred to the size of the metal block used to carve shapes (glyphs). The size of a Point depended on regional/political affiliations :-). Anglo-american point was about 72.27 points to an inch. Not all shapes would be contained within its metal block base. Some (see g in the picture http://ilovetypography.com/2008/03/23/sunday-type- bright-type/) would also extend (kern) beyond its base. String length would be the sum of metal block widths. The sum of shape widths in a run of characters could differ from the string length due to kerns.
Digital typography uses co-ordinate grids instead of a metal block. It defines Point (aka DTP point or Postscript point) as 1/72th of an inch. Grid size varies for different fonts. TTF uses grids of 512, 1024 or 2048. The point size used in font names are 'design size'. i.e. a modern 12pt TTF contains glyphs drawn inside a 2048x2048 grid that will *look like* a 12pt metal typeface when scaled to various digital canvases like a 96dpi screen or 1200 dpi printer.
Though we continue using the term 'glyph' (carving), images are computed on the grid using a 'pictal' process and then scaled to the target canvas. A Truetype font is actually a bytecode program interpreted by a font engine (e.g. Freetype) to scale glyphs at run time. Internally, glyphs are defined in terms of lines and curves in a grid (called em-square) of size 512, 1024 or 2048. Given a canvas (dpi, depth), a glyph code and a point size "hint", the font engine will scale a glyph and tweak them using 'hints' expressed in bytecodes. For instance, stretching a '(' vertically may scale only the middle part and leave the tips alone. The o in "xo" will slightly overshoot x for good visual flow.
However, aesthetic rendering requires a context and a run of characters. The spacing between one character to the next is dictated by kern and direction. Sometimes, adjacent glyphs may coalesce into a more compact or even different shape (e.g. ffi) called a ligature. Runs are handled by a text rendering engine (e.g. Pango, Qt, ghostscript). Of course, the ligated glyph shape should exist in the font.
Squeak's text printing algorithms only consider boxes and kerns - no ligatures, no hyphenation, no direction. Building a true multilingual layout engine is a non-trivial task. Mac and Wintel have only one shaping engine while Linux has multiple options (Pango, Qt, ICU, m17n, Graphite). Pango and Qt are widely used. Squeak should be able detect and load shaping engines on the fly on Linux or allow command line options to pick a wrapper plugin.
There is also the blue plane approach proposed in FoNC paper - treat text boxes like graphic objects. A Font engine is just a specialized vector graphic editor that avoids intensive geometric computations by caching precomputed shapes in a glyph table. Allow graphic objects to have class level editors. Then when a glyph is missing for a character code, open a glyph editor and allow a new shape to be defined on the fly or imported from a public font definition file. Beats displaying $?.
Subbu
On Monday 31 Aug 2009 11:50:14 am Ronald Spengler wrote:
Thank you; you should put this on a wiki or a blog somewhere. If you don't have time, I would gladly do that for you (and of course put your name on it.) This is some really good writing, and I really appreciate the work. It's easy to lose track of historical context amongst all of the ones and zeros.
Please go ahead. I will be out of town (off-net) for the next couple of days and really appreciate your offer.
Subbu
On Monday 31 Aug 2009 11:50:14 am Ronald Spengler wrote:
Thank you; you should put this on a wiki or a blog somewhere. If you don't have time, I would gladly do that for you (and of course put your name on it.) This is some really good writing, and I really appreciate the work. It's easy to lose track of historical context amongst all of the ones and zeros.
http://wiki.squeak.org/squeak/6144
My first swiki entry, Subbu
On Fri, Sep 04, 2009 at 10:59:30PM +0530, K. K. Subramaniam wrote:
On Monday 31 Aug 2009 11:50:14 am Ronald Spengler wrote:
Thank you; you should put this on a wiki or a blog somewhere. If you don't have time, I would gladly do that for you (and of course put your name on it.) This is some really good writing, and I really appreciate the work. It's easy to lose track of historical context amongst all of the ones and zeros.
http://wiki.squeak.org/squeak/6144
My first swiki entry, Subbu
Great, thank you!
Hi Andreas,
I think the problem with the size discrepency results from the scaling factor used in TTCFont computeForm:
FreeType divides the pixel size by the units per em , but TTCFont divides by (ttcDescription ascender - ttcDescription descender).
Try making TTCFont>>computeForm: use the unitsPerEm value instead, it appears to give the correct size glyphs. i.e. ...
computeForm: char
| ttGlyph scale | scale := self pixelSize asFloat / ttcDescription unitsPerEm. Scale ifNotNil: [scale := Scale * scale].
etc.
This is from the FreeType manual page http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-2.html ...
<quote>
In creating the glyph outlines, a type designer uses an imaginary square called the EM square. Typically, the EM square can be thought of as a tablet on which the characters are drawn. The square's size, i.e., the number of grid units on its sides, is very important for two reasons:
It is the reference used to scale the outlines to a given text dimension. For example, a size of 12pt at 300x300 dpi corresponds to 12*300/72 = 50 pixels. This is the size the EM square would appear on the output device if it was rendered directly. In other words, scaling from grid units to pixels uses the formula:
pixel_size = point_size * resolution / 72 pixel_coord = grid_coord * pixel_size / EM_size
</quote>
Line spacing is a separate issue; it is there that the ascender, descender, and other vertical metrics become important .
Cheers,
Andy
.
Date: Fri, 28 Aug 2009 20:22:19 -0700 From: andreas.raab@gmx.de To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Cuis font sizes
Hi Juan -
This is mostly to Juan but others might be able to help as well. I noticed that the Cuis fonts disagree in their pixel sizes significantly with that we get from the plain DejaVu true type fonts in Squeak. A bit of math reveals that at the (assumed) screen resolution of 96dpi a 12pt font should result in 16px high font (12*96/72 see Eqn. 3 in [1]). The corresponding Bitmap DejaVu 12pt font, however, is 19px high which would mean a screen resolution of 114dpi (19*72/12).
Is this choice intentional? Unfortunately, none of the pixel sizes for Bitmap DejaVu correspond exactly to a point size when assuming 96dpi.
The reason this is causing me grief is that I am trying to set up a mechanism for allowing people to drop the DejaVu fonts into their images and have any glyphs not part of the cuis fonts rendered in DejaVu truetype instead. I can probably get the truetype rendering to spit out a precise pixel size to match it but I think it'd be good if we had clarity on how these pixel sizes came into being.
Any insights appreciated!
Cheers,
- Andreas
_________________________________________________________________ View your other email accounts from your Hotmail inbox. Add them now. http://clk.atdmt.com/UKM/go/167688463/direct/01/
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andrew Tween -
Bert Freudenberg -
David T. Lewis -
Juan Vuletich -
K. K. Subramaniam -
Nicolas Cellier -
Ronald Spengler -
Tobias Pape