Imagine that, every part of the code is prone to errors that were never noticed before and every code that very code calls is also located in the tree and might also be part of the error you are getting! Often in the beginning, I thought most of the crashes I was fixing were caused by code changes in the 2012–2014 period but no! doing a git blame it was often a whole section that hadn't been modified since 2003 to 2007! How come it worked is the question you're asking to yourself when you're working with a C/C++ compiler that permits any sort of unchecked memory access (when you mix all that with the bad code style, the code not properly architectured with objects and all it all just becomes toxic). All of this was supporting code that he wrote to get his program running so they don't have nice APIs and all like a library written for its own sake.
#Fontforge windows download full
a Unicode and http implementation that are a bit hackish just to get the things running, a custom-written GUI toolkit that is also (besides being non-native on Windows and OSX) "badly"-written and full of crashes and does not have nice APIs. For us today we're not working at all regularly on it and we have to figure out, in an often-crufty code, what is happening! Also, the 220kLOC of FontForge include e.g. Almost every day, someone would report a bug/crash that George would fix pretty much immediately. Mind you that in its 12 years of presence, FontForge was maintained daily by George Williams. A C code is full of NULL checks, it doesn't have destructors so it's full of memory leaks as well, then FontForge is doing things like carrying function pointers in structs which makes debugging extremely hard. Also, C is extremely low-level and gives you little abstractions. It all works with large structs that were patched and extended as the program goes – this just shows how you're shooting yourself in the foot when doing such an app without OO. George Williams indicated on his website that he found object-oriented too cumbersome and that C++ was badly specified – the latter is true but not even a large company would make a 220kLOC app entirely in C (robofont is 100kLOC according to Frederik's talk, trufont is 15kLOC at the moment), or it would at least require a very strict code styling and review process, which FontForge doesn't. The core problem of FontForge is tha it was developed in C, which is not an object-oriented language. With the current tool, it takes just a couple of lines and a couple of minutes to do this. This includes a couple hours research to figure out where all of this is happening and a couple of following patches to fix what does not work.
This is what it takes to add a dropdown with a new attributes stored in the files and fonts. Out of interest, Dave, what aspects of this new project do you think make it look like a better investment than FontForge, which has obviously been around a lot longer? Are there lessons from the FontForge experience that you think Adrien and supporters of TruFont should be aware of?Īs a core developer of FontForge doing active development for nine months I think I may be able to answer better than Dave here.
0 kommentar(er)
