>> OK. What about passing `__LINE__` then?
>
> Alright, I have done the relevant changes, to pass
> line through a function parameter I had to change
> `FT_DEBUG_INNER' and `FT_ASSIGNP_INNER'
> macros like this:
> ```
> #define FT_DEBUG_INNER( exp ) ( _ft_debug_file = __FILE__, \
>
> I have my college exams on 23rd and 24th this month, and as I
> haven't prepared for them yet, I would like to give a few days that
> are left and study for my exams.
Of course. I wish you success!
Werner
> I have followed the [above] steps to change the `autogen.sh` file,
> so that it copies the files from directory `submodules/dlg` to
> `src/dlg`.
Great, thanks!
> I have also added a `rules.mk` file to `src/dlg` and, for proceeding
> further I wanted to ask that do I have to add a separate tar
Hello Greg,
> figured out the cause. I have however been working on this as much
> as time allows. I've mostly hashed out the scripts to run regression
> tests using demos here:
> https://patch-diff.githubusercontent.com/raw/fundies/freetype2/pull/1.patch
> [...]
Some comments.
* There are too
> As suggested by you I have used `setvbuf()` function in
> `FT_Message()` function for printing logs on stderr in Full
> buffering mode when FT_DEBUG_LEVEL_TRACE macro is enabled. For
> FT2_DEBUG=any:7 and command:
>
> main.exe arial.ttf *qwertyuiopasdfghjklzxcvbnm *
>
> I have got the follow
Hello Priyesh,
> I have used FT2_DEBUG=any:7 with:
>
> ./test arial.ttf *qwertyuiopasdfghjklzxcvbnm*
>
> and I have got following results:
>
> FT_LOGGING: 387ms (here dlg writes logs to stderr)
> FT_DEBUG_LEVEL_TRACE: 305 ms (FreeType writes logs to stderr,
>
> There seems to be a new warning in 2.10.2 (compared to 2.10.1) when
> compiling for 32-bit: [...]
Fixed in git, thanks.
> Also have had a bunch of strncat related warning (probably gcc 1 specific, or
> some compiler switch specific) in ft2-demos, for a while:
>
> ===
> inlined from 'RunIns
Hello David,
> Here's a patch to add a .clang-format style file to the directory.
Thanks. I've slightly improved it, but I think there is still room
for more fixes. Note that newer `clang-format` binaries have
additional options; we thus have to specify which version has to be
used.
We
> strcasecmp does not exist when compiling with Visual Studio
> (_stricmp does though and is doing the same job). mingw-w64 uses a
> #define for that. Why not adding ft_strcasecmp like ft_strdup ?
There is already
#ifdef _WIN32
#define strcasecmp _stricmp
#endif
in `ftcommon.c`...
> A better answer is to actually get rid of strcpy() / strcat() /
> sprintf() because there will always be compilers complaining about
> them.
>
> Here's a patch that does that for freetype2-demos, please take a
> look.
Applied with massaging and splitting into smaller chunks, thanks!
I've also
> I was working on removing the warnings which get triggered after
> enabling macro `FT_LOGGING' in ftoption.h file to use dlg library
> for logging on a file. If `FT_LOGGING' macro is enabled FT_TRACE
> messages are handled by dlg's API which internally uses a function
> of `printf' like format
Hello Vincent,
> On Windows, there is no mmap, but there is shared memory support,
> with CreateFileMapping and MapViewOfFile.
>
> If shared mem really improved loading of files on Unix, would you
> consider adding shared mem support on Windows too ?
If this really makes a difference on Windo
> That doesn't seem to work on windows.
>
> The warning is because of the ` FT_INTERNAL_FUNCTION_ATTRIBUTE'
> macro which is defined to __attribute__((visibility("hidden")). So
> defining it to nothing fixes all the warnings.
Thanks for patch, now applied to git.
Werner
>> The warning is because of the ` FT_INTERNAL_FUNCTION_ATTRIBUTE'
>> macro which is defined to . So defining it to nothing fixes all the
>> warnings.
>
> That's the thing on win32: you are not supposed to even get to
> __attribute__((visibility("hidden")). You must use
> __declspec(dllexport),
> Thanks, I will try to revert closer to the original logic where
> attributes were only used ifdef FT2_BUILD_LIBRARY. I thought it was
> sensible.
OK.
> On a related note, is there interest in HP C/HP aC++ support of
> hidden symbols? I have nuts and bolts for that. Or is there anything
> else n
> I've finished the core of the regression tester.
Great!
> You can now run it and generate a html report but you will need a
> few tools installed: imagick, xwd, npm, pretty-diff and xvfb. This
> should all be listed in ft-regression.sh's comments.If you want to
> run it locally make sure you
> I have added a project under `builds/windows/vc2010/freetype.sln'
> file to build dlg along with FreeType on Windows.
Thanks.
> The dlg project contains two configurations: `Debug' and `Debug
> Static' on both `x64' and `Win32' platforms and will be built with
> FreeType, whenever FreeType is
>> This looks very good, thanks! Indeed, the archive size of almost
>> one Gigabyte is far too large for practical purposes. We have now
>> to find solutions in the next month how to refine that.
>
> Right now it runs ~12 fonts that have ~3k glyphs each; this is why
> it's so large. I think th
>> I've made some progress with the COLR v1 extension implementation
>> in FreeType and would be happy to hear initial feedback on the
>> general approach and API style.
Dominik, this is very nice code, thanks!
> I would much rather prefer that
>
> 1) FT_Load_Glyph sequentially loads and merge
> With my last commit dlg's Visual Studios project is only built for
> `Debug' and `Debug Static' configurations on both `x64' and `Win32'
> platforms. For `Release' and `Release Static' builds, dlg's build
> is skipped.
This sounds completely correct.
Werner
>> Alexei, this sounds interesting. Care to implement this, as an
>> alternative interface? What Dominik has written fits quite well to
>> the existing API, so I'm in favor to add his code.
>
> I am scared of ttgload.c, which constantly juggles transforming and
> hinting. Are layers ever tran
Hello Anuj,
> I have mostly completed the bitmap to SDF renderer (bsdf), there are
> only a few things remaining such as support for all pixel modes
> (currently it only work with FT_PIXEL_MODE_GRAY), and warnings etc.
Excellent, thanks!
> Next, I will be finishing the bsdf renderer and then
Sorry for being late :-)
> Please review the patch if you agree with the placement of the flag
> retention code.
Looks good – and thanks for committing!
Werner
Anuj, Priyesh, and in particular Greg,
GSoC is ending soon! There are about two weeks remaining for work and
a last week for finalizing your projects.
I ask you to start with consolidating your code and documentation,
writing the necessary summaries, etc., etc. It's more important to
have a
> Werner, Are you still interested in adding API to remove overlaps?
Yes, I am.
> I watched the skia code and the video on how it's done in skia. I
> think it's doable, the only tricky part that I think is to find the
> intersecting point of contours, because they use a 4th degree
> polynomial t
>> Thanks, too. What do you think about integrating this into (at
>> least) `ftview`?
>
> Yes, it can be integrated into the existing demo programs, however I
> think it should have a separate demo program because of the way SDF
> is rendered, it has a raw and reconstruction view as well as var
Hello Anurag,
> All the cleartype patents mentioned in
> https://www.freetype.org/patents.html have expired: [...]
>
> So, it would be great if someone could update the patents section to
> reflect this information
Done. Thanks for the report.
> and check if there are any other cleartype pa
Hello Anurag,
thanks for your thoughts.
> *#1: Migrate development over to github:*
> Host the git repo on GitHub, use the GitHub issues and PR tracker
> instead of GNU Savannah and e-mail
No. We won't migrate to github. If at all, gitlab would be a
possible choice.
> *3. Easier for newbies
> I was trying to compile FreeType on Windows using Cygwin and I was
> getting the following error while executing `sh autogen.sh' command
> even though I have installed the required packages from the Cygwin
> package installer:
> --
>
>
> *Can't locate Automake/Config.pm in @INC (you may need
> I have tested the changes on OS X using Autotools i.e by using:
>
> sh autogen.sh
> ./configure
> make
>
> I know FreeType mainly uses Autotools for building purposes and here
> I wanted to ask that other than Autotools are there some other tools
> with which I need to build FreeType and
[CCing freetype-devel]
Hello Anurag,
>> Ah, thanks. However, 'freetype' would be even better :-)
>
> Yep, I hope gitlab support is able to help you (the link 404s
> anyway, so I believe we can get it),
Alas, I got a negative reply – 'freetype' seems to be taken by a
private repository.
htt
[CCed to 'freetype-devel']
> Please check out
> https://gitlab.com/freetype2/issue-migration/-/issues/27 and tell me
> your suggestions.
Very nice! Two comments.
* Please replace
Migrated from: [SAVANNAH-55235] reported by: rim
with
Migrated from: Savannah #55235
Reported by:
>> Today the code is like this:
>>
>> error = FT_New_Size( t42face->ttf_face, &ttsize );
>> t42size->ttsize = ttsize;
>> FT_Activate_Size( ttsize );
>>
>> My initial suggestion was:
>>
>> error = FT_New_Size( t42face->ttf_face, &ttsize );
>> if(error)
>> return error;
> The build actually succeeded in this one:
> https://gitlab.com/freetype2/issue-migration/-/pipelines/180494732
Great, thanks!
>>> Please go to gitlab.com/freetype2/issue-migration/issues/40 and tell me
>>> if any further changes are required in the issue format.
This looks fine. Alexei? To
Alexei,
how do I specify keys like 'F5' with the `-k` command line option to
the various FreeType demo programs?
Werner
>> how do I specify keys like 'F5' with the `-k` command line option to
>> the various FreeType demo programs?
>
> I don't think it is possible because grKeyF5 is 0x105, which would
> be wchar_t. It is either that or rethink and harmonize control keys
> more carefully.
Could you invent somethi
>> No. We won't migrate to github. If at all, gitlab would be a
>> possible choice.
>
> Just out of curiosity, feel free to not answer.
>
> Any specific reason for github.com being "banned" but gitlab.com
> being possible?
>
> Both run on non Free Software.
Well, gitlab's software is availa
>> Alas, I got a negative reply – 'freetype' seems to be taken by a private
>> repository.
>>
>> https://forum.gitlab.com/t/getting-freetype-group/41604/2
>
> Sorry for my late reply there + for the troubles that this may have
> caused but also good news: I reserved gitlab.com/freetype back whe
>> > I don't think it is possible because grKeyF5 is 0x105, which
>> > would be wchar_t. It is either that or rethink and harmonize
>> > control keys more carefully.
>>
>> Could you invent something? Being able to insert functions keys
>> would be quite useful...
>
> We can map them onto printab
>> This would be quite ugly...
>>
>> What about using, say, `|` as a delimiter to enter strings?
>>
>> ab|F5|cde
>>
>> If necessary, character `|` could be entered as `||`.
>
> We need something that is not a pipe command. Bash would except
>
> ab$'\xF2'cde
>
> This looks ok to me and does not
> Nice to see an effort on moving FreeType to a more modern UI :) Even
> if I wish GitLab would be (much) faster.
Really? Obviously you have a more than excellent internet connection
to notice such things...
> I'm wondering when the issue migration is complete? Or am I missing
> something?
Ri
> Alright, so this:
> https://gitlab.com/freetype2/issue-migration/-/issues/56
>
> is the final-final, super final, , final^∞,
> final 2:electric boogaloo, the last final, the final strikes back,
> the final awakens, final: endgame, final: dawn of finale template
> from my side.
:-)
> Are there
Hello David,
> - builds/meson/ftconfig.h.in: template versions of
> ftconfig.h to be used by the Meson build. It is processed
> by Meson, which will turn #mesondefine statements into
> #define / #undef depending on build configuration.
having a meson-specific `ftconfig.h.in` file is not
> It is not about UI but about community. To me,
> https://gitlab.freedesktop.org feels like the right community to
> move in. Thanks to Alan for the invitation. The other two
> communities are too crowded and too commercial.
Mhmm, I think gitlab is a good compromise between ethics and commer
> I propose to get rid of this template entirely for Meson, by
> defining HAVE_UNISTD_H and HAVE_FCNTL_H as simple compiler arguments
> when building the library.
What exactly do you mean with 'compiler arguments'?
> For the builds/unix/ftconfig.h.in case, there is also
> FT_USE_AUTOCONF_SIZEOF
>>> It is not about UI but about community. To me,
>>> https://gitlab.freedesktop.org feels like the right community to
>>> move in. Thanks to Alan for the invitation. The other two
>>> communities are too crowded and too commercial.
>>
>> Mhmm, I think gitlab is a good compromise between ethi
Hello Priyesh,
> I have updated the FreeType's code in accordance with the recent
> changes in the dlg library and again tested the code on
> Linux(Autotools), Windows(Visual Studios), and on OS X(Autotools).
thanks!
> I wanted to ask that is there something else which I have to take
> care o
>> BTW, how well does meson support cross compilation?
>
> it does support cross-compilation a lot better than cmake
> on Windows (though compilation fails because of mmap) :
Thanks for checking.
Werner
>>Create a new branch that presents your code in an ordered
>>fashion, this is, using not-too-large, concise, well documented
>>commits that makes it easy to understand how your project works.
>>Have a look how Anuj is doing this to get an idea. While doing
>>so, please check
Hello Piotr,
> The way to do it is to first go to ttinterp.c , then at the start of
> the file declare two variables:
>
> char FT_injectedGETINFOhack = 0;
> FT_Long FT_injectedGETINFOhackvalue;
this is an interesting idea, thanks.
> First of all, a commercial font is rendered like this wh
>> If this really makes a difference on Windows, and if you want to
>> contribute such code, you are welcome to do so!
>
> I guess that mmap is useful with a font with a large size, right ?
> if so, do you have a font to test with ?
You want a very large font to play around? I suggest to try
`
Hello Greg,
sorry for the late reply.
> As, discussed with Werner I have:
> 1) added a simple config file (in CI/ft-tests.config)
> 2) split the tests into smaller chunks
> 3) changed the colors of the diff images to green / red
> 4) added the diff images to the generated comparison page
> 5)
> So, I have updated the code in `GSoC-2020-priyesh' branch such that
> there are no separate project files for building dlg,
Thanks.
> in this branch I have used the `dlgwrap.c' method, [...]
OK.
> I have also pushed all the changes in this new branch, Please take a
> look at that and let me
> should I write a builds/win32/ftsystem.c ?
I guess yes; it's probably the simplest solution.
Werner
Dear Anuj, Priyesh, and Greg,
GSoC soon ends! Here are some last remarks.
* Starting with Sept. 1st, your GSoC branches in the FreeType
repository should be frozen. If you want to continue with your work
(which I hope you will do) please copy your branches to new ones and
continue work
> I have written the final report for my project.
>
> You can check it out here:
> https://gitlab.com/-/snippets/2007070
Looks great, thanks!
Werner
> Ok I believe I was able to commit to savannah but the message is a
> bit cryptic:
Everything's fine, thanks.
> I also added a readme as requested in CI/readme.md.
Thanks. Please reformat the file to make the lines not longer than 78
characters.
> Can anyone confirm this worked and tell me
> Have you considered dropping infinality especially after v40 have
> been integrated and used to great acclaim?
No, I haven't considered that.
> It is hard to maintain it with hardly any benefits. Reading
> ttinterp.c is prohibitively hard because Infinality is so invasive.
Yes, I know, and
> Any decision yet on whether it should be gitlab.com or
> freedesktop.org?
Nope. We haven't yet contacted the freedesktop.org people. Do you
want to do that?
Additionally, I don't want to rush this so that more people can chime
in – it's still holiday season for many people here in Europe. I
> Hey guys! Thought you might be interested in this project that claims to be
> 4-5x faster than font-rs and even faster than Pathfinder!. I would have
> loved to integrate the code in FreeType, but 1) I am not competent enough,
> 2) I got exams, so I'll save that opportunity for the future😅😅
> (G
> I asked if there were flags to dump the images at some point
I have to apoligize, too – I forgot that Alexei implemented this
feature.
Werner
> These are some horrible numbers that essentially test FT_Load_Glyph
> from compressed unifont.pcf.gz in reverse order: [...]
>
> real0m6.062s
>
> The same string forward is much faster: [...]
>
> real0m0.486s
Ouch.
> Is it well known that rewinding the compressed stream is so
> prohib
> a quick find -name *.c gives files in src/ and also :
>
> ./builds/amiga/src/base/ftdebug.c
> ./builds/amiga/src/base/ftsystem.c
> ./builds/mac/ftmac.c
> ./builds/unix/ftsystem.c
> ./builds/vms/ftsystem.c
> ./builds/wince/ftdebug.c
> ./builds/windows/ftdebug.c
> ./builds/windows/ftsystem.c
>
>
>> Let's not clog the src folder please
>>
>> src/base/amiga (not src/amiga)
>> src/base/unix (not src/unix)
>
> What about using a _.c suffix, as in:
If at all I prefer a `-.c` suffix. Underlines are an
abomination :-)
> src/base/ftsystem_amiga.c
> src/base/ftsystem_win32.c
> etc..
>
> We ar
> I'll tell Werner that black is better, speaking in my capacity of a
> professional python font developer!
I believe you :-)
Werner
> All right, here's the same set of patches with Black applied. The
> differences are minor, except for the use of double-quotes instead
> of single ones (I don't care personally).
Thanks! Will check your stuff within the next few days.
Werner
> 1. Sum the rendered widths of the following 52 characters:
>ABCDEFGHIJKLMNOPQRSTUVWXYZabcd
> 2. Divide by 52 with round to nearest. The way to do it is to add
>26 and divide by 52.
> 3. Multiply by 8. It's not eight spaces like some rumors say, but
>eight times the average letter wi
> All right, here's the same set of patches with Black applied.
Applied to the repository, with some changes here and there. Please
check!
Werner
> Please consider moving scripts into the build/meson folder for
> consistency. This is where cmake keeps its stuff.
Done.
Werner
Hello Eric,
sorry for the late reply.
> In cff/cffgload.c, at the end, in the function cff_slot_load: The
> bearings are set early on from calls to a get_metrics() font method.
> Those values are in font design units. Then towards the end of the
> cff_slot_load, there is a call to FT_Outline_
FreeType 2.10.3 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
Enjo
> So, we've had a report that building Ghostscript against Freetype
> 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
> use only.
>
> Ghostcript supplies callbacks for memory management
> (i.e. FT_MemoryRec) and we used FT_CALLBACK_DEF() for those, which
> seemed logical when d
> I have added icons to ftgrid, ftview, and ftstring. The EPS version
> is attached too. I thought that little branding would not hurt.
> Please comment.
Very nice, and thanks for the work!
For my taste the 'FT' glyphs are a bit tall. What do you think of
reducing the height a bit? This cou
>> For my taste the 'FT' glyphs are a bit tall. What do you think of
>> reducing the height a bit?
>
> It has to be grid-fitted into a 16x16 icon, which is rather
> universal with larger sizes scaled up. There is 1 pixel margin on
> all sides. I could not convince myself to adjust these margins
I've just fixed a heap buffer overflow that can happen for some
malformed `.ttf` files with PNG sbit glyphs. It seems that this
vulnerability gets already actively used in the wild, so I ask all
users to apply the corresponding commit as soon as possible.
Tomorrow I will do a 2.10.4 release.
>> Does this vulnerability affect older (< 2.10.3) versions of
>> FreeType as well?
Yes, down to 2.6, AFAICS.
> It appears that something like this was fixed with 54abd22891 but
> the fix there came too late (after a narrowing conversion) leaving
> some values unchecked.
I think the problem is
FreeType 2.10.4 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
Enjo
A warning for distribution maintainers: Version 2.10.3 and later may
break the build of ghostscript, due to ghostscript's use of a
withdrawn macro that wasn't intended for external usage:
https://bugs.ghostscript.com/show_bug.cgi?id=702985
https://lists.nongnu.org/archive/html/freetype-devel
>> withdrawn macro that wasn't intended for external usage
>
> We should drop it from the demos too, shouldn't we?
Yes.
Werner
> I have made some changes to how ftview selects the color depth mode so
> that there are fewer conversions of the image data.
Thanks!
> As a result, the 32-bit mode is much more readily used. I would
> appreciate it if you test it especially if you have some rare
> hardware or x11 forwarding w
> We're considering running some of the FreeType fuzzers as part of
> the internal Chromium fuzzing as well. In that setup, we have a
> different environment than for oss-fuzz and we can't have a Boost
> dependency.
>
> To that end, I filed a PR [...]
Thanks! I see that Armin is responding, s
> What do you think about a GSoC project to implement native Quartz
> and Wayland ports, considering the current landscape? This is
> somewhat contrary to the ftinspect goals, but I think that our test
> tools should stay rather low level.
Basically, I don't object. On the other hand I wonder
> I wanted to know what the hardware minimum requirements for using
> FreeType and FreeType2 would be (minimum RAM, processing power, and
> flash memory if applicable). I was planning on using FreeType for a
> project involving a microcontroller and wanted to know its
> limitations.
FreeType's
> The empty line after `* @description:` caused the refdoc build to
> fail,
Applied, thanks!
Werner
> The freetype2.pc file generated by Meson carries the version number
> 6.17.4 or something (the .so version number), but the one generated
> by configure says "Version: 23.4.17" -- who is right?
'Right' – this is a good question...
> For what it's worth, some build systems like RetroArch's seem
> Cool, thanks. Out of curiosity, where did the higher number come from?
> Why is it not the official version number?
Here's the explanation
https://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning
and the history of FreeType's libtool and .so numbers is in
`docs/VERSIONS.
> I'm updating Debian's copyright file for FreeType 2.10.4.
>
> Whose name should be attributed for copyright of the python scripts
> in builds/meson?
I've just added our standard copyright boilerplate.
Werner
I've just pushed the branch 'logging' to the git repository that
contains the Priyesh's GSoC project, with all commits beautified, and
with many necessary additions.
Please have a look!
Werner
> The updated code is working fine when we are using the `FT2_DEBUG'
> environment variable with tags(-v / -t / -vt), but without these
> tags I am getting corrupted memory issue with the `features_buf'
> char array in `src/base/ftdebug.c(ft_log_handler)' on both Ubuntu
> and Windows.
D'oh. I w
> > Which commit (from your GSoC branch) are you referring to?
>
> The changes in `include/freetype/internal/ftdebug.h' in commit
> 802176853 are missing in `logging' branch.
Fixed, thanks, and force-pushed! Please test.
Werner
Amit, Mahesh,
> I am new to open source just contributed in HactoberFest and I
> really wanna contribute more but don't know from where to start. I
> visited your website through GSoC. I have gone through projects and
> want to contribute to it and its newer versions.
>
> Please help me and s
Anuj,
I've polished your SDF driver; see the 'sdf' branches in both the
'freetype2' and 'freetype2-demos' repositories. Basically, it's ready
to be merged with 'master' :-)
Note, however, that there is a problem with the graphics display: On
Linux, something has changed in the graphics driver
>> Note, however, that there is a problem with the graphics display
>
> In the long run, ftsdf needs to become more agnostic to the display
> mode.
OK. Anuj, do you time to work on this?
> Right now it writes directly to the buffer assuming 24-bit (rgb888).
> So the quick fix for now is "800x
>> Note, however, that there is a problem with the graphics display:
>> On Linux, something has changed in the graphics driver of the demos
>> – instead of a single image I get four, with stripes (see attached
>> image).
>
> The issue is on windows as well. It is a mistake from my end, when
> I
> Hmmm. bV5CSType lists LCS_sRGB. [...]
OK, there are still open issues. I'll wait with applying the patches.
Werner
>> Assigning the output of the 'shell' command to the temporary
>> variable fixes the error.
Aah, ok, thanks.
> Nice. The internet suggests redirecting to > nul, which might be
> prepended: i.e.
>
> COPY := >nul copy
>
> or something
Anuj, can you change the `COPY` line in file `windows/dete
> Yes, it does work.
>
> ifeq ($(OS),Windows_NT)
> COPY := >nul cmd.exe /c copy
> else
> COPY := >nul copy
> endif # test NT
Thanks for testing! Committed.
Werner
I've just added the SDF module to master (and deleted the 'sdf'
branch). The new demo program is called `ftsdf`.
Please test!
Werner
Anuj,
I think that the memory debugging functions in file `ftsdf.c` can be
greatly simplified. Since `FT_DEBUG_MEMORY` must be defined I can't
see a reason to not use the default FreeType debugging stuff. In
other words, `SDF_ALLOC` and friends can be replaced with `FT_ALLOC`
and friends (mor
> I have attached a patch that strip all the custom memory tracking
> stuff.
Thanks a lot, applied!
Werner
1501 - 1600 of 4490 matches
Mail list logo
