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 |
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 |
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 > (ascent+descent)? the line grid (from a baseline to the next)? Why for Freetype, 12 points meanse 15+4 pixels? Cheers, Juan Vuletich |
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 |
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)? 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 |
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 |
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 |
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 |
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:
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. |
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 > > > |
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 |
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:
-- Ron |
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. > 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 |
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 |
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 - |
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 > > ------------------------------------------------------------------------ > |
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 |
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! |
Free forum by Nabble | Edit this page |