[squeak-dev] Cuis font sizes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Cuis font sizes

Andreas.Raab
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

[1] http://www.emdpi.com/emsquare.html

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Juan Vuletich-4
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
>
> [1] http://www.emdpi.com/emsquare.html

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Juan Vuletich-4
In reply to this post by Juan Vuletich-4
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Bert Freudenberg
In reply to this post by Juan Vuletich-4

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 -





Picture 11.png (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Cuis font sizes

Andreas.Raab
In reply to this post by Juan Vuletich-4
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



DejaVu9pt.png (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

K. K. Subramaniam
In reply to this post by Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

David T. Lewis
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

Reply | Threaded
Open this post in threaded view
|

RE: [squeak-dev] Cuis font sizes

Andrew Tween
In reply to this post by Andreas.Raab
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: [hidden email]
> To: [hidden email]
> 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
>
> [1] http://www.emdpi.com/emsquare.html
>


View your other email accounts from your Hotmail inbox. Add them now.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Nicolas Cellier
In reply to this post by David T. Lewis
I thought it was 72.27

Nicolas

2009/8/29 David T. Lewis <[hidden email]>:

> 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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

David T. Lewis
On Sun, Aug 30, 2009 at 10:12:06PM +0200, Nicolas Cellier wrote:

>
> 2009/8/29 David T. Lewis <[hidden email]>:
> > 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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Casey Ransberger
In reply to this post by K. K. Subramaniam
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 <[hidden email]> 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 <a href="http://ilovetypography.com/2008/03/23/sunday-type- bright-type/" target="_blank">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




--
Ron


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Tobias Pape
In reply to this post by David T. Lewis

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





PGP.sig (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

K. K. Subramaniam
In reply to this post by Casey Ransberger
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

Bert Freudenberg
In reply to this post by Tobias Pape

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 -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Cuis font sizes

Juan Vuletich-4
In reply to this post by Andreas.Raab
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
>
> ------------------------------------------------------------------------
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

K. K. Subramaniam
In reply to this post by Casey Ransberger
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Cuis font sizes

David T. Lewis
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!