Re: Odp: Re: The TrueType rendering accuracy nightmare
>> if you ask FontForge for B/W rasterization it uses FreeType in v35 >> mode. In other words, the rasterization results returned by >> FontForge in this case are *identical* to what ft2-demo returns. > > I happened to be cleaning up my github account lately - so I have an > up-to-date clone of fontforge repo. Fontforge uses freetype for the > hinting instruction debugging (i.e. like ttdbug), and when that's > on, set v35 for the instruction debugger. However, the > freetype-based hinting instruction debugging is optional, and > require source of freetype to be present at fontforge's build time. > Thus a non-custom build of fontforge does not ever call > FT_Property_Set, at all, as far as I can tell, because it is > commented out when there isn't a nearby source tree of freetype. Sorry for being imprecise. I was talking about the B/W rendering while using instruction debugger. > The optional hinting instruction debugger is the only place where > FT_Property_Set is used. Yep, I've added this :-) Werner
Re: Odp: Re: The TrueType rendering accuracy nightmare
On Monday, 18 May 2020, 05:30:58 GMT+1, Werner LEMBERG wrote: > if you ask FontForge for B/W rasterization it uses FreeType in v35 > mode. In other words, the rasterization results returned by FontForge > in this case are *identical* to what ft2-demo returns. Hi Werner, I happened to be cleaning up my github account lately - so I have an up-to-date clone of fontforge repo. Fontforge uses freetype for the hinting instruction debugging (i.e. like ttdbug), and when that's on, set v35 for the instruction debugger. However, the freetype-based hinting instruction debugging is optional, and require source of freetype to be present at fontforge's build time. Thus a non-custom build of fontforge does not ever call FT_Property_Set, at all, as far as I can tell, because it is commented out when there isn't a nearby source tree of freetype. The optional hinting instruction debugger is the only place where FT_Property_Set is used. Frank or George Williams might be able to give a more authoritative answer - but as far as I can see from fontforge's source code, its rendering behavior is not tunable in the manner of ft2-demos. Hin-Tak
Re: Odp: Re: The TrueType rendering accuracy nightmare
Hin-Tak, > There is a bilevel mode in ft2-demo, and you can also switch to v35 > to match Microsoft better in ft2-demo, from the default v40. I told > you so, many emails ago, in my first reply. > > If you feel that you know fontforge and freetype well enough to tell > which is fontforge and which is freetype, I have nothing more to say > on that. Sigh. if you ask FontForge for B/W rasterization it uses FreeType in v35 mode. In other words, the rasterization results returned by FontForge in this case are *identical* to what ft2-demo returns. Werner
Re: The TrueType rendering accuracy nightmare
That's actually great feedback, thanks Piotr, we'll have a look. Le dim. 17 mai 2020 à 20:47, Alexei Podtelezhnikov a écrit : > >> From the image, it is evident that both FreeType and TD renderer (my > own renderer that relies on FreeType but uses my own rasterizer, > https://typedesign.netlify.app/tdrenderer.html) are extremely glitchy. It > is very important to take research into TrueType rendering to properly > simulate the Microsoft bilevel renderer because it would help render fonts > correctly. The immense complexity of FreeType's rasterizer is still not > enough. What a nightmare! > >> > > What are we supposed to answer to your post exactly? > > In Piotr's defense, he is much more constructive in his bug reporting. > I does look that he identified and helped with: > https://savannah.nongnu.org/bugs/index.php?58373 where the borderline > pixels on horizontal stems are not turned on > https://savannah.nongnu.org/bugs/index.php?58352 where rounding in > bytecode seems to be off by 1. > > Alexei >
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
On Monday, 18 May 2020, 02:38:24 GMT+8, piotrunio-2...@wp.pl wrote: > > You showed a few fontforge-generated screenshots, which shows good > > agreement between fontforge and Microsoft rendering. If you think they are > > not good enough, fontforge's github tracker is the place to report it. > It's by no means a good agreement because it's not pixel-for-pixel identical. > In fact, many pixels differ; this is called extremely glitchy and requires > several bugfixes to get it fixed. And FontForge has nothing to do with how > FreeType itself renders, nor does there exist a more accurate mode than the > already existing bilevel mode that's extremely glitchy. There is a bilevel mode in ft2-demo, and you can also switch to v35 to match Microsoft better in ft2-demo, from the default v40. I told you so, many emails ago, in my first reply. If you feel that you know fontforge and freetype well enough to tell which is fontforge and which is freetype, I have nothing more to say on that. Sigh.
Re: The TrueType rendering accuracy nightmare
>> From the image, it is evident that both FreeType and TD renderer (my own >> renderer that relies on FreeType but uses my own rasterizer, >> https://typedesign.netlify.app/tdrenderer.html) are extremely glitchy. It is >> very important to take research into TrueType rendering to properly simulate >> the Microsoft bilevel renderer because it would help render fonts correctly. >> The immense complexity of FreeType's rasterizer is still not enough. What a >> nightmare! >> > What are we supposed to answer to your post exactly? In Piotr's defense, he is much more constructive in his bug reporting. I does look that he identified and helped with: https://savannah.nongnu.org/bugs/index.php?58373 where the borderline pixels on horizontal stems are not turned on https://savannah.nongnu.org/bugs/index.php?58352 where rounding in bytecode seems to be off by 1. Alexei
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
You showed a few fontforge-generated screenshots, which shows good agreement between fontforge and Microsoft rendering. If you think they are not good enough, fontforges github tracker is the place to report it. Its by no means a good agreement because its not pixel-for-pixel identical. In fact, many pixels differ; this is called extremely glitchy and requires several bugfixes to get it fixed. And FontForge has nothing to do with how FreeType itself renders, nor does there exist a more accurate mode than the already existing bilevel mode thats extremely glitchy.
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
On Sunday, 17 May 2020, 14:34:17 GMT+8, piotrunio-2...@wp.pl wrote: > That's not an excuse not to fix the FreeType bugs. The FreeType guys should > not focus on my software and instead fix their own bugs. > I do not intend to ask for any help, I'm already working on fixing the TD > renderer bugs myself. But will the FreeType guys fix their own bugs? You showed a few fontforge-generated screenshots, which shows good agreement between fontforge and Microsoft rendering. If you think they are not good enough, fontforge's github tracker is the place to report it. Since we are not talking about your buggy piece of software, and you are not asking for help, you should stop referring to it. And if you want to talk about freetype, please keep-freetype-devel in the cc.
Re: The TrueType rendering accuracy nightmare
Le jeu. 14 mai 2020 à 20:35, piotrunio-2...@wp.pl a écrit : > The standard ppem of the test font is: 16 > The standard string of the test font is: !"#$% > > From the image, it is evident that both FreeType and TD renderer (my own > renderer that relies on FreeType but uses my own rasterizer, > https://typedesign.netlify.app/tdrenderer.html) are extremely glitchy. It > is very important to take research into TrueType rendering to properly > simulate the Microsoft bilevel renderer because it would help render fonts > correctly. The immense complexity of FreeType's rasterizer is still not > enough. What a nightmare! > > What are we supposed to answer to your post exactly? The bitmap you posted has little context that explains how it was generated (in particular how you configured the TrueType interpreter for FreeType), or what we're supposed to see as defects (hint: when it comes to vector graphics rendering: differences != defects). The web page you link to mentions that your code is buggy anyway. We spent a lot of time tuning the TrueType interpreter and the monochrome rasterizer, trying to match the bi-level rendering of Windows for popular / well-known fonts (e.g. Arial), but we do not guarantee that rendering results will be 100% identical for all fonts, since some of the geometric computations performed during bytecode execution have varying level of accuracy / rounding behaviour, depending on their exact implementation details (which have never been part of the spec). However, if you think we are wrong, we would be happy to see you research on the topic explaining how to improve things in the code base, so we can answer to your claims on a technical basis. I'm sorry if you thought that FreeType would match rendering 100% of the time, we never made this claim, even if we try very hard. Of course, you're free to help us improve the situation. - David
Re: Odp: Re: The TrueType rendering accuracy nightmare
> I fixed some bugs in a development version, which would make the 2.0 > version of TD renderer significantly more accurate than 1.0. > > https://i.imgur.com/oKDg7F1.png > > I also made sure to research how dropout control works and implement > much more accurate rules than in TD renderer 1.0. So the FreeType > guys should fix the bugs in their rasterizer as well. I don't have time right now (moving from one flat to another) – could you provide patches for FreeType? It would be at least interesting to find out where exactly the difference happens, which is caused by rounding, I guess. Werner
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
> I fixed some bugs in a development version, which would make the 2.0 version > of TD renderer significantly more accurate than 1.0. > https://i.imgur.com/oKDg7F1.png You might.have tried the recent FreeType but you didn’t have to. > I also made sure to research how dropout control works and implement much > more accurate rules than in TD renderer 1.0. So the FreeType guys should fix > the bugs in their rasterizer as well. We might but should we? This is not a business you know...
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
No, its evident that both are glitchy. You cant arbitrary say one renderer but not the other does it quite well when both have many errors. They are both extremely glitchy, and thats exactly the implementation nightmare. There is an international agreed ISO standard, ISO 14496-22, currently at its 4th edition, about fonts. It is quite possible to say one renderer is more compliant than another. So yours is broken, and more broken than others. Thats quite evident. I fixed some bugs in a development version, which would make the 2.0 version of TD renderer significantly more accurate than 1.0. i.imgur.com i.imgur.com I also made sure to research how dropout control works and implement much more accurate rules than in TD renderer 1.0. So the FreeType guys should fix the bugs in their rasterizer as well.
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
On Sat, 16 May 2020 at 05:32, piotrunio-2...@wp.pl wrote: > It is very important to take research into TrueType rendering to properly simulate the Microsoft bilevel renderer because it would help render fonts correctly. That is excellent piece of advice. So it seems that you know what you need to do: you should take research into TrueType rendering to properly simulate the Microsoft bilevel renderer. As you've noticed, FreeType is complex. It has many different modes. Screenshots from FontForge don't have any decisive value, because they're just screenshots from one client app. As for the rest: Hin-Tak provided you with some useful pointers so you can start that research. And yes, the arrogant-aggressive stance isn’t exactly encouraging or helpful. Best, Adam
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
On Saturday, 16 May 2020, 11:32:19 GMT+8, piotrunio-2...@wp.pl wrote: > > I am not sure what you are trying to say here or trying to do. Your own > > program is buggy - so go fix it. As I mentioned twice already - we are on > > reasonable friendly terms with the Microsoft folks, and they are happy to > > confirm undocumented behaviors, and afaik from your screenshots, freetype > > /fontforge matches Microsoft's rendering quite well, and your program is > > way off and buggy. If you want to ask for help on debugging, ask for help > > properly. > No, it's evident that both are glitchy. You can't arbitrary say one renderer > but not the other does it "quite well" when both have many errors. They are > both extremely glitchy, and that's exactly the implementation nightmare. There is an international agreed ISO standard, ISO 14496-22, currently at its 4th edition, about fonts. It is quite possible to say one renderer is more compliant than another. So yours is broken, and more broken than others. That's quite evident. If you are struggling to debug your own piece of buggy software, you should ask for help nicely. Keep saying "mine is as buggy as yours" and hope that knowledgeable people would spend time helping you, is not the way. Quite far from it. Also, afaik, Frank (the current maintainer of fontforge) does not subscribe to freetype-devel. He is quite a reasonable and helpful guy, but if you have a concrete problem with understanding your failure to use fontforge properly, you should head over to fontforge's github issue tracker.
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
Please include freetype-devel in all following discussions. Or stop posting. There are official demos which allows you to change modes. They are in the ft2-demos repo. Many linux distros bundle them as freetype-devel or freetype-tools. Fontforge is not freetype. I am not sure what you are trying to say here or trying to do. Your own program is buggy - so go fix it. As I mentioned twice already - we are on reasonable friendly terms with the Microsoft folks, and they are happy to confirm undocumented behaviors, and afaik from your screenshots, freetype /fontforge matches Microsoft's rendering quite well, and your program is way off and buggy. If you want to ask for help on debugging, ask for help properly. On Friday, 15 May 2020, 05:39:13 GMT+1, piotrunio-2...@wp.pl wrote: About my 2nd point - you did not get it: fontforge is not freetype. If you want freetype to imitate Microsoft's bilevel rendering, please do as I suggested. Fontforge does not have a mode of "use freetype to imitate Microsoft's rendering", afaik. Use v35 and set rendering mode to mono. FreeType by itself doesn't layout text or select foreground or background colors, an external program must be used to render with FreeType. And I cannot expect a change of mode to somehow fix the bugs. As for the initial paragraph - it is clear from your own png posted that freetype (in fontforge) matches Microsoft's rendering well enough, but your own rendering does not. You need to show a lot more evidence and proof to claim freetype is glitchy - even our Microsoft friends don't make that kind of claim! What? If anything, it's evident that neither of the two open-source rasterizers are accurate. If both rasterizers are inaccurate you can't just arbitrarily mark one the better. The test can only pass if the rendering is pixel by pixel correct. Also, FreeType's rasterizer probably had much more time to get developed than mine; FreeType may have had multiple updates while it is still the first version of TD rasterizer, so it is yet to improve.
Re: The TrueType rendering accuracy nightmare
On Thu, May 14, 2020 at 2:35 PM piotrunio-2...@wp.pl wrote: > > The standard ppem of the test font is: 16 > The standard string of the test font is: !"#$% Frankly, your image shows amazing consistency between FreeType and GDI. You are right that BW rasterizers have complex rules, each of which can slightly misinterpreted (or have bugs). When reporting a font problem it is important to hammer on a single issue, single glyph, even single pixel instead of complaining broadly and emotionally.
Re: Odp: Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
About my 2nd point - you did not get it: fontforge is not freetype. If you want freetype to imitate Microsoft's bilevel rendering, please do as I suggested. Fontforge does not have a mode of "use freetype to imitate Microsoft's rendering", afaik. Use v35 and set rendering mode to mono. As for the initial paragraph - it is clear from your own png posted that freetype (in fontforge) matches Microsoft's rendering well enough, but your own rendering does not. You need to show a lot more evidence and proof to claim freetype is glitchy - even our Microsoft friends don't make that kind of claim! On Thursday, 14 May 2020, 20:38:23 GMT+1, piotrunio-2...@wp.pl wrote: This is a rather bizarre post - you seems to claim that your wrote a buggy piece of software half-based on freetype, it is not working as you wish, so it is freetype's fault - instead of your own... It is demonstrated that neither FreeType nor my rasterizer work properly. It shows that any renderer that isn't dependent on any Microsoft renderer is extremely glitchy. Another point: freetype tries to render well to gray, and lately even sub-pixels. If you want to get freetype to imitate Microsoft's GDI bilevel to some degree, you need to set the TrueType property to v35 (instead of the v40 default) as well as setting rendering mode to mono (gray is the default, afaik). The FreeType rendering is taken from FontForge's previews with anti-aliasing disabled. Thirdly, garbage in garbage out - if you intentionally make a font which exhibits undefined behavior, and expect undefined behavior to be defined, that's crazy. There are a numbers of tools which can tell you your fonts are buggy and how, and (shameless plug) - https://github.com/HinTak/Font-Validator, Google's fontbakery, apple"s font tools. I don't know why you expect undefined behavior to be defined and matching across different renderers. ?
Re: The TrueType rendering accuracy nightmare (Re: Freetype-devel Digest, Vol 184, Issue 24)
> The standard ppem of the test font is: 16 The standard string of the test > font is: !"#$% From the image, it is evident that both FreeType and TD > renderer (my own renderer that relies on FreeType but uses my own rasterizer, > typedesign.netlify.app typedesign.netlify.app ) are extremely glitchy. It is > very important to take research into TrueType rendering to properly simulate > the Microsoft bilevel renderer because it would help render fonts correctly. > The immense complexity of FreeType's rasterizer is still not enough. What a > nightmare! This is a rather bizarre post - you seems to claim that your wrote a buggy piece of software half-based on freetype, it is not working as you wish, so it is freetype's fault - instead of your own... More specifically - while Microsoft folks won't going to specific details voluntarily on their own initiatives, but they are happy to confirm "undefined" behavior in their rendering engine and let freetype matches undefined behavior over the years/decades. So I suspect you are simply using freetype wrongly to get the results you got. Another point: freetype tries to render well to gray, and lately even sub-pixels. If you want to get freetype to imitate Microsoft's GDI bilevel to some degree, you need to set the TrueType property to v35 (instead of the v40 default) as well as setting rendering mode to mono (gray is the default, afaik). Thirdly, garbage in garbage out - if you intentionally make a font which exhibits undefined behavior, and expect undefined behavior to be defined, that's crazy. There are a numbers of tools which can tell you your fonts are buggy and how, and (shameless plug) - https://github.com/HinTak/Font-Validator, Google's fontbakery, apple"s font tools. I don't know why you expect undefined behavior to be defined and matching across different renderers.
