Re: Build system considerations
On Tue, May 19, 2020 at 10:59 AM Ben Wagner wrote: > > [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates > > between ClearType and Harmony algorithms. Most users won't be able > > to tell them apart.] > > Note that some users of FreeType are never going to use subpixel > rendering at runtime and could do without the code. The actual amount > of code is pretty negligible, but if they are never going to use it > it's just extra weight, so it's nice to be able to configure it out, > no matter how small the extra code for it is. Ben, It is less than negligible, it is nothing. Literally: - Harmony only shifts the outline around (6 extra function calls) - ClearType scales the outline and scales it back, plus filtering. This is nothing in comparison to calculating the bounding boxes, allocating the memory, Bezier flattening, and actual rendering. The whole smooth.o is now only 88k. The Harmony overhead is not more than 5% or 4k. Why bother? Alexei
Re: Build system considerations
Le mar. 19 mai 2020 à 10:05, Alexei Podtelezhnikov a écrit : > > On Tue, May 19, 2020 at 8:09 AM Hugh McMaster > wrote: > > Is there any opportunity to avoid modifying ftoption.h directly to > > enable, say, subpixel rendering with a new build system? Carrying > > permanent patches for downstream packaging is annoying. > > [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates > between ClearType and Harmony algorithms. Most users won't be able > to tell them apart.] Note that some users of FreeType are never going to use subpixel rendering at runtime and could do without the code. The actual amount of code is pretty negligible, but if they are never going to use it it's just extra weight, so it's nice to be able to configure it out, no matter how small the extra code for it is. > > Personally, I'd like to be able to enable various options via > > configure flags or a configurable file (JSON, anyone?) that's not a C > > header. Python could do nicely here. > > One would think that modules.cfg is a configurable file like that but it turns > out that Chromium finds special ftmodule.h more convenient. We also have to > accommodate the less fortunate without Python on embedded systems. Chromium currently finds the ftmodule.h a convenient way to tell the runtime (ftinit.c ft_default_modules) which modules got built at build time. If there were a particularly better way to do that I don't think there would be much difficulty adapting. For example if the whole service / module structure went away and libfreetype just always did what was built and the list of modules to be loaded at library init didn't need to exist then we'd just build what bits we needed in each build and drop the ftmodule.h customization bits. > Some choices in FreeType, including the service and module infrastructure and > very lean external dependencies, has helped it to spread so widely. > > > Other than that, the removal of RPATHs should be revisited. That's a > > topic for another thread. > > Ok. > > Alexei >
Re: undefined reference error when running c++ file depends on freetype2.5
On Tue, May 19, 2020 at 9:52 AM Othman El-Kurdi wrote: > I'm trying to compile freetype2.5 on ubuntu 20.04 LTS (virtual machine), so > that I can use it to compile a c++ script. where I'm facing lot's of errors. Huh? Ubuntu 20.04 comes with FreeType 2.10.1. Try to use or install that. Then you just need proper compile flags to link with the system FreeType. > Firstly, I've followed the following instructions to compile freetype2: > https://github.com/metafloor/bwip-js/wiki/Compiling-FreeType We cannot possibly troubleshoot such unofficial and outdated instructions. > I'm trying to run the following script: > https://gist.github.com/jokertarot/7583938 Same here, but at least they discuss the PNG dependency.
Re: Build system considerations
On Tue, May 19, 2020 at 8:09 AM Hugh McMaster wrote: > Is there any opportunity to avoid modifying ftoption.h directly to > enable, say, subpixel rendering with a new build system? Carrying > permanent patches for downstream packaging is annoying. [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates between ClearType and Harmony algorithms. Most users won't be able to tell them apart.] > Personally, I'd like to be able to enable various options via > configure flags or a configurable file (JSON, anyone?) that's not a C > header. Python could do nicely here. One would think that modules.cfg is a configurable file like that but it turns out that Chromium finds special ftmodule.h more convenient. We also have to accommodate the less fortunate without Python on embedded systems. Some choices in FreeType, including the service and module infrastructure and very lean external dependencies, has helped it to spread so widely. > Other than that, the removal of RPATHs should be revisited. That's a > topic for another thread. Ok. Alexei
undefined reference error when running c++ file depends on freetype2.5
Hello everyone, my name is Othman Kurdi, I am a software developer at Genie9 company. I would like to ask for your help regarding the following issue: I'm trying to compile freetype2.5 on ubuntu 20.04 LTS (virtual machine), so that I can use it to compile a c++ script. where I'm facing lot's of errors. Firstly, I've followed the following instructions to compile freetype2: https://github.com/metafloor/bwip-js/wiki/Compiling-FreeType I'm trying to run the following script: https://gist.github.com/jokertarot/7583938 the errors which I'm getting are the following, they're all 'undefined reference to '''; 1 . undefined reference to `FT_New_Face' 2 . undefined reference to `FT_Done_Face' 3 . undefined reference to `FT_Get_Char_Index' 4 . undefined reference to `FT_Load_Glyph'| 5 . undefined reference to `FT_Render_Glyph'| 6 . undefined reference to `FT_Load_Sfnt_Table'| 7 . undefined reference to `FT_Set_Pixel_Sizes'| 8 . undefined reference to `FT_Select_Size'| 9 . undefined reference to `png_create_write_struct'| 10. undefined reference to `png_create_info_struct'| 11. undefined reference to `png_set_longjmp_fn'| 12. undefined reference to `png_set_IHDR'| 13. undefined reference to `png_init_io'| 14. undefined reference to `png_malloc'| 15. undefined reference to `png_malloc'| 16. undefined reference to `png_set_rows'| 17. undefined reference to `png_write_png'| 18. undefined reference to `png_free'| 19. undefined reference to `png_free'| 20. undefined reference to `png_destroy_write_struct'| 21. undefined reference to `FT_Init_FreeType'| 22. undefined reference to `FT_Done_FreeType'| The freetype library which I'm including to the gcc is located under the following path on my linux machine: */usr/include/freetype2* *My questions are:* 1. Did I compile freetype2 correctly? if not, how should I compile it correctly, can you please provide me with the correct instructions? 2. might the problem be that I am not including the freetype library correctly to the compiler(gcc)? 3. and for people who's familiar and experienced with freetype, can you provide me with clear instructions to follow while compiling it? I've searched a lot for a solution, unfortunately, I didn't find anything in regard. Any help would be highly appreciated. Thanks in advanced, regards, Othman Kurdi othma...@genie-soft.com
Re: Build system considerations
On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote: > > - Meson as the primary build system for FreeType developers, which > > includes the ability to run tests, sanitizers, coverage analysis, > > etc. > > It seems that Meson can create cmake package files, and probably build > scripts, too. Wouldn't that be the best solution? I can also imagine > that Meson builds `configure.ac`... Is there any opportunity to avoid modifying ftoption.h directly to enable, say, subpixel rendering with a new build system? Carrying permanent patches for downstream packaging is annoying. Personally, I'd like to be able to enable various options via configure flags or a configurable file (JSON, anyone?) that's not a C header. Python could do nicely here. Other than that, the removal of RPATHs should be revisited. That's a topic for another thread.
Re: [freetype2-demos] master fdf8913 3/3: [graph]: Implement resizable X11 windows.
> [graph]: Implement resizable X11 windows. Very nice, thanks! Werner
Re: Logging Library-GSOC
Thanks for the reply, *>Basically yes. As an improvement, I would like that the value of the>`FT_COMPONENT` macro can be displayed optionally, e.g.>[afhints] foo bar>[ttgxvar] sproink>...>The idea is that you first do a run with `FT2_DEBUG=any:7:labels` to>see all those tags, then redo it with, say,> FT2_DEBUG=afhints:7>to get only the 'afhints' debug messages if this is what you need for>debugging.* Thanks, I will keep this in mind... *> >2. Most external libraries provide some log levels capabilities>> themselves, so, should I think in direction of utilizing>>those. In case yes, then how should that be utilized?* *>Please elaborate and show examples.* *>> In the 2nd case, FreeType's logger will completely depend on the>> external library, and developers will also need to learn some new>> information to use the logger. And In the worst-case scenario, if>> the external library drops some functionality, we will need to make>> amendments to the logger.* *>I agree.* In the 2nd point I wanted to ask that should I completely reimplement the logger using APIs of external library. Since you agreed with the below point, I don't think the 2nd point makes any sense now... Will proceed with the 1st point... Thanks, Priyesh On Mon, May 18, 2020 at 9:03 PM Werner LEMBERG wrote: > > > > > I wanted to ask that after selecting desirable external library how > > should I proceed: > > [For David T.: The idea is to statically link the library into > FreeType using a git submodule. In other words, it's 'external' only > because it is developed by other people.] > > > 1. Should I stick to the existing debugging facility in which > >filtering of log messages is based on debug level comparisons of > >various FreeType's components and only use the external library > >to write log messages to file instead of stderr? > > Basically yes. As an improvement, I would like that the value of the > `FT_COMPONENT` macro can be displayed optionally, e.g. > > [afhints] foo bar > [ttgxvar] sproink > ... > > The idea is that you first do a run with `FT2_DEBUG=any:7:labels` to > see all those tags, then redo it with, say, > > FT2_DEBUG=afhints:7 > > to get only the 'afhints' debug messages if this is what you need for > debugging. > > > 2. Most external libraries provide some log levels capabilities > >themselves, so, should I think in direction of utilizing > >those. In case yes, then how should that be utilized? > > Please elaborate and show examples. > > > In the 2nd case, FreeType's logger will completely depend on the > > external library, and developers will also need to learn some new > > information to use the logger. And In the worst-case scenario, if > > the external library drops some functionality, we will need to make > > amendments to the logger. > > I agree. > > > According to me, the 1st option is better since the experience of > > using the logger will be the same for the client and developers and > > the only dependency of FreeType on external library will be of > > writing log messages to a file. > > Yep. > > > Werner >
