From: <pc...@gm...> - 2005-08-25 22:01:56
|
Hello again ;-) Well, it looks like there are actually 2 parts of this bug: The first one (http://dejavu.sourceforge.net/wiki/images/3/33/Dejavu_notsog= ood.png) is probably caused by some undocumented behavior of the SHZ instruction which freetype does not implement. I'll better doublecheck everything this time before coming up with any claims about this :-) The second one (http://dejavu.sourceforge.net/wiki/images/e/ea/Ttf_kerning_= bug.png) is pretty easy. Fontforge does not set the right flags (again). Take for example the 'scaron' glyph. The instructions in the 's' component change the advance width of this component, but the composite 'scaron' does not "inherit" the new width and is scaled linearly. This is controlled by the USE_MY_METRICS flag (see http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, Table 18). The flags are set properly in Vera, but FontForge does not use them or even preserve them. They need to be set in the postprocess script and this could be a lot of trouble because you must know which composite glyphs must be changed (eg. change 'ncaron' but not 'nj') and which components of these glyphs must have this flag set (eg. in 'ncaron' set the flag on 'n' but not on the 'caron'). So there :-) Peter |
From: Keenan P. <kee...@gm...> - 2005-08-26 00:05:18
Attachments:
z-spacing.patch
|
Peter Černák wrote: > Hello again ;-) > > Well, it looks like there are actually 2 parts of this bug: > > The first one (http://dejavu.sourceforge.net/wiki/images/3/33/Dejavu_notsogood.png) > is probably caused by some undocumented behavior of the SHZ > instruction which freetype does not implement. I'll better doublecheck > everything this time before coming up with any claims about this :-) By far the majority of Vera's DELTAP1 instructions involve the n+1 advance point; maybe we could fix the spacing problems just by tweaking those. For example, the attached patch fixes the problem with lowercase z shown in the image by simply removing one of the DELTAP1 instructions, so the advance point remains where it is instead of being shifted one pixel to the left. > The second one (http://dejavu.sourceforge.net/wiki/images/e/ea/Ttf_kerning_bug.png) > is pretty easy. Fontforge does not set the right flags (again). Take > for example the 'scaron' glyph. The instructions in the 's' component > change the advance width of this component, but the composite 'scaron' > does not "inherit" the new width and is scaled linearly. This is > controlled by the USE_MY_METRICS flag (see > http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, Table > 18). The flags are set properly in Vera, but FontForge does not use > them or even preserve them. They need to be set in the postprocess > script and this could be a lot of trouble because you must know which > composite glyphs must be changed (eg. change 'ncaron' but not 'nj') > and which components of these glyphs must have this flag set (eg. in > 'ncaron' set the flag on 'n' but not on the 'caron'). > > So there :-) > > Peter It sure would be nice to have support in FontForge for this stuff. I think I'll subscribe to the fontforge-devel mailing list and bug them, err... politely request for this to be implemented. =) Keenan |
From: <pc...@gm...> - 2005-08-26 00:34:23
|
Hi Keenan, > > The first one (http://dejavu.sourceforge.net/wiki/images/3/33/Dejavu_no= tsogood.png) > > is probably caused by some undocumented behavior of the SHZ > > instruction which freetype does not implement. I'll better doublecheck > > everything this time before coming up with any claims about this :-) >=20 > By far the majority of Vera's DELTAP1 instructions involve the n+1 advanc= e > point; maybe we could fix the spacing problems just by tweaking those. >=20 > For example, the attached patch fixes the problem with lowercase z shown = in the > image by simply removing one of the DELTAP1 instructions, so the advance = point > remains where it is instead of being shifted one pixel to the left. Hehe, nice try. Check out http://sourceforge.net/mailarchive/forum.php?thread_id=3D7908822&forum_id= =3D40874, third message from top... ;-) This does not work though, as it will make 'z' too wide on cleartype and maybe on other renderers. The wrong widths always appear after a certain sequence of instructions (look for the mppem - if - shpix - shz - shpix - endif sequence). I'll post more details if anyone's interested. > > The second one (http://dejavu.sourceforge.net/wiki/images/e/ea/Ttf_kern= ing_bug.png) > > is pretty easy. Fontforge does not set the right flags (again). Take > > for example the 'scaron' glyph. The instructions in the 's' component > > change the advance width of this component, but the composite 'scaron' > > does not "inherit" the new width and is scaled linearly. This is > > controlled by the USE_MY_METRICS flag (see [...] > It sure would be nice to have support in FontForge for this stuff. I thin= k I'll > subscribe to the fontforge-devel mailing list and bug them, err... polite= ly > request for this to be implemented. =3D) It surely is worth a try. There is even no need to change fontforge's GUI, just preserving the flag in the sfd files would be sufficient. Good luck with ff's devs then. -- Peter |
From: Keenan P. <kee...@gm...> - 2005-08-26 01:04:09
|
Peter Černák wrote: > Hehe, nice try. Check out > http://sourceforge.net/mailarchive/forum.php?thread_id=7908822&forum_id=40874, > third message from top... ;-) > > This does not work though, as it will make 'z' too wide on cleartype > and maybe on other renderers. The wrong widths always appear after a > certain sequence of instructions (look for the mppem - if - shpix - > shz - shpix - endif sequence). I'll post more details if anyone's > interested. Well, we could always get rid of the SHPIX/SHZ stuff and try to get results of similar quality some other (less kludgy, more portable) way. > It surely is worth a try. There is even no need to change fontforge's > GUI, just preserving the flag in the sfd files would be sufficient. > Good luck with ff's devs then. > > -- Peter > Yeah, I might even dive into the code and hack out a patch myself. Looks a little intimidating tho. Keenan |
From: Stepan R. <st...@sr...> - 2005-08-26 18:29:27
|
Hi. On Fri, 26 Aug 2005, Peter =C8ern=E1k wrote: > Well, it looks like there are actually 2 parts of this bug: > > The first one (http://dejavu.sourceforge.net/wiki/images/3/33/Dejavu_nots= ogood.png) > is probably caused by some undocumented behavior of the SHZ > instruction which freetype does not implement. I'll better doublecheck > everything this time before coming up with any claims about this :-) > > The second one (http://dejavu.sourceforge.net/wiki/images/e/ea/Ttf_kernin= g_bug.png) > is pretty easy. Fontforge does not set the right flags (again). Take > for example the 'scaron' glyph. The instructions in the 's' component > change the advance width of this component, but the composite 'scaron' > does not "inherit" the new width and is scaled linearly. This is > controlled by the USE_MY_METRICS flag (see > http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, Table > 18). The flags are set properly in Vera, but FontForge does not use > them or even preserve them. They need to be set in the postprocess > script and this could be a lot of trouble because you must know which > composite glyphs must be changed (eg. change 'ncaron' but not 'nj') > and which components of these glyphs must have this flag set (eg. in > 'ncaron' set the flag on 'n' but not on the 'caron'). > > So there :-) Impressive. I don't understand a word you wrote ;-) Can you create a Wiki= =20 page with this description and link it from the Bugs page? Thank you. Have a nice day. Stepan Roh |
From: <pc...@gm...> - 2005-08-27 15:59:18
|
2005/8/26, Stepan Roh <st...@sr...>: > > The second one (http://dejavu.sourceforge.net/wiki/images/e/ea/Ttf_kern= ing_bug.png) > > is pretty easy. Fontforge does not set the right flags (again). Take > > for example the 'scaron' glyph. The instructions in the 's' component > > change the advance width of this component, but the composite 'scaron' > > does not "inherit" the new width and is scaled linearly. This is > > controlled by the USE_MY_METRICS flag (see > > http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, Table > > 18). [...] > Impressive. I don't understand a word you wrote ;-) Can you create a Wiki > page with this description and link it from the Bugs page? Thank you. Do you think that a page is necessary? I'll try to explain it better here. From the example above: 'scaron' is a glyph, right? It has its own metrics, but it doesn't have an outline. Intead, it has two components -- 's' and 'caron'. When rendering, 'scaron' uses its own metrics. We don't want that, we want to use metrics from its component 's'. This would be done by setting the USE_MY_METRICS flag on that component. And that's it :-) -- Peter |
From: Stepan R. <st...@sr...> - 2005-08-28 18:09:10
|
On Sat, 27 Aug 2005, Peter =C8ern=E1k wrote: > 2005/8/26, Stepan Roh <st...@sr...>: > >>> The second one (http://dejavu.sourceforge.net/wiki/images/e/ea/Ttf_kern= ing_bug.png) >>> is pretty easy. Fontforge does not set the right flags (again). Take >>> for example the 'scaron' glyph. The instructions in the 's' component >>> change the advance width of this component, but the composite 'scaron' >>> does not "inherit" the new width and is scaled linearly. This is >>> controlled by the USE_MY_METRICS flag (see >>> http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, Table >>> 18). [...] > >> Impressive. I don't understand a word you wrote ;-) Can you create a Wik= i >> page with this description and link it from the Bugs page? Thank you. > > Do you think that a page is necessary? Maybe for tracking the progress on this bug? But you are probably right=20 that it's not necessary. But link this thread on Bugs page. Thank you. >> From the example above: 'scaron' is a glyph, right? It has its own > metrics, but it doesn't have an outline. Intead, it has two components > -- 's' and 'caron'. When rendering, 'scaron' uses its own metrics. We > don't want that, we want to use metrics from its component 's'. This > would be done by setting the USE_MY_METRICS flag on that component. > And that's it :-) OK, thanks. That makes sense. Maybe that could be set in postprocess ...=20 yes, looks like it could be, although I don't yet know how (see=20 Font::TTF::Glyph). Have a nice day. Stepan Roh |