From: <pra...@gm...> - 2012-09-29 06:22:41
|
Hi, I have downloaded https://googlefontdirectory.googlecode.com/hg/ofl/cousine/ Cousine-Regular.ttf and saved as .sfd and regenerated ttf from it. But regenerated font does not get recognized as a Monospace in Windows http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty.exe While the original downloaded font get recognized there properly. What might be going wrong while saving it as .sfd and regenerating .ttf? Regenerated font http://pravins.fedorapeople.org/Test-Cousine.ttf Let me know if anything additional information required. fontforge-20110222 used for this. Thanks, Pravin Satpute |
From: Khaled H. <kha...@eg...> - 2012-09-29 10:38:57
|
On Sat, Sep 29, 2012 at 11:52:33AM +0530, pra...@gm... wrote: > Hi, > > I have downloaded https://googlefontdirectory.googlecode.com/hg/ofl/cousine/ > Cousine-Regular.ttf and saved as .sfd and regenerated ttf from it. But > regenerated font does not get recognized as a Monospace in Windows http:// > www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty.exe > While the original downloaded font get recognized there properly. > > What might be going wrong while saving it as .sfd and regenerating .ttf? > > Regenerated font http://pravins.fedorapeople.org/Test-Cousine.ttf The original font has the isFixedPitch bit in post table set which it seems used by some application to recognise monospace fonts (though this, arguably, is wrong, there is no requirement that all monnospace fonts set it). Per the spec, isFixedPitch is only set when all glyphs in the font have the same width, but the font has a zero width ".null" glyph, so FontForge does not set isFixedPitch when generating the font (which is the right thing to do, some applications is know to behave wrongly with such a font). Removing that glyph (which seems to serve no purpose and was probably auto inserted by the tool generating the font), should do the trick. Regards, Khaled |
From: <pra...@gm...> - 2012-10-01 09:32:27
|
On 29 September 2012 16:08, Khaled Hosny <kha...@eg...> wrote: > On Sat, Sep 29, 2012 at 11:52:33AM +0530, pra...@gm... wrote: > > Hi, > > > > I have downloaded > https://googlefontdirectory.googlecode.com/hg/ofl/cousine/ > > Cousine-Regular.ttf and saved as .sfd and regenerated ttf from it. But > > regenerated font does not get recognized as a Monospace in Windows > http:// > > www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty.exe > > While the original downloaded font get recognized there properly. > > > > What might be going wrong while saving it as .sfd and regenerating > .ttf? > > > > Regenerated font http://pravins.fedorapeople.org/Test-Cousine.ttf > > The original font has the isFixedPitch bit in post table set which it > seems used by some application to recognise monospace fonts (though > this, arguably, is wrong, there is no requirement that all monnospace > fonts set it). Per the spec, isFixedPitch is only set when all glyphs in > the font have the same width, but the font has a zero width ".null" > glyph, so FontForge does not set isFixedPitch when generating the font > (which is the right thing to do, some applications is know to behave > wrongly with such a font). > > Removing that glyph (which seems to serve no purpose and was probably > auto inserted by the tool generating the font), should do the trick. > Converting Cousine-Regular.ttf to .sfd and $cat Cousine.sfd |grep "Width: 0"|wc -l 267 We have lots of Zero width characters in Cousine-Regular fonts and removing them looks not good solution. Do we have any other alternative to Set isFixedPitch bit? Thanks, Pravin Satpute |
From: Khaled H. <kha...@eg...> - 2012-10-01 13:14:17
|
On Mon, Oct 01, 2012 at 03:02:15PM +0530, pra...@gm... wrote: > > > On 29 September 2012 16:08, Khaled Hosny <kha...@eg...> wrote: > > On Sat, Sep 29, 2012 at 11:52:33AM +0530, pra...@gm... wrote: > > Hi, > > > > I have downloaded https://googlefontdirectory.googlecode.com/hg/ofl/ > cousine/ > > Cousine-Regular.ttf and saved as .sfd and regenerated ttf from it. But > > regenerated font does not get recognized as a Monospace in Windows http:/ > / > > www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty.exe > > While the original downloaded font get recognized there properly. > > > > What might be going wrong while saving it as .sfd and regenerating > .ttf? > > > > Regenerated font http://pravins.fedorapeople.org/Test-Cousine.ttf > > The original font has the isFixedPitch bit in post table set which it > seems used by some application to recognise monospace fonts (though > this, arguably, is wrong, there is no requirement that all monnospace > fonts set it). Per the spec, isFixedPitch is only set when all glyphs in > the font have the same width, but the font has a zero width ".null" > glyph, so FontForge does not set isFixedPitch when generating the font > (which is the right thing to do, some applications is know to behave > wrongly with such a font). > > Removing that glyph (which seems to serve no purpose and was probably > auto inserted by the tool generating the font), should do the trick. > > > Converting Cousine-Regular.ttf to .sfd and > > $cat Cousine.sfd |grep "Width: 0"|wc -l > 267 The font you linked to have only a single zero with glyph, .null. > We have lots of Zero width characters in Cousine-Regular fonts and removing > them looks not good solution. > > Do we have any other alternative to Set isFixedPitch bit? Check how DejaVu Sans Mono is doing it. Regards, Khaled |
From: <pra...@gm...> - 2012-10-01 11:18:24
|
On 1 October 2012 15:02, pra...@gm... <pra...@gm...> wrote: > > > On 29 September 2012 16:08, Khaled Hosny <kha...@eg...> wrote: > >> On Sat, Sep 29, 2012 at 11:52:33AM +0530, pra...@gm... wrote: >> > Hi, >> > >> > I have downloaded >> https://googlefontdirectory.googlecode.com/hg/ofl/cousine/ >> > Cousine-Regular.ttf and saved as .sfd and regenerated ttf from it. But >> > regenerated font does not get recognized as a Monospace in Windows >> http:// >> > www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty.exe >> > While the original downloaded font get recognized there properly. >> > >> > What might be going wrong while saving it as .sfd and regenerating >> .ttf? >> > >> > Regenerated font http://pravins.fedorapeople.org/Test-Cousine.ttf >> >> The original font has the isFixedPitch bit in post table set which it >> seems used by some application to recognise monospace fonts (though >> this, arguably, is wrong, there is no requirement that all monnospace >> fonts set it). Per the spec, isFixedPitch is only set when all glyphs in >> the font have the same width, but the font has a zero width ".null" >> glyph, so FontForge does not set isFixedPitch when generating the font >> (which is the right thing to do, some applications is know to behave >> wrongly with such a font). >> >> Removing that glyph (which seems to serve no purpose and was probably >> auto inserted by the tool generating the font), should do the trick. >> > > Converting Cousine-Regular.ttf to .sfd and > > $cat Cousine.sfd |grep "Width: 0"|wc -l > 267 > > We have lots of Zero width characters in Cousine-Regular fonts and > removing them looks not good solution. > > Do we have any other alternative to Set isFixedPitch bit? > While more analysis i found that 0 width is assigned to most of the marks characters. 1. In my humble opinion it is valid. We can not assign equal Width same as Base characters to Marks character. Font with "Decided Fixed width" or "0 Width" characters should be considered as a Monospace. 2. Other reasons is compatibility with other font editors. Thanks, Pravin Satpute |
From: Paul F. W. <pa...@fr...> - 2012-10-01 11:55:13
|
pra...@gm... wrote: > > Converting Cousine-Regular.ttf to .sfd and > > $cat Cousine.sfd |grep "Width: 0"|wc -l > 267 > > We have lots of Zero width characters in Cousine-Regular fonts and > removing > them looks not good solution. > > Do we have any other alternative to Set isFixedPitch bit? PuTTY is known to have a problem when isFixedPitch is zero. As Khaled says, isFixedPitch should only be set non zero when all characters have the same advance width. (It matters not that it takes a peculiar, non-standard reading of the simple word "or" to come to this conclusion; that is ancient history.) It is probably instructive to see how DejaVu Sans Mono handles this: they manage to set isFixedPitch to one and make everyone happy by setting the width of every single glyph except .notdef to the same value, and then altering the advance width of combining marks in the GPOS table with single adjustment lookups. If you take a look (I used TTX), you'll see the same width of 1323 throughout the hmtx table, and then in GPOS you'll see the XAdvanceWidth lookups cancel this out with -1323. -- Paul Flo Williams http://hisdeedsaredust.com |
From: <ms...@an...> - 2012-10-01 12:26:12
|
On Sat, 29 Sep 2012, Khaled Hosny wrote: > fonts set it). Per the spec, isFixedPitch is only set when all glyphs in > the font have the same width, but the font has a zero width ".null" Apple's documentation at https://developer.apple.com/fonts/TTRefMan/RM06/Chap6post.html describes the flag as applying when "all glyphs have the same horizontal width at all point sizes (that is, in the 'hmtx' and 'hdmx' tables), or have zero width."; that is exactly the situation here. Microsoft's documentation at http://www.microsoft.com/typography/otspec/post.htm says it applies to "monospace" fonts but doesn't seem to define what "monospace" means, leaving the question open. Both these documents are consistent with setting the isFixedPitch flag on a font with some zero-width and some non-zero-width glyphs, but all non-zero widths the same. The Apple document requires setting the flag in this case; the Microsoft document is unclear but does not forbid it. Is there a specific document you are following other than these, that specifically says the flag should NOT be set when all glyphs have the same horizontal width or have zero width? -- Matthew Skala ms...@an... People before principles. http://ansuz.sooke.bc.ca/ |
From: Khaled H. <kha...@eg...> - 2012-10-01 13:37:01
|
On Mon, Oct 01, 2012 at 07:26:04AM -0500, ms...@an... wrote: > On Sat, 29 Sep 2012, Khaled Hosny wrote: > > fonts set it). Per the spec, isFixedPitch is only set when all glyphs in > > the font have the same width, but the font has a zero width ".null" > > Apple's documentation at > https://developer.apple.com/fonts/TTRefMan/RM06/Chap6post.html > describes the flag as applying when "all glyphs have the same horizontal > width at all point sizes (that is, in the 'hmtx' and 'hdmx' tables), or > have zero width."; that is exactly the situation here. Microsoft's That or it totally out of place and makes no sense at all given the original intent of that bit, it was probably added in the "7 April 2000" revision mentioned in the Change Log at the buttom of the page (someone from Apple over the OpenType mailing list mentioned that). > documentation at > http://www.microsoft.com/typography/otspec/post.htm > says it applies to "monospace" fonts but doesn't seem to define what > "monospace" means, leaving the question open. > > Both these documents are consistent with setting the isFixedPitch flag on > a font with some zero-width and some non-zero-width glyphs, but all > non-zero widths the same. The Apple document requires setting the flag in > this case; the Microsoft document is unclear but does not forbid it. Is > there a specific document you are following other than these, that > specifically says the flag should NOT be set when all glyphs have the same > horizontal width or have zero width? They are just vague like everything else in OpenType spec, they specify file format pretty well but not how to use them, and you have to resort to checking widely used implementation on how to interpret the values, which agrees with what GWW was doing with this bit. Regards, Khaled |
From: <ms...@an...> - 2012-10-01 12:37:14
|
On Mon, 1 Oct 2012, Paul Flo Williams wrote: > the same advance width. (It matters not that it takes a peculiar, > non-standard reading of the simple word "or" to come to this conclusion; > that is ancient history.) If we are going to set the flag if and only if all glyphs are strictly the same width, not allowing some to be zero, for compatibility with other software that requires that to be the meaning of the flag, fine. That may be the right thing to do. But I think we should never say that such a meaning for the flag is required by the specification; instead, it is a deliberate choice to break the specification for compatibility with other, broken, software. To claim that this semantic for the flag is a requirement of a specification that actually says something quite different, creates needless confusion when we talk to people who do know what the word "or" means in English and who don't know the ancient history of the question. If we choose not to follow the spec, let's admit it - and mention it in the documentation. -- Matthew Skala ms...@an... People before principles. http://ansuz.sooke.bc.ca/ |
From: Paul F. W. <pa...@fr...> - 2012-10-01 13:09:04
|
ms...@an... wrote: > On Mon, 1 Oct 2012, Paul Flo Williams wrote: >> the same advance width. (It matters not that it takes a peculiar, >> non-standard reading of the simple word "or" to come to this conclusion; >> that is ancient history.) > > If we are going to set the flag if and only if all glyphs are strictly the > same width, not allowing some to be zero, for compatibility with other > software that requires that to be the meaning of the flag, fine. That may > be the right thing to do. But I think we should never say that such a > meaning for the flag is required by the specification; instead, it is a > deliberate choice to break the specification for compatibility with other, > broken, software. To claim that this semantic for the flag is a > requirement of a specification that actually says something quite > different, creates needless confusion when we talk to people who do know > what the word "or" means in English and who don't know the ancient > history of the question. If we choose not to follow the spec, let's > admit it - and mention it in the documentation. I agree with your natural reading of the specification, but this exact same point came up back in March this year when Steve White suggested changing FontForge's behaviour to match it. Khaled said that the particular reading of the specification that FontForge follows had been decided in discussions on the OpenType mailing list a long time ago. Unfortunately, there appears to be no public archive of that list. DejaVu's wiki mentions how they deal with combining diacritical marks in Mono: http://dejavu-fonts.org/wiki/Typography#Combining_Diacritical_Marks I take this to be a good model of how to set isFixedPitch to 1 and have every glyph the same width. -- Paul Flo Williams http://hisdeedsaredust.com |
From: Paul F. W. <pa...@fr...> - 2012-10-01 13:13:38
|
ms...@an... wrote: > > If we choose not to follow the spec, let's > admit it - and mention it in the documentation. I forgot to say "yes" to this bit. If a question has turned up twice in one year, we should certainly point to information on how to answer it quickly the third time! -- Paul Flo Williams http://hisdeedsaredust.com |
From: Khaled H. <kha...@eg...> - 2012-10-01 13:30:51
|
On Mon, Oct 01, 2012 at 07:37:06AM -0500, ms...@an... wrote: > On Mon, 1 Oct 2012, Paul Flo Williams wrote: > > the same advance width. (It matters not that it takes a peculiar, > > non-standard reading of the simple word "or" to come to this conclusion; > > that is ancient history.) > > If we are going to set the flag if and only if all glyphs are strictly the > same width, not allowing some to be zero, for compatibility with other > software that requires that to be the meaning of the flag, fine. That may > be the right thing to do. But I think we should never say that such a > meaning for the flag is required by the specification; instead, it is a > deliberate choice to break the specification for compatibility with other, > broken, software. To claim that this semantic for the flag is a > requirement of a specification that actually says something quite > different, creates needless confusion when we talk to people who do know > what the word "or" means in English and who don't know the ancient > history of the question. If we choose not to follow the spec, let's > admit it - and mention it in the documentation. That 'or' was added by someone at Apple to the spec¹ in a much later date, it wasn’t there originally, and it does not exist in Ms page². isFixedPitch is a remnant of Type1 fonts (that is why it is in the post table not OS/2 or head), and it have the same meaning it had in Type1 spec (which has no or’s). Regards, Khaled ¹ https://developer.apple.com/fonts/TTRefMan/RM06/Chap6post.html ² http://www.microsoft.com/typography/otspec/post.htm |
From: Khaled H. <kha...@eg...> - 2012-10-01 13:21:50
|
On Mon, Oct 01, 2012 at 04:48:16PM +0530, pra...@gm... wrote: > > > On 1 October 2012 15:02, pra...@gm... <pra...@gm...> wrote: > > > > On 29 September 2012 16:08, Khaled Hosny <kha...@eg...> wrote: > > On Sat, Sep 29, 2012 at 11:52:33AM +0530, pra...@gm... wrote: > > Hi, > > > > I have downloaded https://googlefontdirectory.googlecode.com/hg/ofl > /cousine/ > > Cousine-Regular.ttf and saved as .sfd and regenerated ttf from it. > But > > regenerated font does not get recognized as a Monospace in Windows > http:// > > www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty.exe > > While the original downloaded font get recognized there properly. > > > > What might be going wrong while saving it as .sfd and regenerating > .ttf? > > > > Regenerated font http://pravins.fedorapeople.org/Test-Cousine.ttf > > The original font has the isFixedPitch bit in post table set which it > seems used by some application to recognise monospace fonts (though > this, arguably, is wrong, there is no requirement that all monnospace > fonts set it). Per the spec, isFixedPitch is only set when all glyphs > in > the font have the same width, but the font has a zero width ".null" > glyph, so FontForge does not set isFixedPitch when generating the font > (which is the right thing to do, some applications is know to behave > wrongly with such a font). > > Removing that glyph (which seems to serve no purpose and was probably > auto inserted by the tool generating the font), should do the trick. > > > Converting Cousine-Regular.ttf to .sfd and > > $cat Cousine.sfd |grep "Width: 0"|wc -l > 267 > > We have lots of Zero width characters in Cousine-Regular fonts and removing > them looks not good solution. > > Do we have any other alternative to Set isFixedPitch bit? > > > While more analysis i found that 0 width is assigned to most of the marks > characters. > 1. In my humble opinion it is valid. We can not assign equal Width same as Base > characters to Marks character. > Font with "Decided Fixed width" or "0 Width" characters should be considered as > a Monospace. > 2. Other reasons is compatibility with other font editors. The isFixedPitch bit is carried on from Type1 fonts where it really meant all glyphs with no exception have the same width so implementations can just check the width of any glyph, cache it, and assume all other glyphs have the same width, as a form of optimisation in the olden days. Many implementation still does so, now if the font have a zero width glyph and it happens to be the glyph that the implementation checked first, all other glyphs will be treated as if they are zero width, which is not something you want¹. Now if you don’t care about all of this, you can use fontTools python library (or its command line ttx tool) to post process the font and manually set the bit. IMO, applications using isFixedPitch to categorize monospaced fonts in the menus are abusing it. Regards, Khaled ¹ This is not a hypothetical case, there are widely used applications that does so. |
From: <pra...@gm...> - 2012-10-03 04:49:32
|
On 1 October 2012 18:51, Khaled Hosny <kha...@eg...> wrote: > On Mon, Oct 01, 2012 at 04:48:16PM +0530, pra...@gm... wrote: > > > > > > On 1 October 2012 15:02, pra...@gm... <pra...@gm...> > wrote: > > > > > > > > On 29 September 2012 16:08, Khaled Hosny <kha...@eg...> > wrote: > > > > On Sat, Sep 29, 2012 at 11:52:33AM +0530, pra...@gm...wrote: > > > Hi, > > > > > > I have downloaded > https://googlefontdirectory.googlecode.com/hg/ofl > > /cousine/ > > > Cousine-Regular.ttf and saved as .sfd and regenerated ttf from > it. > > But > > > regenerated font does not get recognized as a Monospace in > Windows > > http:// > > > www.chiark.greenend.org.uk/~sgtatham/putty/download.htmlPutty.exe > > > While the original downloaded font get recognized there > properly. > > > > > > What might be going wrong while saving it as .sfd and > regenerating > > .ttf? > > > > > > Regenerated font > http://pravins.fedorapeople.org/Test-Cousine.ttf > > > > The original font has the isFixedPitch bit in post table set > which it > > seems used by some application to recognise monospace fonts > (though > > this, arguably, is wrong, there is no requirement that all > monnospace > > fonts set it). Per the spec, isFixedPitch is only set when all > glyphs > > in > > the font have the same width, but the font has a zero width > ".null" > > glyph, so FontForge does not set isFixedPitch when generating > the font > > (which is the right thing to do, some applications is know to > behave > > wrongly with such a font). > > > > Removing that glyph (which seems to serve no purpose and was > probably > > auto inserted by the tool generating the font), should do the > trick. > > > > > > Converting Cousine-Regular.ttf to .sfd and > > > > $cat Cousine.sfd |grep "Width: 0"|wc -l > > 267 > > > > We have lots of Zero width characters in Cousine-Regular fonts and > removing > > them looks not good solution. > > > > Do we have any other alternative to Set isFixedPitch bit? > > > > > > While more analysis i found that 0 width is assigned to most of the marks > > characters. > > 1. In my humble opinion it is valid. We can not assign equal Width same > as Base > > characters to Marks character. > > Font with "Decided Fixed width" or "0 Width" characters should be > considered as > > a Monospace. > > 2. Other reasons is compatibility with other font editors. > > The isFixedPitch bit is carried on from Type1 fonts where it really > meant all glyphs with no exception have the same width so > implementations can just check the width of any glyph, cache it, and > assume all other glyphs have the same width, as a form of optimisation > in the olden days. Many implementation still does so, now if the font > have a zero width glyph and it happens to be the glyph that the > implementation checked first, all other glyphs will be treated as if > they are zero width, which is not something you want¹. > It is clear to me now, Fontforge's behaviour is as per standard. As said by Paul it will be good to Document this somewhere since looks like other proprietary editors do not follow it. > > Now if you don’t care about all of this, you can use fontTools python > library (or its command line ttx tool) to post process the font and > manually set the bit. > I do care for standards but for the time being will use fontTools. But in Long Term i will do necessary changes. Thanks to all helped to clear my doubts. Regards, Pravin Satpute |
From: <pra...@gm...> - 2012-10-05 05:10:23
|
On 3 October 2012 10:19, pra...@gm... <pra...@gm...> wrote: > > > On 1 October 2012 18:51, Khaled Hosny <kha...@eg...> wrote: > >> On Mon, Oct 01, 2012 at 04:48:16PM +0530, pra...@gm... wrote: >> > >> > >> > On 1 October 2012 15:02, pra...@gm... <pra...@gm...> >> wrote: >> > >> > >> > >> > On 29 September 2012 16:08, Khaled Hosny <kha...@eg...> >> wrote: >> > >> > On Sat, Sep 29, 2012 at 11:52:33AM +0530, pra...@gm...wrote: >> > > Hi, >> > > >> > > I have downloaded >> https://googlefontdirectory.googlecode.com/hg/ofl >> > /cousine/ >> > > Cousine-Regular.ttf and saved as .sfd and regenerated ttf >> from it. >> > But >> > > regenerated font does not get recognized as a Monospace in >> Windows >> > http:// >> > > www.chiark.greenend.org.uk/~sgtatham/putty/download.htmlPutty.exe >> > > While the original downloaded font get recognized there >> properly. >> > > >> > > What might be going wrong while saving it as .sfd and >> regenerating >> > .ttf? >> > > >> > > Regenerated font >> http://pravins.fedorapeople.org/Test-Cousine.ttf >> > >> > The original font has the isFixedPitch bit in post table set >> which it >> > seems used by some application to recognise monospace fonts >> (though >> > this, arguably, is wrong, there is no requirement that all >> monnospace >> > fonts set it). Per the spec, isFixedPitch is only set when all >> glyphs >> > in >> > the font have the same width, but the font has a zero width >> ".null" >> > glyph, so FontForge does not set isFixedPitch when generating >> the font >> > (which is the right thing to do, some applications is know to >> behave >> > wrongly with such a font). >> > >> > Removing that glyph (which seems to serve no purpose and was >> probably >> > auto inserted by the tool generating the font), should do the >> trick. >> > >> > >> > Converting Cousine-Regular.ttf to .sfd and >> > >> > $cat Cousine.sfd |grep "Width: 0"|wc -l >> > 267 >> > >> > We have lots of Zero width characters in Cousine-Regular fonts and >> removing >> > them looks not good solution. >> > >> > Do we have any other alternative to Set isFixedPitch bit? >> > >> > >> > While more analysis i found that 0 width is assigned to most of the >> marks >> > characters. >> > 1. In my humble opinion it is valid. We can not assign equal Width same >> as Base >> > characters to Marks character. >> > Font with "Decided Fixed width" or "0 Width" characters should be >> considered as >> > a Monospace. >> > 2. Other reasons is compatibility with other font editors. >> >> The isFixedPitch bit is carried on from Type1 fonts where it really >> meant all glyphs with no exception have the same width so >> implementations can just check the width of any glyph, cache it, and >> assume all other glyphs have the same width, as a form of optimisation >> in the olden days. Many implementation still does so, now if the font >> have a zero width glyph and it happens to be the glyph that the >> implementation checked first, all other glyphs will be treated as if >> they are zero width, which is not something you want¹. >> > > It is clear to me now, Fontforge's behaviour is as per standard. As said > by Paul it will be good to Document this somewhere since looks like other > proprietary editors do not follow it. > > >> >> Now if you don’t care about all of this, you can use fontTools python >> library (or its command line ttx tool) to post process the font and >> manually set the bit. >> > > I do care for standards but for the time being will use fontTools. But in > Long Term i will do necessary changes. > Script to set isFixedPitch bit, http://git.fedorahosted.org/cgit/liberation-fonts.git/tree/scripts/setisFixedPitch-fonttools.py Regards, Pravin Satpute |