Re: tracing and logging library - GSOC Project
*>Hold your horses – what you do currently is already part of the GSoC* *>project! Right now you should do some preliminary investigations only* *>so that you are able to write a useful proposal.* Got it! :) *>That said, `zlog` looks indeed promising. Not sure about the Windows* *>port, however; maybe this needs some extra work.* I will definitely look into the windows library... Thanks... On Wed, Mar 4, 2020 at 1:30 AM Werner LEMBERG wrote: > > Hello Priyesh, > > > > Working forward in an external library hunt i came across two > > C based logging libraries: [...] > > > > I am also working on a prototype that will print log messages > > generated by FT_ERROR into a log file. > > Hold your horses – what you do currently is already part of the GSoC > project! Right now you should do some preliminary investigations only > so that you are able to write a useful proposal. > > [If you want to work on that project without being part of GSoC this > would be nice too and very welcomed, of course.] > > That said, `zlog` looks indeed promising. Not sure about the Windows > port, however; maybe this needs some extra work. > > > Please guide me if I am working in right direction.. > > You are :-) > > > Werner >
Re: tracing and logging library - GSOC Project
Hello Priyesh, > Working forward in an external library hunt i came across two > C based logging libraries: [...] > > I am also working on a prototype that will print log messages > generated by FT_ERROR into a log file. Hold your horses – what you do currently is already part of the GSoC project! Right now you should do some preliminary investigations only so that you are able to write a useful proposal. [If you want to work on that project without being part of GSoC this would be nice too and very welcomed, of course.] That said, `zlog` looks indeed promising. Not sure about the Windows port, however; maybe this needs some extra work. > Please guide me if I am working in right direction.. You are :-) Werner
Re: tracing and logging library - GSOC Project
Hey, Working forward in an external library hunt i came across two C based logging libraries: 1.log4c 2.zlog In the above mentioned libraries zlog claims to be faster, more safer and powerful. It is also well tested and mature, it also has a windows version. Some of zlog's features which i think could be useful for this project are: - log messages could be formatted according to our needs. - It has six default log levels and we can also define our own log levels ( could be used to define 8 levels of debugging in FT_TRACE ) - Highly Accurate and 1000 times faster than syslog ( claimed in documentation ) - It is also self debuggable i.e. it can output it's own debug and error logs - Thread safe for multi process situations I am also working on a prototype that will print log messages generated by FT_ERROR into a log file. Please guide me if I am working in right direction.. On Thu, Feb 27, 2020 at 10:14 AM Priyesh kumar wrote: > > > > *>In other words, my gut feeling says no to the idea of using > any>different code language. The logging facility should be written in>the > C language, too, not using more recent features than C99 so that>older > compilers support it.* > > Got it!! Thanks for your suggestion... I will keep this in mind. > > > > > *>It's not a *requirement* to use an external logging library (in spite>of > the project's name), but there are good arguments to not re-invent>the > wheel. In particular, it can be expected that a well-maintained>external > library gets a lot of testing and comes with a mature API.* > > Thanks, I agree with your point that an external library would be well > tested and mature. I thought in that direction as well but thought if > somehow I could get rid of integrating an external library. > Since quality is an important aspect, I will focus on the external library > part going forward. > > As per my understanding FreeType's Logger consists of following basic > Macros for printing log messages: > 1.FT_ERROR: for serious error messages. > 2.FT_ASSERT: for checking assertions at runtime. > 3.FT_TRACE: for general-purpose debugging messages with 8 levels of > debugging( 0 - 7 ). Different components in FreeType could have different > debug level. These levels are specified using FT2_DEBUG environment > variable. > Other logger features can be easily taken care( like they are today) if we > find a replacement for above basic Macro functions. > > Going forward, I will explore logging libraries and will check if one or > more of them will meet the above requirements either by directly > integrating them or by adding a little bit of logic on top of them. > Please guide me if I am on the right track. > > Thank You > > On Tue, Feb 25, 2020 at 12:00 PM Werner LEMBERG wrote: > >> >> Hello Priyesh! >> >> >> Thanks for your interest in FreeType. >> >> >[...] Therefore, I propose to implement separate code files for >> >logging, which could be based on C++ and can be easily plugged >> >into the existing C code base. In addition to this, improving a >> >bit on documentation can contribute to better understating of >> >existing logger codebase. >> >> I'm not sure I like this. >> >> Debugging is at the very heart of FreeType. Assume that you have to >> identify a bug, and you work in an environment for an exotic platform >> that only provides an (old) C compiler. Your suggestion implies that >> you no longer can activate debugging output at all on such a platform! >> >> In other words, my gut feeling says no to the idea of using any >> different code language. The logging facility should be written in >> the C language, too, not using more recent features than C99 so that >> older compilers support it. >> >> > Based on above points, all these changes could be done without >> > embedding an external library. Having said that, if it is really a >> > requirement to replace the current logging facility with an external >> > one, there is an external C based logging library named "Zlog" >> > already been discussed on mailing list here >> > < >> https://lists.nongnu.org/archive/html/freetype-devel/2019-01/msg00023.html >> >. >> > I can work on it and explore other available external library >> > option. >> >> It's not a *requirement* to use an external logging library (inspite >> of the project's name), but there are good arguments to not re-invent >> the wheel. In particular, it can be expected that a well-maintained >> external library gets a lot of testing and comes with a mature API. >> >> >> Werner >> >> >> PS: The current use of the debugging macros are documented in >> `doc/DEBUG`. >> >
gsoc idea: porting Raph Levien's font-rs to FreeType
I've just updated our GSoC pages with the following. Port the font-rs rendering engine to FreeType Raph Levien has developed font-rs[1], an experimental font renderer written in the Rust programming language. A blogpost describes some of its features in more detail; of particular interest is that it is much faster than FreeType's anti-aliasing rendering module. The gist of this project would be to port the Rust code to C and to integrate it into FreeType, providing it as an alternative rendering engine that eventually might replace the old one. It would be necessary to investigate how this can be done, and whether it is feasible at all. In case a port doesn't make sense (for whatever reasons) it should be investigated whether the ideas of the code can be used to re-implement the rasterizer in C. Difficulty: medium (if porting) to high (if reimplementing). Requirements: Rust, C, Unix build tools. Potential mentors: Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki (FreeType). [1] https://github.com/raphlinus/font-rs Werner
Re: Pd: Re: Odp: Re: ttfautohint — additional feature requests.
> So you're saying the only anti-aliasing is overkill > anti-aliasing. ? What do you mean? > Who thought of this as a good idea? It is ever so slightly more > accurate but really not worth it on lower end hardware such as > embedded systems. 4*4 oversampling is a high priority feature > request. I also suggest more oversampling rates of lower priority: > 6*5, 8*8, 2*2, 4*1, 6*1, 8*1, 2*1, oh you might as well make it > customizable, but at high priority is 4*4 oversampling. Sorry, but you are talking nonsense. FreeType was developed especially to run on embedded systems! In particular, the rasterizers (both the B/W and the A/A one) do work with systems that have just a very small amount of memory. > > FreeType doesn't do any filtering for grayscale rendering. > > Instead, it produces *exact* coverage values per pixel with 256 > > levels. In general this gives better results than filtering, for > > example, if you have to render long lines with a small slope. > > That is pretty much what a box filter is (to take the area in each > square). Well, yes. IIRC, however, rendering B/W at a much larger resolution followed by applying a filter is *slower* than FreeType's approach of directly computing the pixel coverage. > But to implement that exactly would be severe overkill. [...] Again, you are talking nonsense. Please get acquainted with FreeType's A/A rendering code before doing such unfounded claims. > If the glyph is very complex, with many intersections with pixel > edges and corners, the method would spend a lot of time finding the > exact value of the intersections then taking the exact integral > value of the entire square and take 8 fractional bits of it. This > is a processing waste, it also makes it much more complicated to > implement dropout control (in anti-aliasing it's supposed to have a > more subtle effect functioning on individual samples) There is no drop-out control in A/A mode, since it's kind-of useless. > and you would have to completely rewire the method to disable > vertical anti-aliasing as in the gasp flag. FreeType doesn't support the (crippled) mode of having A/A only along one axis. > It makes FreeType impossible to run with anti-aliasing on embedded > platforms. I am marking adding 4*4 oversampling as a high priority > now because FreeType deserves to have anti-aliasing (obviously with > correct gamma, and only when the font enables anti-aliasing) even on > embedded platforms that could run 4*4 oversampling but certainly not > the integral overkill monstrosity. Sigh. Werner
