Re: Edge effect (Depressed) on a Pixmap buffer using freetype lib
Hi Alexei, We resolved the issue by taking care of the alpha value. Thanks for your help and inputs. Thanks Sagar On Mon, 8 Jun 2020 at 1:57 PM, Aurovind Sagar wrote: > Hi Alexei, > > Yeah, we were aware of alpha blending upto an extent probably we were not > aware of the terminologies. Anyway we are trying to blend the edge (font in > a different color) and the font in our code. Thanks for the inputs. > > Tx > Sagar > > On Thu, Jun 4, 2020 at 6:18 PM Alexei Podtelezhnikov > wrote: > >> On Thu, Jun 4, 2020 at 8:28 AM Aurovind Sagar wrote: >> > We are using FreeType. Sorry, the intention was not to report any bug. >> We are looking for suggestions. We are not from graphics background, hence >> please excuse if we have asked any obvious questions. >> >> Guys, you need to learn about alpha blending. In the simplest terms: a >> glyph bitmap is colorless but rather gives you a proportion of brush >> and background colors: zeros mean that background is unchanged, 255 >> means it turns into purely brush color, something in between is a mix of >> colors. Then you just apply several layers like this: shade first, >> filled body second, outline third. >> >
FT_Add_Module() and related functions
Hi David, I actually thought about FT_Add_Module as a visionary interface for dynamically plugging alternative renderers: https://github.com/raphlinus/font-rs https://github.com/mooman219/fontdue https://github.com/servo/pathfinder Admittedly, none of those projects explored this possibility or there are more straightforward ways to achieve this. Then there is this whole discussion on how to integrate SVG, which again comes down to using an alternative renderer module and whether it is worth hooking inside a single module or Add/Remove multiple modules. https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00058.html So I know that nobody uses FT_Add_Module but it is not a bad interface. Alexei
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Thanks Werner, the patch looks good to me :-) Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit : > > Hello David, > > > > Since nobody does development on DOS or Windows 9x anymore, we can > > finally drop the requirement to use file names limited to the 8.3 > > format, which was the reason why the FT_LONG_HEADER_NAME_H macros > > were introduced in the first place. [...] > > Here's my patch, condensing your commits, adding some documentation, > and fixing some glitches. Please check! > > > - The public headers should not be renamed. > > What do you think about introducing a bunch of header files with long > names that do something like the following: > > file `FT_Multiple_Masters.h`: > > #include > /* EOF */ > > > Werner >
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit : > > Hello David, > > > > Since nobody does development on DOS or Windows 9x anymore, we can > > finally drop the requirement to use file names limited to the 8.3 > > format, which was the reason why the FT_LONG_HEADER_NAME_H macros > > were introduced in the first place. [...] > > Here's my patch, condensing your commits, adding some documentation, > and fixing some glitches. Please check! > > > - The public headers should not be renamed. > > What do you think about introducing a bunch of header files with long > names that do something like the following: > > file `FT_Multiple_Masters.h`: > > #include > /* EOF */ > > If this is about the public headers, why not, but let's do this in a future patch (with some documentation explaining what the new headers are, some simple sed or python scripts so developers can easily change the includes in their sources if they want to). Also, I would rather have include the new public header instead, it's cleaner, but I wonder if this is going to break scripts that try to list the headers explicitly in build systems or packaging scripts. As for the name, we should keep using format as part of the official source API, because it avoids a lot of needless conflicts to happen. On the other hand, we can use #include "ftmm.h" (instead of ) because this first search in the header's current directory. To be honest, I don't consider that a big priority for now, compared to the other build refactors / cleanups. It's easier not to do anything for now, to avoid breaking things unexpectedly for our users :-) > > Werner >
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Le mar. 9 juin 2020 à 01:06, Alexei Podtelezhnikov a écrit : > > >> We can remove as well, can't we? It is only used to > >> define the macros. So it is either ft2build.h and macros or neither. > > > > Not until all the consumers of FreeType are adapted to use direct > > header inclusion instead of the macros, > > Perhaps I was not clear. There is no point to have #include > in the FreeType source files that do not use macros any longer. The files > that use FT_CONFIG_OPTION_H still need it. > > But I do share the sentiment that it is probably too late for this kind of > change. The ship has sailed. > > I agree, we simply cannot change the source API at this point, which means we will need to support , the macros for the public headers, and *avoid* renaming the public headers themselves (because something is bound to break if we do). On the other hand, what we can do is: - Rename / move any internal header. Personally, I'm not too fond of CamelCase or Mixed_Camel_Case in header names :) - Stop using and the macros inside the FreeType sources (the patch is a first step in this direction). - If we deprecate a public API (e.g. I'm preparing patches to do that for FT_Add_Module() and related functions), they need to still be available and defined (as well as all types they depend on), but the implementation return FT_Err_Unimplemented_Feature. Of course, the doc should be updated with a "don't use this" message or something along that line. I would also like to get rid of ftmodule.h, and change the ftconfig.h file to only contain user-selectable options (it currently contains definitions that really belong to the implementation, and that nobody in its right mind would use in client code anyway), but this requires changing the way the library's features are configured, and that will probably happen after the module-API-deprecation anyway, or maybe after we change our primary build system. But none of that is urgent.
Re: Logging library
> Logging libraries are used for collecting and filtering and storing > logs *in production systems*. What you seem to want is better > debugging facilities. That's it. OK, wrong use of terms. Sorry for that. I want a logging library (or rather, a library that provides such facilities, whatever it is called) to improve debugging. The project is not intended to become part of production versions of FreeType. Does this clarify my intentions? > You seem to be on the camp of "how can more stuff be a bad idea." Not at all. But FreeType's debugging capabilities, inspite of the zillion tracing statements part of the source code, are still not sufficient IMHO to quickly get meaningful logging data. And I use the logging output *a lot* to identify the reason for bugs. Werner
