Re: Important changes in Docwriter

Hello Nikhil, thanks for your quick response. >> Note that `mkdocs.yml` gets explicitly removed while calling `make >> dist` (see `builds/toplevel.mk`). > > `mkdocs serve` requires the file `mkdocs.yml` to generate the site > and start up the server. Yes, but... > If we want search to be us

Re: GSOC

Hello Greg, Anuj, and Priyesh! Welcome to FreeType :-) We are glad that you are with us the next few months (and maybe even longer), and thank you in advance for the work on your projects. Our main communication is e-mail, which has served us well since the very beginning. Except for really pr

Re: GSOC

>> Please get an account on Savannah > > I have created an account my username is: *anujverma* Added. > And here is my name in my native script Hindi (हिंदी): अनुज वर्मा (Anuj > Verma) Thanks! Werner

Re: Important changes in Docwriter

> I did a quick search, and came across this pull request in the mkdocs > repository: > > https://github.com/mkdocs/mkdocs/pull/1805 OK, thanks for investigating. > To implement these changes to allow them to work with docwriter will > require fixing the attached script to prevent the page fr

Re: [ft-devel] woff2 support integrated into FreeType

> Do you know why ftdump is failing with WOFF2? > Other demos seem to be working. Fixed in git now, thanks for the report. Werner

Re: pkg-config --modversion freetype2

> When I run `pkg-config --modversion freetype2` on my Ubuntu 20.04, I > get weird version number: `23.1.17`. This does not look like a > freetype version number at all to me. It's the libtool version, which is the important thing. It is an abomination to make tarball versions equal to DLL ver

new version soon

Folks, I'm cutting a new version today or tomorrow. Any last urgent things to consider? Werner

Re: [Freetype-devel] Re: GSOC

> Can I create a separate branch in the freetype2 repository as suggested by > Werner? ( > https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00033.html) You did the right thing :-) >> * I ask you to put your stuff into a private branch called >> 'xxx-projectname', with 'xxx' ident

Re: Requirements from external logging library

> As according to my GSOC project which is integrating an external > logging library with FreeType. I need some help gathering the > requirements that the external library should satisfy. > > From earlier discussion, below are basic some requirements: > > 1. It should be written in C language (f

Re: new version soon

>>> Do you mean >>> https://www.freetype.org/freetype2/docs/rasterinfo/rasterinfo.html ? >>> I do not think RasterInfo.ttf was ever considered a part of FreeType. >> >> Yes, that's what I was referring to. If not included, the packaged >> documentation is left with a broken section. > > Do you m

FreeType 2.10.2 released

FreeType 2.10.2 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

Re: [freetype2] master 652f886: [smooth] Stop using dedicated LCD modules and classes.

> diff --git a/include/freetype/ftmodapi.h b/include/freetype/ftmodapi.h > index 01cb5fb..64735ff 100644 > --- a/include/freetype/ftmodapi.h > +++ b/include/freetype/ftmodapi.h > @@ -65,7 +65,7 @@ FT_BEGIN_HEADER > * psnames > * raster1 > * sfnt > - * smooth, smooth-lc

Re: GSOC - Distance Fields

> I can't decide which format to use for storing the SDF(signed > distance fields). I think using floating-point values (fixed-point > in this case) for generation will be more accurate than using > integer, but then saving the SDF to a file will require a > conversion. > > So there can be few t

Re: [Freetype-devel] Re: GSOC - Distance Fields

> Oh, I see the value to be stored is in a range [-1.0, 1.0]. > I want to hear the comments from other developers :-), > whether the initial implementation should be FT_F2Dot14 (16bit) > or float (32bit, at least). Well, we have dropped 16bit support already, so it's only a question about storag

Re: [Freetype-devel] Re: GSOC - Distance Fields

> [...] Initially I thought that FreeType supports saving glyph > bitmaps to file. But Alexei clarified that. So now I think the > saving part can be left to the external application to decide. OK. >>> What 'image' dimensions are we talking about? Usually, Freetype >>> glyph bitmaps are very

Re: [freetype2-demos] master 1612259: [ftview, ftstring, ftgrid] Unify gamma adjustments.

+ void + FTDemo_Display_Gamma_Change( FTDemo_Display* display, + int dir ) + { +if ( dir > 0 ) +{ + if ( display->gamma == 0.0 ) +display->gamma = 2.3; + else if ( 2.25 - 0.1 < display->gamma && display->gamma < 2.25 ) +

Re: Logging Library-GSOC

> I was exploring the logging libraries as per the requirements, and I > was thinking of adding functionality to automatically check whether > the logging library is installed or not as FreeType does for other > libraries like Harfbuzz and libpng. Not sure whether it makes sense at all to use th

Re: Odp: Re: The TrueType rendering accuracy nightmare

> I fixed some bugs in a development version, which would make the 2.0 > version of TD renderer significantly more accurate than 1.0. > > https://i.imgur.com/oKDg7F1.png > > I also made sure to research how dropout control works and implement > much more accurate rules than in TD renderer 1.0. S

Re: Odp: Re: The TrueType rendering accuracy nightmare

Hin-Tak, > There is a bilevel mode in ft2-demo, and you can also switch to v35 > to match Microsoft better in ft2-demo, from the default v40. I told > you so, many emails ago, in my first reply. > > If you feel that you know fontforge and freetype well enough to tell > which is fontforge and

Re: Build system considerations

>> > In the end, and this is personal opinion, I find Meson cleaner than >> > CMake, I don't have to have a look at Meson to believe this immediately :-) >> I'd vote for removing CMake support. Its inofficial status means that >> people shouldn't rely on it anyway, even if there inevitably are >>

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

> Also in the last message you said you would explore logging > libraries, and I would be curious about the results, i.e.: > > - Can you give one *concrete example* of an actual logging library > that would be useful for FreeType developers for development > purposes. Because I failed to find

Re: Patches to remove Jamfiles from freetype2 and freetype2-demos

> Here are two patches to remove the Jamrules/Jamfiles from the build > and documentation. Applied, thanks! Werner

Re: Odp: Re: The TrueType rendering accuracy nightmare

>> if you ask FontForge for B/W rasterization it uses FreeType in v35 >> mode. In other words, the rasterization results returned by >> FontForge in this case are *identical* to what ft2-demo returns. > > I happened to be cleaning up my github account lately - so I have an > up-to-date clone of

Re: [patch] Remove obsolete HAVE_STDINT_H probing

> It turns out the macro is never used, anad is never > included. Committed, thanks! Werner

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

David wrote: > I'm sorry but that doesn't make any sense to me. There is > absolutely no point in making part of FreeType depend on a specific > external logger library at this point. Also we don't even know > which library, or which API. This looks like a solution looking for > a problem. >

Re: Logging Library-GSOC

Hello Priyesh, > Clearly there is some problem with the current logger, but I think > the requirements which are mentioned on the FreeType's GSoC page and > the requirements which are discussed being here are different... I don't think so. It's only that David T. is back, and he wasn't part of

Re: GSOC

Hello Greg, > There appears to be some issue with my school's awful email service > and your mailing list so I've created this account in hopes I can > better get/send messages. thanks for that. > I did reply to werner multiple times but I guess they were missed. Indeed, I haven't received a

Re: [Freetype-devel] Re: GSOC - Distance Fields

> > [...] go ahead and write a standalone program that calculates DF > > for a outline glyph in whatever format you choose or is > > appropriate. > > I have written the program, you can find it at: > https://github.com/preversewharf45/freetype2-sdf > To view the output I'm currently using a small

Re: [Freetype-devel] Re: GSOC - Distance Fields

>> However there is an issue with the program, the glyphs which >> contain intersecting contours have an issue. (example: >> https://imgur.com/MxJfAwY) > > The intersecting contours used to be discouraged and [are] still > quite rare. [...] This is no longer true: Variation fonts have officia

Re: Logging Library-Week 1

[Please try to write plain text e-mails that don't rely on HTML formatting.] Hello Priyesh, > The coding period has begun, and now I will begin exploring the > logging libraries. According to my proposal, I have given 3 weeks > for the exploring phase. I will keep updating you about the > p

Re: GSOC - Distance Fields

> > I think we do want a 8bit representation at least, and possible a > > higher one. > > Currently I am using 32bit floats, but since freetype doesn't use > floats I am thinking of using 32bit 16.16 fixed point instead. I think this is the right choice for intermediate computations. Alexei gav

Re: GSOC - Distance Fields

Dear all, please stay constructive and civilized. No need for personal attacks – in the end we all want the same. I'm glad that there are experts on the list who want to share their experience, and who are willing to help Anuj so that he succeeds. I believe that it is a big help to have diffe

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

Hello David, > This bundle contains patches to replace all #include FT_XXX_H > statements from the library into the corresponding #include > include. Thanks! If I understand you correctly, the idea is to 'normalize' FreeType so that it looks similar to other libraries, not alienating users wi

Re: Logging Library-GSOC

Hello Priyesh, > This week I have explored several libraries and I have prepared a > report mentioning their pros and cons @here > thanks for that. Very informative. A quick comment: I think we

Re: GSOC Build tests

Hello Greg, > So over the week I started writing continuous integration build > tests for several platforms. You can preview them here: > https://dev.azure.com/fundies/freetype2/_build/results?buildId=146&view=results this looks great! > Please let me know if there are any additional compiler

Re: Logging Library-GSOC

> I am currently looking at a library called EasyLogger ( Github Link: > https://github.com/armink/EasyLogger ). I would say it could be my > favourite logging library as it satisfies most of the > requirements. But the problem is that the plugin which this library > uses for outputting logs to

Re: Logging Library-GSOC

> The gnulib repository provides a module 'unistd' for creating a > 'unistd.h' header file; this works on Windows too. > > https://www.gnu.org/software/gnulib/ By the way, the gnulib repository also provides an interface to threads – including Windows. If you install the corresponding modules

Re: [Freetype-devel] Re: GSOC - Distance Fields

> So, I have been trying to convert my code to FT_Fixed for a few days > now without any success. [...] > > As for bezier curves, there is almost always an overflow because > while solving polynomials some large numbers are involved. I even > tried using Newton's approximation, but it's too sl

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

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

Re: Logging library

> I want to raise same concerns that David did in a thread a few > months ago. > > I don't think a logging library is neither needed nor appropriate > for FreeType. Werner, can you please summarize why you think this > is a good idea? See https://lists.nongnu.org/archive/html/freetype-devel

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, whate

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

> Thanks Werner, the patch looks good to me :-) OK, applied. Werner

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

> And here's the patch to fix freetype2-demos compilation first. Applied too, thanks. Werner

Re: FT_Add_Module() and related functions

> I don't think we want to statically link any SVG renderer to the > library by default. There are so many subtleties related to vector > graphics rendering, that there is no "good" default choice to make. > In other words, any default we select at link time would probably be > inappropriate for

Re: Logging Library-GSOC

> I find it a *very* bad idea to have code in FreeType that would > write to a file. Specially bad if that can be controlled by an > env-var. Interesting. Please explain. Do you fear security issues? > I still think what's desired can be done best by just revamping and > writing custom code

Re: [Freetype-devel] Re: GSOC - Distance Fields

>> How many times do you have to solve this for each glyph? > > A considerable amount of time. If you want the exact number it is > `width * rows * number_of_conic_curves', without any optimization. Ouch. >> How many different solutions (aka curve points) do you have to find >> for each curve

Re: [Freetype-devel] Re: GSOC - Distance Fields

> Did you miss the last two mails from Alexei and me? I missed a few > mails a few days ago for no reason and even got a few duplicate > mails. I think I received everything. It's only that sometimes I start writing an e-mail and finish it hours later – in this case, Alexei has answered meanwhi

Re: [Freetype-devel] Re: GSOC - Distance Fields

>>> - Your handling of two edges meeting at a corner is solid. That's >>> exactly what we do in GLyphy. However, I'm also now convinced >>> that there is no way to produce SDF from contours that might >>> overlap. Imagine a "+" sign that is two straight contours. You >>> cannot find t

Re: [Freetype-devel] Re: GSOC - Distance Fields

> For SIMD, I studied what's available last year for HarfBuzz. I > documented what I found here: > > https://github.com/harfbuzz/harfbuzz/blob/simd/src/hb-simd.hh Thanks for the link, it's an interesting read. > If you use floats internally and fill in the distances, then you can > do SIMD

Re: [Freetype-devel] Re: GSOC - Distance Fields

>> IMHO, in FreeType, SIMD support is something to be done in >> addition, not as a replacement. Since Anuj makes quick progress I >> suggest that he first concentrates on the fixed-float route. If >> there is some time left we should check how SIMD can be >> implemented. > > Just to clarify,

Re: [Freetype-devel] Re: GSOC - Distance Fields

>> - I highly suggest you stick to float internally [...] > > I still think `float' is a better option for generating SDF, > especially in lower resolution glyphs where fixed-point produces > kind of straight lines instead of smooth curves (which is not > noticable if you look at it briefly). P

Re: Logging Library-GSOC

> After going through log4c, I don't think I have any more options to > look onto... If you guys know any more logging libraries, please > let me know... I think you did a great job with your exploration. Do you think that you already can suggest a library that fits best? Werner

Re: [Freetype-devel] Re: GSOC - Distance Fields

>> Please elaborate. It's not clear to me what you are referring to, >> and what the problem is about. > > If you checkout this (https://i.imgur.com/hw4vrZL.png) which is an > ascii character `0' at pixel size 31, you can see that fixed point > deviates from the actual path slightly, which does n

Re: woff2tags.h copyright date

> I've been running copyright checks for Debian, and came across > src/sfnt/woff2tags.h. > > The copyright statement lists 1996-2020. > > Can I just check why this 1996 is the starting date, instead of > 2019, when the file was created? Certainly a copy-and-paste error, now fixed in git. Than

Re: intel compiler support interest?

> I think it makes sense to first disable the vectorized code path to > get the source to build properly with the Intel compiler. A second > patch could try to optimize the code using Intel intrinsics on x86 > and x86_64, this would probably be portable to more compilers. Not > sure this is wor

Re: Logging Library-GSOC

> During the exploration phase, I have seen several libraries and > according to me *dlg* is best suited for the requirements: OK, then let's try this library! > In previous mails, Armin suggested to move some of the FreeType's > logging functionality to the external logger but according to my

Re: [Freetype-devel] Re: GSOC - Distance Fields

>>> Also I'm surprised that you haven't put the code get_min_distance >>> code for each edge type into a function. Would you prefer that I >>> comment re these on github? >> >> I don't think that will be necessary. I will fix that while adding >> in FreeType. That repository is just for testing

Re: [Freetype-devel] Re: GSOC - Distance Fields

> Systems without an FPU are vastly less common than they were 20 > years ago. They still exist, and is a defendable position to want > FreeType to continue to work on those systems, [...] Honestly, I think this an issue even today – just think of the Internet of Things stuff, which demands that

Re: [Freetype-devel] Re: GSOC - Distance Fields

> One more thing, shouldn't it be a `minmum level of warnings.' ? > http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftgrays.c#n441 No, I don't think so. I interpret the text as that you can switch on the maximum number of compiler warnings by suppressing warning 4324.

Re: Logging Library-GSOC

> Also I have updated the progress report for 3rd week @ here > Thanks! The recent discussion with Behdad reminded me to ask you whether you have also investigated the case where you modify the ex

Re: GSOC Build tests

Hello Greg, > Over the past couple weeks I've converted the build tests to use > autotools for the three desktop OSes. I've managed to leave the > cmake tests intact too. I also now have demos building against the > freetype version pulled in the CI. Thanks! > I wasted quite a bit of time tr

Re: [Freetype-devel] Re: GSOC - Distance Fields

> I added functionality to set renderer properties (namely the > `spread' parameter). So, there is API for this `FT_Property_Set' > and `FT_Property_Get'. Is there any similar API for setting the > renderer specific modes which is defined by the > `FT_Renderer_SetModeFunc' function, or do I get

Re: Logging Library-GSOC

> > The recent discussion with Behdad reminded me to ask you whether you > > have also investigated the case where you modify the existing > > debugging and tracing code of FreeType without using an external > > library. For example, such new code might be based on the code from > > 'dlg' but st

Re: Logging Library-GSOC

> [...] Therefore, according to me if you are concerned about the > additional code that we need to add along with using dlg, it would > be much less than the code if we develop a logger inside FreeType > with all of the above the requirements and support on different > platforms. OK. > I would

Re: [Freetype-devel] Re: GSOC - Distance Fields

> One more thing. I think the OpenGL demo is not good for everyone to > test, so I will working on a demo similar to 'ftview' in my spare > time. Great! Werner

Re: Logging Library-GSOC

> I have updated the progress report for this week @ here > > It contains a brief description of all the useful APIs provided by > dlg Thanks, looks promising. If you are going to import the 'dlg'

Re: [patch] Simplify ftconfig.h

> We should also decide whether to chose a dash or an underscore as > the word separator for header and source file names :-) I have no > favorites here, but being consistent will be less ambiguous for > everyone. I definitely prefer '-' over '_'. Werner

Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

> In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland > (Google Fonts) and myself (Blink/Chrome) ... and Behdad Esfahbod ... > we have proposed and published an OpenType extension to the COLR > table to bring color gradients to color vector fonts. Thanks. Are there fundament

Re: [patch] Simplify ftconfig.h

> Here's the rebased and updated patch then. Thanks. However, what you've sent are actually two completely separate things: The splitting of `ftconfig.h` into smaller files, and the modification of `FT_BASE' and friends. Please change this into two separate commits, which makes it much easier

Re: [freetype2] anuj-distance-field 145c3c6 4/4: [sdf] Make squared distances toggleable.

> + /* If it is defined to 1 then the rasterizer will use squared distances */ > + /* for computation. It can greatly improve the performance but there is */ > + /* a chance of overflow and artifacts. You can safely use is upto a */ > + /* pixel size of 128.

Re: [Freetype-devel] Re: GSOC - Distance Fields

> I have created the demo program, it can be used to view raw SDF > without any bilinear filtering and there is no way to reconstruct > fonts from SDF because again it doesn't have bilinear filtering. I > will add that soon. Thanks, will test soon. > There is a pretty weird issue that I ran in

Re: Logging Library-GSOC

> Throughout this week I have integrated dlg with FreeType and I was > able to achieve the following goals: [...] Thanks! > [...] I am facing a problem with printing FT_COMPONENT and > Time-Stamp along with log messages part... The problem is that this > extra information is printed every time

Re: [patch] Simplify ftconfig.h

> Yes, here's it is as a bundle of 5 intermediate commits. As a > reminder, to use it, do: > > git remote add bundle /path/to/bundle > git fetch bundle Thanks! I've normalized the commit messages by converting them to proper ChangeLog entries, then committed to git. Note, however, that there

Re: Logging Library-GSOC

> > Since debugging isn't time critical it might be necessary to add > > an additional step that scans tracing messages for newline > > characters, then massaging the output by inserting the time stamp. > > In other words, all occurrences of `\n` should be replaced with > > `\n[time stamp] ` or s

Re: [patch] Simplify ftconfig.h

> [...] compilation of the the demo programs fails with > > freetype2-demos/src/ftbench.c: In function ‘face_requester’: > freetype2-demos/src/ftbench.c:165:5: warning: > implicit declaration of function ‘FT_UNUSED’ > [-Wimplicit-function-declaration] >FT_UNUSED( face_id

Re: Logging Library-GSOC

> I have added some changes to produce the desired output using the > previous approach specified by you. With this approach, I have to > make very little changes in some FT_TRACE calls for better > indentation. Would that be OK with you? Of course. Please send a separate patch for these fixe

Re: [patch] Simplify ftconfig.h

> Werner, please don't commit something if you think there are still > problems in it, that's what code reviews are, Normally, I do that. However, I've already invested a lot of time in writing ChangeLog entries... > See attached patch for a fix. Applied, thanks. Note, however, that there are

Re: Logging Library-GSOC

>> Of course. Please send a separate patch for these fixed so that I >> can apply it to master directly. > > Ok, I will provide you the patch once done... Thanks. >> Very nice! Do you have some data how large the slowdown is due to >> the additional code? > > No, As I haven't done software p

Re: Logging Library-GSOC

>> Oh yes, you can! Either you modify the source code of 'dlg' within >> FreeType, or – which is better IMHO – you submit a feature request >> or patch to the 'dlg' maintainers that allows control of the '{' >> and '}' characters for marking tags. I see no reason why this must >> be hard-coded.

Re: Logging Library-GSOC

>> What do you mean with 'toggle'? > > In one of the previous mail, you mentioned that you wanted to print > FT_COMPONENTS along with actual log message only when there is some > string present in the FT2_DEBUG env variable. Therefore, I wanted > to ask about what exactly do you have in your mi

Re: [patch] Simplify ftconfig.h

>> However, I've already invested a lot of time in writing ChangeLog >> entries... > > Would you consider dropping the ChangeLog entries. Basically, I don't object to that. However, experience has shown that people tend to write very sloppy git commit messages in general. The ChangeLog format e

Re: [Freetype-devel] Re: GSOC - Distance Fields

> You can check out the demo here: > https://github.com/preversewharf45/ft2sdf-demo The build process is > the same as ft2-demos. The freetype2 library is added as a submodule > so use --recursive. It's actually `--recurse-submodules`... > And it only works properly on windows. On GNU/Linux the

Re: [Freetype-devel] Re: GSOC - Distance Fields

>> It's actually `--recurse-submodules`.. > > I think they are both the same. They both do exactly the same thing > for git clone. The ` --recurse-submodules` was added later to avoid > confusion or something. Interesting. The manpage of git 2.26.2 no longer contains a reference to `--recursi

Re: GSOC Build tests

Hello Greg, >> Over the coming week I plan to write some functionality tests. I >> believe my best course of action for this is just to use the >> existing freetype demo programs in tandem with some bash scripting >> to check for inconsistencies in various fonts between commits. I >> will hop

Re: Logging Library-GSOC

> I have made the required changes in the dlg library according to the > requirements and submitted a pull request ( > https://github.com/nyorain/dlg/pull/5 ) one day ago and I am waiting > for the dlg's maintainer to respond to it. Thanks a lot; the discussion looks interesting. > I have tried

Re: [Freetype-devel] Re: GSOC - Distance Fields

> I have added all the optimization modes to the module. Great, thanks! > By far the fastest method is to subdivide the curve into a number of > line segments. [...] OK. I'm glad that you took the time to implement the various algorithms so that we have such a comparison. > The major downsi

Re: [Freetype-devel] Re: GSOC - Distance Fields

> I have updated the demo, added bilinear filtering, shape > reconstruction and has all optimization modes which can be toggled. > I have attached the new list of keys. > (https://github.com/preversewharf45/ft2sdf-demo) Looks excellent! Some items for the wishlist of `ftstd`: * A help menu sho

Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.

> * src/sdf/ftsdf.c (*): Replaced `FT_QNEW' and `FT_ALLOC_MULT' to > custom macros in order to track memory allocations throughout > the process of generating SDF. It basically add the memory > being allocated to a static global variable and at the end > outputs it at

Re: [Freetype-devel] Re: GSOC - Distance Fields

>> I would be less worried about FT_Property_Set if FreeType reserved >> the right to remove (ignore) or change properties when it is >> reasonable to do so, i.e. properties should not be considered a >> part of API. > > Does that mean I shouldn't use `FT_Property_Set' ? For some > parameters su

Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.

>> I think having a global variable for that is a bad idea, even if it >> is only active in debugging mode: If you have multiple threads you >> will get nonsense information. Isn't it possible to add this >> variable to one of the existing structures? > > Thanks for pointing that out. I can us

Re: Logging Library-GSOC

> I have added an option in `FT2_DEBUG` environment variable to > enable/disable the printing of FT_COMPONENT and Timestamp with a log > message. Looks good, thanks. > After looking at builds/windows/vc2010, builds/windows/visualc and > builds/windows/visualce I can see that they all depend on

Re: Logging Library-GSOC

> I was trying profiling on the example program given @ here > . I > have used the profiling tool inbuilt in Visual Studios but was > unable to extract useful information from it, therefore I have tried > a solution provided on Stack O

Re: Logging Library-GSOC

>> *Have you set `FT2_DEBUG=any:7` in the environment?* > > Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with > OpenSans-Bold.ttf font. OK. > Also, I wanted to ask is this the right approach for profiling? I'm not an expert, sorry. However, you might also try `valgrind --tool

Re: [freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

> How is this: > https://lists.nongnu.org/archive/html/freetype-commit/2020-07/msg00067.html > ? Nice! However, I think it's better to have two versions of `SFD_ALLOC` and `SFD_FREE` depending on whether debugging is enabled or not. There should be zero overhead for the non-debugging case. Hav

Re: Logging Library-GSOC

> I have tried the query performance counter/frequency method for > example program: > (https://www.freetype.org/freetype2/docs/tutorial/example1.c) on > Windows with arial.ttf and FT2_DEBUG=any:7 on > string:"qwertyuiopasdfghjklzxcvbnm" which produced 24260 logs. > > I have executed the test pro

Re: [freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

>> Having two versions would also allow to use a function internally >> so that you can (a) avoid the `do {} while (0)` construction, and >> (b) still use the macro within a conditional. > > I thought about that, but if we create a function then the memory > dump won't print the actual line numb

Re: Logging Library-GSOC

> When I am redirecting stderr logs to a text file using: `main > arial.ttf qwertyuiopasdfghjklzxcvbnm 2>sdterr_logs.txt` I am getting > the following results: > > `FT_LOGGING`: 8 sec > `FT_DEBUG_LEVEL_TRACE`: 11 sec This still looks fishy. >> Otherwise I guess the big difference between `FT_LO

Re: [nkoo, N'KO identification issue on Ubuntu 20.04]

Hello Moustapha, > I'm Mr Kourouma Moustapha, i used to use N'KO as language in Ubuntu. > I have already installed ttfautohint (see below) but  i don't find > nkoo nor N'KO in the list of languages available. > > :~$ sudo aptitude search ttfautohint > > p   libttfautohint-dev    - Automatic

<    10   11   12   13   14   15   16   17   18   19   >