RE: fuzzing SDFs
>> I did check it out and I think simply adding the new render modes to >> the render mode list should be sufficient. [...] > > Looks good! Please submit a Pull Request that Armin (and others) can review. Agreed! :) > Note that a major problem will probably be timeouts: Right now it can happen > that the fuzzing code wants to render too much glyphs in one run. Since the > SDF mode is really slow I guess we will see much more of such issues, which > can become a hassle. > > Armin, do you have ideas how this could be improved and/or avoided in > general? I think generally there are two options: - We do have a few screws at this point to steer how many glyphs we're looking at in a single fuzzer run. We could either use one of the existing ones or, if they are to coarse, we could introduce new screws that specifically target the SDF mode. - Alternatively SDF could get it's very own fuzzer. We've already done this to separate rendering from utility access; we _could_ look into further separating fuzzing rendering from fuzzing SDF rendering. Although, that would be quite a lot of work.
RE: fuzzing SDFs
>> now that SDF support is publicly available I think it might be useful >> to extend the `freetype2-testing` repository with a fuzzer. Would you >> like to have a look to check whether you can implement this? > > Sure, I'll see how it works and try to implement. Oh this is very exciting! :D Anuj, there is a lot of documentation in form of READMEs in this repository to hopefully give you a high-level idea of how this thing is kind of put together. I reckon, a good entry point to probably this script: https://github.com/freetype/freetype2-testing/blob/master/fuzzing/scripts/custom-build.sh; just run it and it will prompt you for details :) Armin
RE: Replacing Boost dependency in ft-testing with explicit constructor deletion?
>> 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, I am -- there are currently two PRs that I'll hopefully get to this weekend :) The boost one is conceptually simple, I just have to get to grips with the fact that we're losing it (and potentially replace it with code I wanted to avoid initially) *sob* > so I guess this code will be soon in his repository. I would like to stress that it's _our_ repository ;) Best Armin
RE: Migrate to github
Hi Anurag + Werner, > 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 > > so a group called 'freetype2' is what we have to take. Sorry for my late reply there + for the troubles that this may have caused but also good news: I reserved gitlab.com/freetype back when we started github.com/freetype and we can+should obviously use it!! :) I am currently on holiday so my responses might take a little bit longer but let me know if there are specific users that I should add and I'll do it asap (feel free to send me private emails); it's currently just Nikolaus + me as "owners" and "freetype2-testing" mirrored from GitHub :) Best Armin
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 something similar. This would print wrong-ish timestamps that couldn't really be used for profiling (I mean, it could; you just have to know which timestamp belongs to which message). I would suggest to rather store a flag after reading `\n` and attach the timestamp to the following message. Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that this is followed by an IO operation. To be tested though :) Writing this lead me to look for multi-linebreak traces (e.g. src/pcf/pfcread.c:504) -- should that have one timestamp for the entire statement or one timestamp per line? Armin
RE: Logging Library-GSOC
Hi Priesh,
>> In previous mails, Armin suggested to move some of the FreeType's
>> logging functionality to the external logger but according to my
>> analysis, none of the external logging libraries that I have
>> explored exactly matches the logging architecture of FreeType
>> (i.e. logging based on debug level of components and debug levels of
>> trace calls). According to me, this is not possible with dlg
>> library [...]
>
> This is not a problem at all.
Don't worry about that -- I was just thinking out loud about things we could do
:)
> (For Armin){
> I have looked into log4c, [...] but I am not sure about it on windows [...]
> }
I do like that notation style ;) Apart from that I for sure have not used it
on Windows; don't worry about that either and thanks for double-checking! :)
As you are now moving into the implementation phase of your project I would
quickly like to recall my message from about a month ago:
https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00165.html.
Don't worry about exact naming and we might need more functions and/or more
arguments but outlining the general idea: I would very much appreciate it if
we could find a way to wrap FT logging into a public interface that works
something along these lines. So basically there's a default log callback
implemented internally that listens to environment variables (and/or other,
more dynamic inputs) and then there's a way to overwrite this callback from the
outside by providing (a) custom function(s). All details are obviously up for
discussion :)
RE: Logging Library-GSOC
> No, I haven't thought in that direction as according to the requirements least > coupling is favorable... I think (but happy for everyone with other opinions to chime in + discuss) at this point the only real hard constraint in that regard is that we want to wrap the logger into FreeType specific macros and not expose it directly in the core codebase. In addition, `FT_TRACE*` and `FT_ERROR` should not be replaced or changed (unless there is a really good reason that pretty much everyone agrees on). However, I could see how e.g. the usage of `FT_COMPONENT` could be slightly altered (or an additional macro introduced) if that helps with moving more functionality into the logger. As I understand it, parts of this project is to generally enhance tracing + logging within FreeType. Apart from platform independent write-out, timestamps, custom callbacks, etc ... this _could_, in my opinion, also include moving the handling of logging + tracing out of the core codebase (if / as much as this is reasonable) as this could open up a lot more flexibility down the road (depending on the logging library in question + should be discussed separately). I believe that, once we are able to hook a specific logger into FreeType with just a few macros, replacing that logger might become a reasonably easy task, should requirements change. Thus, unless Werner disagrees, I believe it would be interesting to explore that option and understand if / how easily this can be done (and to what extent). Best Armin
RE: Logging Library-GSOC
Hi Priyesh, > I have updated the progress report for this week @ > https://docs.google.com/document/d/1X5ApmVxz0pXcGUCF9Um5VhVZV403LWDIYFbKYg1aLoQ/edit?usp=sharing Thanks for your update & write-up, looks promising :) I agree with your approach of trying to find the most lightweight C logger that does the job, just two quick questions about your work: (1) do you plan to mainly using the logger to write to files and an equivalent of `stderr` consistently across multiple platforms or do you also plan to use it to replace some of the handling that's currently done within FreeType (like checking + parsing log levels + components, etc) with calls to that library? I believe it would be especially interesting if we managed to move some of the components handling out of FT and into that external piece. Not sure however, if any of these libraries have a somehow direct mapping of how components (modules) are used for tracing within FT currently (essentially, all components/modules can be configured with their own trace level). (2) have you looked into log4c at any point? Not saying it is what FreeType needs but something that worked reasonably well for me a while ago; might be a lot bigger than what we need or have other downsides, just asking b/c I couldn't see it in your list. Best Armin
RE: GSOC
Hi Greg, > My plan is to write a basic compilation test and render test for one font to > start then build upon that. Sounds good :) > I could use some suggestions on types of render modes and types of fonts to > test as well any common pitfalls you see in commits. I think we should aim for a broad spectrum of different modes + fonts that can be plugged + played as we see fit. Thus, I suggest to start using any modes and fonts that you prefer and we can define specific cases along the way. Let's aim to build a flexible framework rather than a very specific setup. Best Armin
RE: Logging Library-GSOC
Hi Priyesh, > 2. Modifying the output stream at runtime. > >a. Dynamic change of desired output log levels. >b. Dynamic log redirection. > > [...] > > All of this should be configurable either with a config file or with > environment variables. I'm not sure how item 2 can be handled best; if this > feature is active it maybe makes sense to force re-reading of environment > variables and config files as sonn as a FreeType API function is called. I believe a good way to handle point 2 (and blend in well with the rest of the project) is to allow overrides of the these values (from the config file or env variables) with dedicated functions at runtime; something like ```c FT_Trace_Set_Level( FT_Trace_Level level ); typedef void (*FT_Trace_Callback)( FT_Trace_Level level, const char* fmt, va_list args ); FT_Trace_Set_Callback( FT_Trace_Callback callback ); FT_Trace_Set_Default_Callback( void ); ``` Note this is just a quick sketch and the actual callback function might have a forth parameter for the module ... or this can be part of `fmt` and `args` ... tbd :) One thought also on the timestamps: let's plan them flexible please (at least on/off toggle-able per env variable) as there's a good chance that you want to use your own TS format when retrieving the logs through the callback. I totally agree with the rest :) Have a lovely Sunday, Armin
RE: Logging Library-GSOC
> Armin, could you chime in and add your opinion? Gladly, sorry for the delay guys! >> 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. >> >> Also we don't necessarily send logs to stderr, e.g. there are already >> several versions of ftdebug.c, i.e. the one under builds/windows/ uses >> OutputDebugStringA(), or the one under builds/amiga/ uses KVPrintf(), >> etc.. All Werner wants is structured outputs, which can easily be >> done in the current code base with minimal refactor of the FT_TRACE >> macro implementations. > > Mhmm, yes and no. For example, if you want to have time stamps in the logging > output, too, you have to take care of the OS since you are entering > platform-specific behaviour. It would be nice if this is completely hidden. Agreed; also in addition, the two biggest things to be improved from my perspective: 1. Dynamic change of desired output log levels 2. Dynamic log redirection I've recently been working on long-running (for days/weeks straight) video transcoders, depending on several libraries like FFmpeg, FreeType, ... One thing that is 100% needed is to change log levels on the fly (enable more logging as things go south) and be able to redirect logs to wherever I want them to go, separate for each library, maybe prefixed differently on the fly (files, memory, ... best case, again, changeable at runtime). I consider both things reasonably standard and something I'd love to see in FreeType as well :) About external dependencies: everything you don't build yourself leaves more time for the things you actually want to build. I do get the concern (it's a trade-off) but the question IMO is how easy it is to replace dependencies. In terms of an external logging library I imagine it to be very easily replaceable should that become interesting at some point. A few more thoughts about recent messages (didn't chime in since, by the point I read it, it was already answered in a way that I agreed with): - 100% submodule + static linking - Let's keep using various FreeType macros within the code base and use the external library mainly for writing out + the filtering / forwarding / flexibility part The biggest upside of an external logging lib IMO is not to care about its implementation and cross platform compatibility, just use something that's been tried + tested and spend all the more time on the core business of font rendering. Also provide users of FreeType a way to extract logs in an extremely flexible way that does not require users to dig deep into the implementation of the codebase in order to write a personalised log callback function that filters and converts relevant logs and requires users to do all sorts of nasty downcasts that really only library implementers are comfortable doing. Just a few thoughts, happy to discuss further :)
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
>> Whether with -wrapv or with the unsigned macros, we simply disable >> some compiler optimizations, perhaps some good optimizations too. > > Most certainly, yes. But there are a lot more things that slow down the > potential performance of FreeType -- C in itself is a trade-off between > maintainability and performance. > >> Why? Is it because we got scared? There is absolutely no evidence of >> real bugs in FreeType. It is reasonable to disable optimizations with >> -wrapv, if scared, but macros are too rigid. Some compilers recognize >> /* fall through */ comment to suppress particular warnings. I wish we >> could just add a comment to silence these warnings after adjudication. > > It's not about being scared but about making sure we understand _what_ the > code within FT does. If we proactively mark operations that have a certain > behaviour we make those operations explicit to whomever reads that thing in > the future. `-wrapv' has two downsides IMO: (1) we lose track of what it > does and _where_ ... maybe, really covering up bugs (2) we rely on 3rd parties > to compile FT in a very specific way to avoid certain types of reports. For reference, find the patch attached (most code in that area is already wrapped in `*_LONG' macros). @Werner: should I apply it? Armin 977845.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
> Whether with -wrapv or with the unsigned macros, we simply disable some > compiler optimizations, perhaps some good optimizations too. Most certainly, yes. But there are a lot more things that slow down the potential performance of FreeType -- C in itself is a trade-off between maintainability and performance. > Why? Is it because we got scared? There is absolutely no evidence of real bugs > in FreeType. It is reasonable to disable optimizations with -wrapv, if > scared, but macros are too rigid. Some compilers recognize /* fall through */ > comment to suppress particular warnings. I wish we could just add a comment to > silence these warnings after adjudication. It's not about being scared but about making sure we understand _what_ the code within FT does. If we proactively mark operations that have a certain behaviour we make those operations explicit to whomever reads that thing in the future. `-wrapv' has two downsides IMO: (1) we lose track of what it does and _where_ ... maybe, really covering up bugs (2) we rely on 3rd parties to compile FT in a very specific way to avoid certain types of reports. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
>> .. and undo those macros? > > Well, if you then can? Signed integer overflow being undefined strikes me as a > severe deficiency in the C language. This of course makes -wrapv a compiler > level workaround, which may not be available to every compiler FreeType wants > to support. Hm. It's one of many oddities of C ... Problem is that it's undefined behaviour and compilers are technically free to do anything with the calculation, including optimising statements away completely that have to be preserved when assuming wrap-around that could, maybe, end up becoming an actual bug with buffer overflow or whatever. Haven't constructed such an example yet though. Also, I agree with both of you: I think the current solution (casting everything for the sole purpose of silencing UB fuzzers) is an ugly way or introducing technically irrelevant overhead to the code base. On the other hand; the C standard is what the C standard is (maybe for good reason, maybe due to lobbying) but at least it is a standard that is being obeyed. As such, I don't think it's a good idea to suggest people should build FreeType in ways that change the C standard on a compiler level. This, sadly, brings us back to the current way of dealing with these things; adding ugly macros that transfer these operations from UB space into defined C space ... Not saying I'm happy with that but I believe this is the cleanest solution in the big picture right now. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
> Thanks for looking into it. FWIW, my commit merely re-enabled an older code > path. NW we've already fixed a lot of those that came up in our own fuzzers :) ... it's actually harmless but a side product of fuzzers throwing super random input at apps. Some overflow when facing gigantic glyphs but no one who's truly interested in rendered results would ever use FreeType with such inputs. The idea is to keep the overflow as it is, but have it done in `unsigned' world where it is actually "defined" behaviour (resulting in the same value most likely tho). I left a comment at https://bugs.chromium.org/p/chromium/issues/detail?id=977845#c7 which would help me figure out the exact line of peril much more quickly :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
Thanks for sending that in -- looks harmless but is worth fixing; if for
nothing else but avoiding these kinds of reports in apps that fuzz FreeType ;)
I'll happily look into it later and provide a fix.
Armin
-Original Message-
From: Freetype-devel On
Behalf Of Nikolaus Waxweiler
Sent: 06 August 2019 20:08
To: freetype-devel
Subject: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer:
Integer-overflow in compute_glyph_metrics
Forwarding the following message I received regarding a fuzzer find.
I'm not sure what to do about it.
-- Weitergeleitete Nachricht --
Von: kkal… via monorail
Betreff: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in
compute_glyph_metrics
Datum: Wed, 10 Jul 2019 00:34:24 -0700
An: madig...@gmail.com
{ "@context": "http://schema.org;, "@type": "EmailMessage",
"potentialAction": { "@type": "ViewAction", "name": "View Issue",
"url": "https://bugs.chromium.org/p/chromium/issues/detail?id=977845;
}, "description": "" }
Updates:
Labels: M-76 Test-Predator-Wrong
Comment #5 on issue 977845 by kkal...@chromium.org: pdf_font_fuzzer:
Integer-overflow in compute_glyph_metrics
https://bugs.chromium.org/p/chromium/issues/detail?id=977845#c5
Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.
Thank You...
--
You received this message because:
1. You were specifically CC'd on the issue
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Reply to this email to add a comment.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Travis CI broken: OSS Regression Suite
>> I am aware of the fact that Travis CI is broken since midweek and I'm >> trying to talk to someone from Travis to get that fixed. [...] > > Thanks! Sorry for spamming, it's fixed already, turns out Xenial broke our build :P - https://github.com/freetype/freetype2-testing/commit/6f46ee5cd0f1aa3ce823876 1d5f17c93e1b353fe - https://travis-ci.com/freetype/freetype2-testing Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Travis CI broken: OSS Regression Suite
Hi all, I am aware of the fact that Travis CI is broken since midweek and I'm trying to talk to someone from Travis to get that fixed. Afaik, we're using a pretty standard setup that's even been advertised in their how-to section so I suspect an issue within Travis CI itself. If anyone is interested in it, the latest failed build is https://travis-ci.com/freetype/freetype2-testing/jobs/220239164 I'll keep you updated once it's been fixed :) Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Accessing FT_Stream API
>>>> Also, I just ran into the issue of `FT_Stream_OpenGzip' requiring >>>> the stream to having a valid `memory' field, which is not provided >>>> by `FT_Stream_OpenMemory' (for obvious reasons). >>> >>> This looks like a bug, both in documentation (which doesn't mention >>> it) and implementation (which doesn't correctly check for a valid >>> `memory' field). > > After some thinking I now believe that we have to solve this issue in a > different way. A stream should always be created with `FT_Stream_New'; among > other things it ensures that there is a valid `stream->memory' field. If you > encounter a situation where `memory' > is NULL it seems that either `FT_Stream_New' wasn't properly called, or > `stream' wasn't set up correctly. Can you investigate that? If I'm not mistaken, one such place is http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftmac. c#n770 (this is where I got my initial idea from :)) ... there are generally a few more cases in combination with `FT_Stream_OpenMemory' and possibly more instances with other initialisation methods. Do you suggest patching those cases or just suggesting `FT_Stream_New' as "best practise" in the future? > So please commit the `memory' checks but not the documenation fix, which is an > internal detail Joe User shouldn't take care of (as Alexei correctly states). Tbh, I'm not sure how much these checks help; if you have half initialised (non-zeroed-out-first) objects from `FT_Stream_OpenMemory', these checks won't help (e.g. in `ftmac.c'). Afaik there's no policy about throwing half-initialised things at `FT_Stream_OpenMemory' (which does not zero-out anything either). These NULL-checks are only useful when used on properly initialised objects which, most likely, stem from `FT_Stream_New' anyways and don't need those checks. Please correct me where I'm wrong! :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Accessing FT_Stream API
>> > This looks like a bug, both in documentation (which doesn't mention >> > it) and implementation (which doesn't correctly check for a valid `memory' >> > field). >> >> Sure, please find it attached :) -- were you thinking of something >> like that? If so, I can gladly push it with a ChangeLog entry, >> otherwise I'd kindly ask for change requests ;) > > I am still confused though. > "memory The memory manager to use to preload frames. This is set > internally by FreeType and shouldn't be touched by stream implementations." > This means that FreeType takes care of it. Now you suggest otherwise. Not sure if we're talking about the same thing but _if_ we are, then the problem arises from `FT_Stream_OpenGzip' requiring a memory manager and due to its interface it can only acquire it through the source stream (spec. since there is no way of addressing the library itself ... there might be a good reason for `FT_Stream' not carrying around `FT_Library'). A such, the source stream within `FT_Stream_OpenGzip' has to provide the manager and whoever throws a stream at `FT_Stream_OpenGzip' has to make sure that such a manager exists. Agreed though, it feels somewhat unclean, at least at first glance. > Elsewhere in FT_Stream_OpenGzip and friends: > "The source stream must be opened before calling this function." > How? Well if a stream resides purely in memory (e.g. a simple conversion from some memory blob to `FT_Stream' with `FT_Stream_OpenMemory') this stream can be considered "opened" by default (IMO?) but it still does not contain a memory handle. Also, afaik, streams without memory handles circulate within FreeType so there might be a chance that they end up as input to `FT_Stream_OpenGzip' when using ` FT_Stream_OpenGzip ' without inspecting the code first. Maybe I got the whole stream interface wrong, however :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Accessing FT_Stream API
>> Also, I just ran into the issue of `FT_Stream_OpenGzip' requiring the >> stream to having a valid `memory' field, which is not provided by >> `FT_Stream_OpenMemory' (for obvious reasons). > > This looks like a bug, both in documentation (which doesn't mention > it) and implementation (which doesn't correctly check for a valid `memory' > field). > >> Anyways ... would it be a good idea to add that requirement (a valid >> `memory field') as defined precondition of `source' to >> `FT_Stream_OpenGzip' etc.? > > Yes. Please provide a patch :-) Sure, please find it attached :) -- were you thinking of something like that? If so, I can gladly push it with a ChangeLog entry, otherwise I'd kindly ask for change requests ;) stream.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Accessing FT_Stream API
>> However, I can only use `FT_INTERNAL_INTERNAL_H' with `FT2_BUILD_LIBRARY' > > That is a fine solution if FT_SYSTEM_H is not enough for you. > https://www.freetype.org/freetype2/docs/reference/ft2-system_interface.html Alright, thanks a lot :) Also, I just ran into the issue of `FT_Stream_OpenGzip' requiring the stream to having a valid `memory' field, which is not provided by `FT_Stream_OpenMemory' (for obvious reasons). Anyways ... would it be a good idea to add that requirement (a valid `memory field') as defined precondition of `source' to `FT_Stream_OpenGzip' etc.? ... as far as I know, streams within FreeType _could_ be created and passed around without valid `memory' fields? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Accessing FT_Stream API
Hi all, what's the best way to access `FT_Stream*' from outside of FreeType? I'm finally building the zipping fuzz targets (GZIP, LZW, and BZIP2) and it would be suuuper handy to create streams on the fly with `FT_Stream_OpenMemory' (and release them with `FT_Stream_Close'). As far as I understand, I need `FT_INTERNAL_STREAM_H' which is defined `FT_INTERNAL_INTERNAL_H'. However, I can only use `FT_INTERNAL_INTERNAL_H' with `FT2_BUILD_LIBRARY' and I think I don't want to set that (no idea what that macro activates but it cannot be good :D). As such, I currently include `freetype/internal/internal.h' manually but it feels hacky; basically: ... #include #include FT_INTERNAL_STREAM_H ... I guess no one ever needs to work with FreeType like that but is this the best I can do or is there a nicer way to include the stream API? Love, Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType vs Gamma Correction
>> > FreeType simply provides *colorless* coverage map, i.e., fraction of >> > each pixel covered by an outline. This coverage is a proportion of a >> > text color to be mixed/blended with a surface color. It is just a >> > proportion, it is never transformed. >> >> Perfect thanks, this is exactly what I expected/meant; sorry for my >> imprecise description :D > > You got it the first time. Even LCD maps are still just coverage maps for each > color channel separately. ClearType filtering or Harmony shifting ensures that > each color channel has the same *integral* coverage to avoid color fringes in > thin features - cut all the crap about visual perception. Thanks so much for clarifying this -- I haven't given gamma correction in combination with FreeType too much thought on a technical level before Veeki's GSoC project; I think I'm all caught up now :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType vs Gamma Correction
>> Please correct me where my assumptions are wrong > > I think you are confused. FreeType simply provides *colorless* coverage map, > i.e., fraction of each pixel covered by an outline. This coverage is a > proportion of a text color to be mixed/blended with a surface color. It is > just a proportion, it is never never transformed. Perfect thanks, this is exactly what I expected/meant; sorry for my imprecise description :D > A client app should be using gamma-corrected colors but it happens outside > FreeType. Thanks, that really confirms what I was after; basically the question if the coverage map is generally considered to be in "linear space". Best, Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType vs Gamma Correction
Nikolaus, Alexei, and everyone else :) I would be very happy if you quickly helped me verify the correct process of using FT to get _correct_ output rendering results (basically what Nikolaus described in his article -- https://www.freetype.org/freetype2/docs/text-rendering-general.html). So really, the best way to apply FreeType to any random surface. My understanding of applying FreeType (the out-of-the-box version, no custom configuration) is: 1. Take any surface in _linear_ space (transform the surface to linear space if required). 2. Take any FreeType rendered bitmap and blend it with the surface however you wish (b/c the _standard_ output bitmap of FreeType is also in linear space). 3. Once done, _after_ blending, "gamma correct" the whole thing by applying the sRGB transformation or the pow-function separately to every channel (R, G, B) of the blended result. Paint the result and be done. Please correct me where my assumptions are wrong (I also gladly accept links to further reads) -- I'm just trying to finally clear out a lot of myths and beliefs that I have about gamma correction in combination with FreeType; also in respect to Veeki's GSoC project. Thanks a lot in advance, Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Modification in FT_Gzip_Uncompress
Good morning Moazin, > I hear a lot about the `fuzzers' here in the community. I tried grepping it in > the library source as well as `freetype2-demos' and found no significant > match. Can anyone here tell me where can I see these fuzzers? > > A google search revealed a folder `ftfuzzer' in src/tools but it doesn't exist > there anymore. :D Hehe your search was close; `ftfuzzer' was used until last summer before it was retired in favour of the new fuzzing framework that was my GSoC'18 project: https://github.com/freetype/freetype2-testing/tree/master/fuzzing :) In short, the fuzzers are a set of test harnesses that try to call the whole API in respect to all different scenarios (font drivers, settings/properties, ...). OSS-Fuzz (https://github.com/google/oss-fuzz) then takes these harnesses and shoots randomized input at it, with the hope of crashing it (https://en.wikipedia.org/wiki/Fuzzing) -- so far, LLVM's AddressSanitizer and UnedfinedBehaviorSanitizer are used to instrument FreeType to find issues and crash the harnesses (apart from timeouts). Due to Google's enormous infrastructure, these harnesses are being worked on 24/7 and with several 100 inputs per second. Due to that, many newly introduced issues (in terms of address violation or undefined behaviour (overflow of signed ints etc)) to code that is already covered by the harnesses can be detected pretty much instantly, giving some peace of mind in terms of CI :) You can find some fixes that are based on OSS-Fuzz' findings in the ChangeLog and the git log by looking for messages tagged with `bugs.chromium.org'. Best, Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Modification in FT_Gzip_Uncompress
>> After using zlib in a separate program on the same data I figured out >> the problem. [...] > > Great! That is amazing work! :) > Please prepare a patch for master. In case there are problems I guess that > the FreeType fuzzers will catch them, probably unveiling hidden bugs. Whoop, whoop I certainly hope so! Also, I hope to find time soon to write specific fuzzers for the support API like discussed with/requested by Alexei a few weeks ago; that would be grand as the fuzzers are generally crazy good at sniffing out issues almost instantly :) A shout-out to Kostya and his team there! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Beta, GSoC] Code Style Guide for FreeType
Hi Nikhil, > Great guide! It's short but super-informative; exactly what people should know > (and can always review) while writing code in FreeType. That is the plan and I hope it works out that way -- anyways please let me know if you come across things that should be added/changed :) > P.S.: s/MarkDown/Markdown Whoopsi, yes haha THX :D ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Beta, GSoC] Code Style Guide for FreeType
> I always wondered if ‘indent’ can do the bulk of the work. I remember using it > a while back and it was wonderful. I basically did not care about formatting, > just ran it periodically. I have no experience with `indent' but I surely believe the process can be automated; the style is consistent enough. Do you still have the setup/options lying around somewhere? Would be cool to attach :) For me personally `emacs' works out of the box btw. Also, I don't mind giving formatting a few extra thoughts as it lets me think about the code I've written at least twice, which is kind of a free code review :P ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Beta, GSoC] Code Style Guide for FreeType
> This is great thank you. I started writing code in FreeType repo for the first > time yesterday and it was taking a lot of time to first decode the "styles" > used and then use them. This will save a lot of time. :-) I'm really glad if it helps -- and please feel free to report missing aspects that you come across :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [Beta, GSoC] Code Style Guide for FreeType
Dear FreeType devs, Werner and I have put together a style guide for writing C-like code for FreeType. By no means is it complete but it should give a quick introduction into the most important aspects/concepts that differ from other C-like code. Please feel free to discuss further aspects that should be mentioned but also keep in mind that this guide should stay super brief in order for people to actually READ it ... knowing that from my own experience -- long guides are rarely read with great attention ;) Also, please refrain from discussing details of FreeType's _code style_ as the style itself is not up for discussion. It's really just about reporting/formalising the existing style and helping out people who start contributing to FreeType. Best, Armin FT Code Style Guide.md Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType development cycle
Hi Moazin, > I want to inquire about how FreeType devs, whenever they are fixing a bug or > adding a new feature, code and test the new additions? I think everyone has their own way of approaching it, just quickly highlighting my approach and, TLDR; your approach pretty much sums it up IMO -- it can just be optimised a bit. > I have the following approach in mind: > > - Code the new stuff in the repo > - Write a program (with a `main' function) that will eventually trigger the > "newly added" part somehow. > - Use GDB to set a break point on the "newly added" part and then step through > it and confirm whether everything works or not. > - Repeat > > This approach feels slow because for each new modification, the library as > well as the program that uses it will have to be rebuilt. Is this the right > approach? Is there a better one? Please let me know. As for ideas: - Build automation via a simple shell script is HIGHLY advisable; have a script that builds the library, builds your main program, links the lot, and also starts `gdb' with the desired settings and the desired input. If that script is then somewhat customisable (e.g. define main features via simple variables), you're pretty well off :) - To speed up the build process of the library, spec. when only a few files are changed, look into `ccache'; it's hella crazy and should speed up your rebuild of FreeType dramatically :) Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType into Chromium autoroller
Hi Ben, > At [0] there is now an autoroller from Chromium's mirror of the FreeType > repository [1] into Chromium. [...] thanks a lot for the update :) > [...] If there are any issues with permissions or being able to see enough > interesting information through these links, let us know. So far I can confirm that I can step through everything I click on; sometimes the system asks for authorisation but my Google account works fine whenever that happens. The whole infrastructure seems pretty extensive though, I might've missed something on my initial walkthrough. Best Armin [0] https://autoroll.skia.org/r/freetype-chromium [1] https://chromium.googlesource.com/chromium/src/third_party/freetype2/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] An analysis of Librsvg
> what annoys me with resvg is that another compiler is needed. I guess that for > unix, there is no problem with package managers, as resvg is is already > compiled. For (native) Windows, i will be a bit more complicated I was thinking about that as well but what about using a different renderer for Windows? _If_ resvg turns out to be `the perfect' solution for Linux that's a big big step. Then, finding something else that's probably equally perfect for Windows might be a better solution altogether than having one thing that works `meh' across all platforms? That's also the core idea about FT's modularity. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] The criterion for comparing SVG Rendering libraries
>> 3. *How much work to do make it work with FreeType*: Does it need a >>C API wrapper? > > Yes. This is really the main criterium IMO; as discussed two days ago, as long as the library is shipped as a prebuilt code blob for most Linux distros, that's perfect and no one needs to care about its source code. Even better would obviously be libraries that come packaged for / are distributed by the top X [insert random number here] Linux distros out there as you don't even have to bother with dependencies. Not necessarily the best source but just something I could come up quickly: https://www.fossmint.com/best-linux-distros-for-laptops-in-2019/ ... maybe someone has better and more credible sources. I think, this is the most important feature of a library to even be considered here: (1) Proper C interface that is well maintained. Some libraries offer, say, a C++ interface first and the C interface is maintained by volunteers which are not directly related to the project. If that can be avoided it's probably a good idea as those half-hearted C interface ports may fall back one day, even if the library itself stays well-maintained. (2) Packaged for / distributed by top X (10/20 minimum?) Linux distros and ... maybe ... even pre-installed on some of them like Ubuntu or such. `Top' has to be defined, obviously, like `most used', `most talked about' or such. >> 5. *Testing: *Is the library well tested? Is there a need for >>aggressively testing SVG glyph renderings from our side? > > `Aggressively testing' on the FreeType side will be done with the fuzzer, more > or less.[*] On the other hand, it is always nice to have an extensive test > suite. Whoop, whoop, I cannot wait to get my hands on it :D > [*] The fuzzer has the tendency to find issues in other libraries > also. For example, the current setup (for Chromium's ClusterFuzz > incarnation) links with `libarchive', and I remember to have seen > about 10 bugs related to it that the fuzzer reported over the last > year. Can confirm ;) Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Supporting OT-SVG out of the box
>> I think Werner took the day off today so let me quickly jump in with a >> few thoughts that might help you until Werner is back :) > > Thanks! It's mother's day... Thanks for reminding me! Haha, joking, already called ;) ... also, happy mother's day, Werner :) >>> 1. We specify `svgnative' and `cairo' as a dependency, just like >>> 'libpng' is defined currently (provided it is configured to be `yes' >>> in ./configure step). > > No. We *only* specify `svgnative' as a dependency. What graphics backend > `svgnative' is actually using should not bother us. During FreeType's > `configure' test for the usability of the library, a function from > `svgnative' should be called that returns the library's graphics capabilities, > namely whether it can actually generate and return a bitmap. Sorry, I missed that part! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Supporting OT-SVG out of the box
>> I assume yes, very much so. FreeType has never used (git) submodules of >> sorts (afaik) and quite frankly, even though it got a lot better, submoduling >> is still pretty painful, even with modern git. (Beware: this is my >> _personal_ opinion) > > I've had a bit of experience with those. Couldn't agree more. Quite painful. > You would have to take care of building all of the submodules within your own > build system, I guess? Exactly, this is one issue that you can avoid when using `installed' libraries instead (if you can). But also the process of setting up submodules, updating them and -- god forbid! -- deleting them can cause a lot of headache. >> In contrast, using (`linking') external libraries on Linux (FreeType's main >> target system) is and has always been easy and super-efficient. You don't >> have to care about _any_ updates (changes to other build systems, e.g.) of >> those libraries and you can link them in all sorts of funny ways (dynamically >> [pretty much standard for many things], statically, or even at runtime within >> your application). Also, you don't have to care about target specific >> weirdness of those other libraries. > > Yea, I didn't actually know that dynamic linking is the standard these days > until today. It is amazing how complex dependency trees can be treated with > ease using dynamic linking. I compiled a very simple program that uses > FreeType today and tried to link everything statically. It's really painful. I > had to seek out `.a' files of the dependencies of FreeType and then those of > their dependencies. With something as less-dependent as FreeType, the process > was hard, I can imagine how terribly hard it would be for more complex things. > The size is another issue it solves. Am I correct? You're describing two main benefits of dynamic linking and why it so popular. As far as I'm concerned, static linking is rather used for edge cases like static code analysis or when you can't be certain that a required library exists on a system when want to run your program. >> From a library user's perspective, all you (usually) do (on Linux) is [...] > > Thank you for writing a very clear explanation. I have been on Linux for some > time and have been doing a lot of building from source so have learned these > things over time. Your explanation really allowed me to confirm my concepts > and verify them as correct, so thank you very much. :) That's great to hear, no worries at all :) Also sorry, haven't had the chance yet: congratulations and welcome to FreeType :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Supporting OT-SVG out of the box
works the same :) Hope I could help at least a bit. If not, let me know, I'll be sitting in front of my computer for a few more hours today. Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSOC -Project Availability
> A random thought on testing FreeType: I recently read about a small testing > library for C code, here: > https://www.bassi.io/articles/2019/03/14/a-little-testing/. > Might be interesting. Another option could be using the freetype-py wrapper > and test with that (pytest is nice). One thing that would be welcome is a > continuous integration ready approach, meaning that every commit would trigger > test runs under different operating system images and compilers. This could > help with uncovering differences due to compilers. Wait Nikolaus, not so fast :D The project described by Sadeep was the rendering test framework. I don't think it's super possible to have a (reasonable) CI-ready test suite in 3 months (due to many, many reasons). As far as I see it (also Kushal's approach), you have to go for qualitative testing not for quantitative testing there. Something along the lines of outputting `the old' result (with a reference version of FreeType) and `the new' result (with the version under test) and have a way of sorting through differences efficiently for human users (devs) with most important ones on top. Like some senseful ranking of differences by some value, detecting "simple" shifts etc + having a good (clean) UI to inspect the diff (highlighting of differences one way or another). The main problem (afaik) is that tiny differences can always occur and sometimes they're known and benign due to some change within some module. But other times you have small changes between version that actually hint at grave issues; finding a reasonable ranking algorithm seems difficult enough but finding one that is completely automatable within CI might not be possible easily. That was at least the idea behind that project last year -- not saying that's the only way of approaching it :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSOC -Project Availability
> Hello everyone, Hi Sadeep > I looked into the (apparently) the same project which was done by Kushal in > GSOC 2017. I want to know what are the limitations in his implementation. Having applied for the same project last year (however I got selected for a different project), Kushal's approach seems somewhat unfinished and somewhat difficult to (re)use due to extensive scripting (apart from other things). I suggest try to understand what FreeType really does (and what it does not) first. Based on that insight, try to find an approach that makes sense for FreeType and its developers (!). It must be super easy to use (next to no manual needed while still being flexible to set up), and produces maximum useful output. Basically thinking about the whole thing from the perspective of the FreeType's developers (almost no one works full time on FreeType!) who don't want to have to _learn_ how the framework works :) > Also does this project have a confirmed student? Afaik such things do not exist here. > Has anyone applied for this? I don't know but feel free to apply either way and convince Werner -- the best students/proposals will be chosen :) (And no, I could not apply this year ;)) > If so is there any other project in FreeType that I can apply to? https://www.freetype.org/gsoc.html > I am willing to do some implementation before the application period is over > (<48hrs) as a proof of concept. Go ahead but I think a clever (well thought-through) design (may it be words or pictures) are probably more convincing than a (small) working prototype. GSoC is generally the time for implementing chosen ideas. Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Old URLs breaking with the Update
>>> It was a deliberate change, but hmm. Nikhil, do you have a >>> suggestion? >>> >> >> Well, a simple fix would be to move all files from >> `docs/reference/site' to `docs/reference'. > > Done, together with updating all links. Please check. Wonderful, everything works perfectly fine again, as far as I can see :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Old URLs breaking with the Update
>> The latest update (to the new, superhot docs :D) breaks all old URLs >> (Google as well as my personal bookmarks) due to an additional `site/' >> in them. >> >> Old: >> https://www.freetype.org/freetype2/docs/reference/ft2-error_code_value >> s.html >> New: >> https://www.freetype.org/freetype2/docs/reference/site/ft2-error_code_ >> values >> .html >> >> Please ignore this if the changes were deliberately. > > It was a deliberate change, but hmm. Nikhil, do you have a suggestion? If things are too complicated for what it's worth, we could put a simple 301 forwarding from `non-site' to `site' into an `.htaccess' file somewhere in that tree (granted that `.htaccess' is not in any way blocked by the hosting server). I could provide that file, if needed :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Old URLs breaking with the Update
The latest update (to the new, superhot docs :D) breaks all old URLs (Google as well as my personal bookmarks) due to an additional `site/' in them. Old: https://www.freetype.org/freetype2/docs/reference/ft2-error_code_values.html New: https://www.freetype.org/freetype2/docs/reference/site/ft2-error_code_values .html Please ignore this if the changes were deliberately. Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Want to work on a project to add support for the 'SVG ' OpenType table to render color fonts.
Hi Alekh, > I had also discussed about *librsvg* by GNOME as potential library that can > fit the job.Although as told by Werner Sir it is porting to rust but still its > API is in C. `librsvg-2' looks fine to me: it is widely supported (on Linux at least), developed by a trustworthy team, and proven to be stable + fast. Rust as source language doesn't put me off (for all I care it can be JavaScript as long as it works :P); `librsvg-2' would solely be used as a prebuilt library (like `libpng' is being used already). > Whether to edit both Glyph positioning(otvgpos.c) and substitution tables > (otvgsub.c) or only positioning,I want to know about this. I am not sure about that, Werner might have an answer for you there :) > And rather than creating a new module editing API stuff by defining function > to transfer data from font table to the external library and bitmap output > back to Freetype can prove to work. There is enough time to discuss both approaches within GSoC but since you're bringing it up: what's keeping you off the module approach? To me, a proxy/wrapper seems a lot cleaner and reusable. > Sir, please suggest me how can i test Freetype 2 to analyse the changes.And I > will welcome any other suggestions. I am sure you have cloned and built FreeType from http://git.savannah.gnu.org/cgit/freetype/freetype2.git/ by now. For quick first tests, I would take a random SVG font, and follow the online tutorial (https://www.freetype.org/freetype2/docs/tutorial/index.html) to try to load it (use `dlopen' with _your_ compiled version of FreeType). As soon as you have managed to load the SVG file (with _your_ build), start making changes to FreeType itself, recompile it, and see how things change :) Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSOC 2019
> Hello Shibajyoti! Hi Shibajyoti :) Sorry for being somewhat late to this discussion, >> My name is Shibajyoti Debbarma, Pre-Final Year Engineering Student >> from India, looking forward to contribute to the Freetype Project >> "Replace FreeType's tracing and debugging facilities with an external >> logging library". I have proficiency in C and C++ languages so can >> anybody kindly guide me how to get started and any suggestions for me. > > Please go back to FreeType's GSoC page at > > https://www.freetype.org/gsoc.html > > and read the paragraph at the top printed in red. > > I urge you to also read the GSoC student guide > > https://google.github.io/gsocguides/student/ just a quick additional hint: there has also been a lengthy discussion in the devel mailing list two or three weeks ago that addressed quite a few details about the community aspect of the new logging/tracing framework. That discussion ultimately led to updating https://www.freetype.org/gsoc.html. You definitely want to check out that as well :) Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] fuzz timeouts
>> > We have 73 timeouts and counting: >> > https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1=Timeout+pro >> > j%3Dfreetype2 > >> This solution would (maybe) remove most timeout reports immediately but it > would also silently hide unreached parts of those fuzz targets. > > The blanket approach to loading flags is extremely wasteful. The fuzzing > without FT_LOAD_RENDER would be so much faster. All targets without `-render' in their names follow that path very successfully. > The only productive way to fuzz the rendering is your glyphs-outlines, on the > other hand. The question is, if any of the `-render' targets help the other targets (`glyphs-outlines' as well as non-`render' targets) with code coverage, which they did back in October. This could be re-evaluated of course. However, I rather have overlaps than gaps, esp. if it is _free_ (for FreeType at least :P). > Why is this not a solution? Are you talking about a hard cap on totally (cumulatively) rendered pixels per target (e.g. for `glyphs-outlines')? If so, imagine the target (any target) has a multiple subtasks (render modes + sizes) that it executes, one subtask after another. If we introduce a hard cap, that target would categorically execute earlier subtasks more often than later subtasks without any feedback (no one would know). Obviously, that's a very bad thing as "luck" decides which tasks are done more regularly than others. The better solution is to understand which of the tasks actually take up too much time and put those tasks into separate targets (or limit those _specific_ tasks in other ways). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] fuzz timeouts
> Armin, Hi Alexei :) > We have 73 timeouts and counting: > https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1=Timeout+proj%3Dfreetype2 > > The best solution is to limit the cumulative total to 1 Gb of rendered > bitmaps. Is this hard to implement? This solution would (maybe) remove most timeout reports immediately but it would also silently hide unreached parts of those fuzz targets. I really, really, really want to avoid that. The best solution (IMO) is to take the time and trace lengthy calculations within the targets and make sure that those calculations are kept to a minimum (either by splitting targets or capping certain actions). There has been some progress with that (e.g. capping the maximum glyph render size) and the results are generally promising. It's just not finished yet which is why those timeout reports still exist. Personally, I would treat those reports as temporary, implicit "Won't fix" until I (or someone else) have enough time to carefully examine those timeouts on a per-target level. (I will gladly do that btw, it's only a matter of having enough time at some point ...). At the moment, OSS-Fuzz shows only one of those timeout reports per target until that report gets made public. Only then, a new timeout report for the same target will show up. I think that's not too much noise, compared to the alternative of silently missing parts of fuzz targets. Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Logging library proposal
> There's a simple rule: don't try to fix something that is not broken. I 100% agree. However, as Werner and I have pointed out earlier, there are a few issues with the current implementation of the logger. At least, there are things that could clearly be improved. > Another consideration would be to leave the decision to people who actually > works with Freetype code, and who is used to work with existing code base. My word might not mean that much to you as I'm not actively developing FT features but I'm rather on bug hunting missions (and only joined recently). However, also Werner addressed different issues. When it comes to choosing a logger, this will (of course) not be done blindly and/or "behind the scenes". As you can imagine, the hardest part will be to convince Werner of accepting the new thing ;) Apart from that I can only imagine that it will be addressed in the mailing list as well so everyone is free to offer their thoughts. > Also, obviously there is no point in inventing new dependencies for such a > simple thing as logging. This is probably where I disagree the most. Logging/tracing in itself is far more than "a simply thing"; it is a tremendous debugging tool (when done right). Instructions that are (1) dead easy to insert and (2) generate output that is spot-on for whatever you're looking for in any specific situation can make the difference between firing up `gdb' or finding an issue within a few seconds. The current logger is great, but there are far better solutions out there. > IMHO if something is going to be changed or improved this shouldn't be an > external library, I will leave it at that ... > and new things should be left compatible with existing ways of usage. ... and I strongly agree with that! That should totally be worked into a the possible overhaul! Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Logging library proposal
>> Well, as far as I can see, it's exactly as Armin described the >> situation: people insert `printf' statements for debugging. And the >> final code usually missed important debugging calls... > > How does that justify adding new logging library or changing the current > logger code? That sounds more like current tracing statements should be > improved. May I ask you, Dmitry, what are your concerns with introducing an external logger? Obviously, the goal is to improve the overall situation for everyone or (at least) keep things equally fine as they are at the moment. Following our discussion here, it seems to me as if changes would affect you negatively which should (obviously) be avoided. Necessity aside (who cares if it's necessary if someone else does it (properly) and it has no negative effect on anyone), what are negative consequences for you personally or for FreeType in general and how can they be avoided/tackled/justified/eased? @Yash: sorry for spamming your thread, but it seems as if you question has sparked some conversation here :P ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Logging library proposal
>> Of course. Only if some preprocessor macros are defined at configure >> time, this feature is available – I won't change that. In other >> words, it will stay as a developer-only feature. > > Right. Which makes using en external library overkill. Not really, you want your logger to be as top-notch as the rest of your program (spec. fast + as helpful as possible). In-house logging is fun but like with everything else: if there are people who specialise on something, why not taking advantage of that? Improving the logger over the years is not really a strong focus of developers who want to contribute to _FreeType_ (as I understand). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Logging library proposal
> That's all I can think about it for the moment ... if I come across something > else I will add it to the thread. To keep this memo board somewhat complete: a key aspect of the logger should also be the ease of "extegration"; meaning the logger has to be compiled out completely by default (not leaving _any_ traces) -- (1) obvs. for performance reasons but (2) also for all the projects that use FreeType as a library (like we would use the logger). Since we're in `C'-land this is typically done using some sort of preprocessing magic but some loggers might be easier to extegrate than others. @Werner: I just checked https://www.freetype.org/gsoc.html and, if you like, I can try to briefly (!) summarise more details to make it easier to understand the challenges (and possible approach) when choosing this project? Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Logging library proposal
Hehe I was just preparing a detailed answer myself to bridge the gap until you have time to answer ... but you beat me ;) Also: hi Yash, welcome to FreeType :) >>> Anyways, a simple solution to an inaccessible stderr is to print log >>> messages directly into a file. Our code will work independently of >>> whether stderr is accessible or not. > > Yes. Seems sensible. >> Can you elaborate on what are your exact targets in this project? >> Does the project only aim for "platforms with inaccessible stderr"? >> Can you explain me some difficulties we may face? If you feel zlog >> is suitable for this project, I want to start contributing to >> freetype in gsoc as well. Do you plan to contribute as part of GSoC or outside of it? For GSoC you can expect reasonable mentoring to ease you into working with/on FreeType but outside of that you're a bit more on your own due to lack of personnel ;) Please mind that participating GSoC organisations are only revealed later in February and, while unlikely, there is a chance that FreeType will not be chosen to take part this year. > The target is to improve and streamline FreeType's debugging capabilities. > Please have a look at file > > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/DEBUG > > to see how debugging works. > > Armin, can you chime in? You probably know better than me what could be > improved. And would you be willing to act as a mentor for this GSoC project? Exactly, the main idea is to get rid of the current logging system and completely replace it with a state-of-the-art logger that is being developed "out of house". The idea is to simply "use" that logger and not to care about developing/debugging/adjusting/fixing it. I think it all starts with carefully evaluating the current logger (it's definitely not to be underestimated; it has quite a few nifty features!) and make sure that everything stays possible one way or another _OR_ have good reasons for dropping/replacing features. It's not just about adding a nice logger but about finding something that convinces Werner to drop his own brainchild and switch over to the new one ;) That being said, a big downside of the current logger (in my opinion, Werner will disagree probably) is it's lack of "ease of use". I, personally, think a logging library has to be able to get you started with reading less than 3 sentences about it (looking at it from both sides: the person who puts the logger into some piece of source code as well as the person who's trying to retrieve messages of a specific level/domain -- that second part is specifically difficult with the current system IMO). As I see it, part of the project should also involve writing a short but exhaustive documentation about how the logger should be used in the context of FreeType (just setting up a few basic guidelines to have everyone on the same page). As for the logger itself it should be tried and tested across all thinkable (reasonable) platforms that FreeType supports (that should not be underestimated). Also it should be supported by a community that can be trusted with developing it for a foreseeable future as we don't really want to replace the logger on a yearly basis ;) That's all I can think about it for the moment ... if I come across something else I will add it to the thread. @Werner: I would be happy to help out as much as I can, I just don't know any details about my Summer yet. Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Logging library proposal
> Please don't use an external library. Logging in FreeType is for developers > only, and some parts maybe for font designers. Clients who just want to > render text don't need the logging capabilities. Just keep it simple. Obviously a logging library has to be completely compiled out by default and should not interfere with other projects that use FreeType as a library only (unless they want to run some tracing but that should not be the case usually?). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [SPAM] Re: color framework
>>> Let's see whether someone is interested in this. What about making >>> >>> Add SVG support >>> >>> a GSoC project? :-) >> >> Ooohhh that's an extremely interesting and tempting thing; I wish I >> could participate again (or had more time in general) :D > > The former is possible AFAIK, I think you can only participate twice in total? Also, if everything goes well, I should be done with university in February ^^ > the latter is your very own problem :-) True, true ... > In general, the idea is as follows. > > * Evaluate the freely available SVG libraries which would fit the > job best. > * Define FreeType API functions and hooks for transferring data from > the font's `SVG' table to the external library. > * Ditto for transferring the resulting (bitmap) output back into > FreeType. I am surprised that the API currently doesn't have anything like that; isn't there support for external rendering already? > Anything else? Sounds good to me. Should be a lot of fun to do :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
> Let's see whether someone is interested in this. What about making > > Add SVG support > > a GSoC project? :-) Ooohhh that's an extremely interesting and tempting thing; I wish I could participate again (or had more time in general) :D ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Question
> Łukasz, > > >> How can I write text directly on a painted bitmap? I am sending you >> my source code. > > we don't have time to look at arbitrary code. if you want us to help you we > need a command line program that can be easily compiled, a so-called `minimal > working example', MWE. It should produce something, and you should explain > what you get and what you expect instead. Add: there are some fine tutorials online (https://www.freetype.org/freetype2/docs/tutorial/index.html) -- they might even answer some questions you have about workflows that include FreeType and/or explain the general scope of FreeType. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ccache support for `freetype-testing'
Werner asked me about this a few days ago and since there are a few people using this repo I thought it is worth mentioning it in the ft-devel list: I just added `ccache' support to `freetype-testing' (https://github.com/freetype/freetype2-testing). It can be turned off (default is "on" though) and the option should only appear if `ccache' can be located on the target system. I ran a couple of tests on different machines and different setups but obvs. I cannot test EVERYthing so please let me know if you run into any weird caching issues (spec. when recompiling the thing over-and-over again with different settings) :) Apart from that, have a great Sunday :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype fails to build
> El divendres, 31 d’agost de 2018, a les 22:39:44 CEST, Albert Astals Cid va > escriure: >> /src/freetype2/src/base/ftobjs.c:365:7: error: non-void function >> 'ft_glyphslot_preset_bitmap' should return a value [-Wreturn-type] >> return; > > I guess it's my fault for compiling with -Werror, I can see no fault there ;) > but i guess it's still a > warning that makes sense to fix. Absolutely, I'm sure Alexei is already on it, there was just some discussion going on around this very issue in another thread: https://lists.gnu.org/archive/html/freetype-devel/2018-08/msg00119.html Best Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] `ft_glyphslot_preset_bitmap' breaks the build atm
In file included from /home/cherusker/FreeType/cherusker-freetype2-testing/external/freetype2/src/ base/ftbase.c:32: /home/cherusker/FreeType/cherusker-freetype2-testing/external/freetype2/src/ base/ftobjs.c:365:7: error: non-void function 'ft_glyphslot_preset_bitmap' should return a value [-Wreturn-type] return; ^ Introduced in `1dacbd893d3c2f027b5c79f504d8899a68112c0c'. I assume, it should be `return 0'? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Error Description Strings
>> Cross referencing the other thread: should I change 'error_string' >> to `error_string`? > > For consistency with the rest of the API documentation: Please no. Applied, woohoo :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Documentation guidelines file
> Seriously: We talk about formatted plain text documents with prose (more or > less) and thus to be viewed with a typewriter font. Much longer line lengths > for such documents are a bad idea; it's no longer convenient to read – the eye > can easily lose the current line. I totally see where you are coming from and it totally makes sense (there are lots of rules like these to keep text manageable for readers (lines should neither be too narrow lines nor too wide, also rules about vertical flow, etc) and there is also some belief when it comes to that topic. I, personally, would not restrict writers too much (ultimately not my decision with FT, for good reason! just trying to explain my point of view): If you take https://raw.githubusercontent.com/freetype/freetype2-testing/master/fuzzing/README.md as an example (I know it's markup, but still), "hard 72" (or 78 for that matter) has/would have several impacts: (1) Well formatted tables can still be read easily, even if 72 (78) total width is exceeded (as long as the cells themselves are well formatted). (2) Deeper nested lists can suffer from rigorous restrictions like these as every indentation cuts off a piece of the cake. Maybe something like "lines of straight text should not exceed X but the total width of a line of code should stay within Y" (e.g. X = 78, Y = 120 (which is still too narrow for the shown tables in my example but would probably work for most cases)) Just a thought, feel free to ignore it ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Error Description Strings
>> Please find pitch #2 attached. > > Excellent, thanks! Attached is my version with slight whitespace fixes; > please apply (together with a proper ChangeLog entry). Wonderful, thanks, will do :) Cross referencing the other thread: should I change 'error_string' to `error_string`? > Ah, and `fterrors.c' should be added to the `_sources' string in > `src/base/Jamfile' also. Will do, sorry, I missed that! ... note to myself: we should setup a Travis build row that uses Jam. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Documentation guidelines file
> Ah, this is due to my formatting using Emacs, which has a default line width > of 72 chars. For the sake of consistency the style guide should rather > mention to use 78 chars. On the other hand, a well-formatted document with a > shorter line length doesn't hurt... Nooo :// Please, ... 78 is already ... sooo ... short ... ^^ ... We should instead rather start a fundraiser to collect money for a bigger screen for Werner :D ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Error Description Strings
Please find pitch #2 attached. > We now use our special Markdown flavour for documentation (in particular no > longer `xxx' but either `xxx` or 'xxx', depending on the intended use); please > update your patch accordingly. Oh right, sorry I forgot that, changed now (if I understand the new system correctly). > Maybe the debugging output can be made a bit more compact? Done :) In addition, I removed `FT_UNUSED( ... );' since this is not true any longer. fterrors.02.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Documentation guidelines file
> I've attached the `docs/DOCUMENTATION' file (from the draft work at > https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project). > This should cover everything needed to understand the basics and the > markdown formatting of the docs. Thanks, very informative! :) The only thing missing (if I haven't missed it) is the fact that apostrophes are used to refer to other parameters of the same function ... eg: ``` /** ... * ... * @description: * Uses 'a' to meep 'b'. * ... */ FT_EXPORT( void ) FT_Meep ( A a, B b ); ``` > A few things, such as preference of uppercasing may be added to this > From a previous thread: > >> * Shall we mention that we prefer two spaces after a full stop ending > a sentence? Please do, esp. for people who're new to FreeType; I plan to add a whole code style guide, once the new website is online :) Generally (not always, but very often true): the more information the better, esp. when well organised :) >> Ditto for details on uppercasing in section titles (US >> style, for example `This and That'), how to cite a C function >> (without trailing parentheses), etc., etc. Ditto, please do, for the sake of everyone who's new to contributing to FT :) > Also, I'm not sure about the `forced' line filling to column 71 as seen > in other files in the `docs' directory. I don't exactly know what you mean but I'm sure this one is targeted towards Werner, who will know :D ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
> Werner, Armin, Alexei, > Here is all the confusing parts about FT_Get_Glyph: > - It takes ownership on the bitmap without copying the data. Thus, it should > not be called twice on the same GlyphSlot and should fail if > FT_GLYPH_OWN_BITMAP is not set. The current behavior with deep copy when > FT_GLYPH_OWN_BITMAP is not set is a bug that need to be fixed. > - It copies the outline data without modifying original ownership. So it is > the opposite of bitmap glyphs. To add to the confusion FT_OUTLINE_OWNER is in > a different place. > I think we should stick to the lazy copy in both cases because it is usually > used once. The deep copy is a waste because FT_GlyphSlot is usually discarded. > I do not think the deep copy is useful. What is the usual use case and why are there two (very) different glyph containers in first place (`FT_Glyph' and `FT_GlyphSlot')? I would expect that `FT_GlyphSlot' is a wrapper around `FT_Glyph' to add more information that is e.g. needed for rendering etc. But it turns out that they are two rather distinct things. I totally agree with whatever the two of you cook up; just trying to shed some light from a user's perspective who tries to work with FreeType only (!) reading the API docs (not trying to understand any of the black magic that goes on in the depths of FT): The docs surrounding `FT_Get_Glyph' really make it look like I get an independent `FT_Glyph' that can be used whatever. I would definitely add several warning signs to the docs. Also, can FreeType become the owner of that generated `FT_Glyph'? That way the confusion with `FT_Done_Glyph' would vanish & it would be clearer that I will always get the same (maybe, but who cares?) object from calling `FT_Get_Glyph' -- changes that I make to that object might get propageted into `FT_GlyphSlot' (also something that should be put into the docs explicitly IMO). Reflecting on it, I do really believe that the call to `FT_Done_Glyph' is the source of much confusion (at least for me). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
>>>> Please keep FT_Get_Glyph light. >>> >>> Why? >> >> Because it is meant to be used once followed by as many FT_Glyph_Copy >> as you want. > > OK. Armin, can you change your usage pattern to something like the following? > > FT_Load_Glyph( face, 0, 0 ); > FT_Get_Glyph( face->glyph, ); > > FT_Glyph_Copy( reference, ); > ... > FT_Done_Glyph( glyph1 ); > > FT_Glyph_Copy( reference, ); > ... > FT_Done_Glyph( glyph2 ); > > FT_Done_Glyph( reference ); > > Together with an update of the documentation this doesn't look too bad IMHO. Mhm; I mean I get it -- changing to deep copy here would also introduce semantic changes which is never anything you really want in an API. Just another proposal (feel free to decline!): how about coming back to (3) and introduce something like `FT_Get_Glyph_Deep'? Internally, the same logic could be used; I would simply add a switch (bool var) that gets propagated down to `ft_bitmap_glyph_init' to skip the lazy copy? I could even prepare the patch if you like, no work for anyone ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
> Yeah. Another proposal. > > (3) Make `FT_Get_Glyph' always do a deep copy. Add new function > `FT_Get_Glyph_Lazy' to do a lazy copy if it holds a bitmap object. I would like that very much :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
> If I'm not mistaken, `FT_Glyph_Done' is still problematic in that case: [...] Please ignore that, got the other message too late :D ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
>> Sure, no worries; you can find a tiny C function + build script >> attached. Please make sure to build FreeType with `clang' and >> `-fsanitize=address' for it to work :) > > Thanks. I see two possibilities to fix the bug. > > (1) Avoid lazy copying in `FT_Get_Glyph'. How frequently is `FT_Get_Glyph' used and in which context? > (2) Update the documentation: > > By default, `FT_Get_Glyph' can be used only once.[*] If you want > more copies, use either `FT_Copy_Glyph' or call > `FT_GlyphSlot_Own_Bitmap' before calling `FT_Get_Glyph' again. If I'm not mistaken, `FT_Glyph_Done' is still problematic in that case: (1) if `FT_Glyph_Done' is NOT called, we (might?) end up with mem leaks, but (2) IF it is called, the bitmap in the face's glyph slot gets erased (something that is not expected IMO) and the whole loaded glyph cannot be used anymore. > What do you prefer? This question is not targeted towards me (I think) but if the overhead of properly copying the bitmaps is OK with `FT_Get_Glyph's current use cases (do we have any statistics on API usage?), I would lobby for that outcome. Esp. since `FT_Get_Glyph' has the potential of being something really powerful ... however, the lazy copy makes it unintuitively and complicated to use (beware: opinion!) ... then again, I currently use the API in somewhat unconventional ways, other people might have other preferences there. >> I think the else (proper copy) condition is bogus. If bitmap is not >> owned, it is not valid and you cannot copy it, which leaves us with >> lazy case only. > > Yep. This must be fixed. > > [*] This statement is valid only for FT_GLYPH_FORMAT_BITMAP objects. > For FT_GLYPH_FORMAT_OUTLINE objects, FreeType always creates a > copy. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
>>> Looks like a bug. Please provide a simple compilable example that I >>> can use for debugging. >> >> Sorry, sure, I forgot! You could use `2018-08-20-bitmaps' on my >> private fork like: >> >> $ git clone https://github.com/cherusker/freetype2-testing.git >> cherusker-freetype2-testing >> $ cd cherusker-freetype2-testing >> $ git checkout 2018-08-20-bitmaps >> $ cd fuzzing/scripts >> $ ./custom-script.sh >> ... ... > > Following this recipe (using git 3763871e) it fails [...] Mhm ... strange, but I can see the same fail with Travis as well; no worries, won't be delivered that way ;) >> Is that OK, or should I extract a teeny-tiny sample with just the 4 to >> 5 necessary API calls? > > The latter would be really nice, especially if written in C. Sure, no worries; you can find a tiny C function + build script attached. Please make sure to build FreeType with `clang' and `-fsanitize=address' for it to work :) <> ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
>> I'm still working on the bitmaps and just ran into an interesting >> access violation that happens with using the API exactly (?) as it is >> intended to: >> >> FT_Load_Glyph( face, index, load_flags ); >> >> FT_Get_Glyph( face->glyph, ); >> FT_Done_Glyph( glyph ); >> >> FT_Get_Glyph( face->glyph, ); // fails with an >>// access violation > > Looks like a bug. Please provide a simple compilable example that I can use > for debugging. Sorry, sure, I forgot! You could use `2018-08-20-bitmaps' on my private fork like: $ git clone https://github.com/cherusker/freetype2-testing.git cherusker-freetype2-testing $ cd cherusker-freetype2-testing $ git checkout 2018-08-20-bitmaps $ cd fuzzing/scripts $ ./custom-script.sh ... ... $ ../build/bin/driver --glyphs-bitmaps-pcf ../corpora/glyphs-bitmaps-pcf/bungeman/HangingS-16lL.pcf ... ... Is that OK, or should I extract a teeny-tiny sample with just the 4 to 5 necessary API calls? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
>> FT_Get_Glyph( face->glyph, ); // lazy copy in >> `ft_bitmap_glyph_init' > > I think the else (proper copy) condition is bogus. If bitmap is not owned, it > is not valid and you cannot copy it, which leaves us with lazy case only. > Elsewhere, we do not even free the bitmap buffer in the FT_GlyphSlot if it is > not owned. Personally, I think the "else" is the only "proper" way to proceed in that situation (even though it is way more expensive): the glyph that is being allocated in `FT_Get_Glyph' is basically a deep copy of whatever resides in the face's glyph slot (at least that's the way it is advertised). Apart from my expectations (1), I also have to free the glyph that `FT_Get_Glyph' crafts (according to docs) and that flushes the bitmap buffer of said glyph (which causes the issues in first place). (1) I expect to be able to use the returned glyph however I like. Knowing it won't affect the glyphslot in the face ... that way I can do fancy things to it without the need to reload the glyph in the face -- which renders `FT_Get_Glyph' pretty much useless. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Bitmap_Convert: source == target >> boooom?
>>> I wondered if I can feed it the same bitmap twice. >> >> The cost-benefit analysis is in order. Is it worth checking a great >> number of valid uses to capture the invalid one? [...] > > I've now slightly improved the documentation. Please check whether it is more > clear. As clear as day now, thank you sir :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Bitmap_Convert: source == target >> boooom?
>> > Only so much you can do to protect against it. You only capture one >> particular >> > case. >> >> I wondered if I can feed it the same bitmap twice. > > The cost-benefit analysis is in order. Is it worth checking a great number of > valid uses to capture the invalid one? Sure, I totally get that and the check was just in addition; my main question was if that information should find its way into the docs to clear out any issues upfront ... design by contract + such. > Whether your program crashes or gives an error, you have to fix the bug in > your program (unless there is a security implication, which changes the cost > balance). Sure, totally agreed. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] PCF: Issues with lazy copy in `ft_bitmap_glyph_init'
I'm still working on the bitmaps and just ran into an interesting access violation that happens with using the API exactly (?) as it is intended to: ``` FT_Load_Glyph( face, index, load_flags ); // no load flags (0x0), PCF driver FT_Get_Glyph( face->glyph, ); // lazy copy in `ft_bitmap_glyph_init' FT_Done_Glyph( glyph ); // frees the bitmap in the face's // GlyphSlot (due to the lazy copy) FT_Get_Glyph( face->glyph, ); // proper copy in // `ft_bitmap_glyph_init' and // `FT_Bitmap_Copy' fails with an // access violation ''' I am not quite sure how to fix/tackle the issue and what the exact purpose of fastpath is but in that case it seems somewhat overly fast (unless I misunderstand the API usage) :) Only tested with the PCF driver but the issue might be similar with other drivers. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Bitmap_Convert: source == target >> boooom?
>> I assume that `source != target' is true for `FT_Bitmap_Convert' (esp. >> since there is some reallocating going on). I suggest putting a quick >> note into the docs to clarify that and probably extend the entry check: > > I can explode fscanf too with invalid pointers. True, however, the documentation of `fscanf' is pretty intense and seems to cover pretty much everything there is to know about it -- if you read it, you don't have to check the implementation to figure out what to do with it and what to avoid. > Only so much you can do to protect against it. You only capture one particular > case. True as well, it's the case I just encountered when I wondered if I can feed it the same bitmap twice (would generally be a legit use-case IMO). Simply wanted to share my thoughts (pretty much as "your regular API user" at this point) with you :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_Bitmap_Convert: source == target >> boooom?
I assume that `source != target' is true for `FT_Bitmap_Convert' (esp. since there is some reallocating going on). I suggest putting a quick note into the docs to clarify that and probably extend the entry check: ``` diff --git a/src/base/ftbitmap.c b/src/base/ftbitmap.c index c04eec43..6037538d 100644 --- a/src/base/ftbitmap.c +++ b/src/base/ftbitmap.c @@ -528,7 +528,7 @@ if ( !library ) return FT_THROW( Invalid_Library_Handle ); -if ( !source || !target ) +if ( !source || !target || source == target ) return FT_THROW( Invalid_Argument ); memory = library->memory; ''' Further, I believe that similar rules apply to `FT_Bitmap_Blend'. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Love the new docs!
A quick word of appreciation: using Nikhil's preview for browsing the docs since yesterday and man that's fast + convenient! No need for Google or browser bookmarks or Ctrl+F or tabbing or ... very well done, I love it! :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Error Description Strings
https://stackoverflow.com/questions/31161284/how-can-i-get-the-corre sponding-error-string-from-an-ft-error-code is the best solution >>> >>> It is, but the code formatting in the link is extremely ugly and thus >>> hard to read and understand. >> >> What don't you like about the formatting? > > Indented cpp lines! AFAIK, the `#' should always be on the first line. I > also don't like that the cpp statements are put into the array, making it more > difficult to grasp what's going on. Agreed with `#'. However, I am not sure if I completely understand the other thing: do you prefer the solution by `N. Yoda' on StackOverflow (1) or the solution presented in `fterrors.h' (2)? (the latter uses the array, the former uses a switch/case) 1. Switch/case is somewhat slower than array accesses but, IMO, the code is better to read (although I would exchange the lines with `FT_ERROR_START_LIST' and `FT_ERRORDEF' for improved readability) and it results in less code in total. Also no global variables. 2. Faster execution but IMO results in somewhat messier code. Also global variables. Efficiency is generally nice, however somewhat neglectable when it comes to debugging and really, it shouldn't be THAT much of a difference. Beauty lies in the eye of the beholder and I'll willingly agree to whatever you prefer. and/or if I (or someone else) should add a function like `strerror' to FreeType's API? >>> >>> Not necessary, I believe. >> >> Am I the first (or third) person to request/use that? > > IIRC, yes. That's interesting; I use `strerror' (and equivalent functions/methods in other libs and languages) sooo much :D >> I believe such a function (that minimises boilerplate on FreeType's >> users' end) would be nice when using FreeType in combination with >> loggers since strings are definitely easier to review/debug for humans >> than numbers. How about a default-no-but-optional-yes-macro in >> `ftoption.h'? > > I don't object. Thank you :) > Do you want to provide a patch? I do! :) Just finishing fuzzing the bitmap handling API first, but right after that! :) > I can imagine to activate that automatically if tracing is active, doing a > call within the `FT_THROW' macro. Totally, why not :) However, for my (fuzzing) purposes, I'd appreciate it if `FT_Get_Error_Message' was independent of tracing since I usually don't use FreeType's tracing but do log all return values (esp. `if ( error != 0 ) ...'). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Error Description Strings
>> I wonder what's the best solution to get FreeType's error strings from >> its error numbers? E.g. "cannot open resource" from `FT_THROW( >> Cannot_Open_Resource )'. Since I cannot locate anything in the docs > > This must be an oversight on your side, since FreeType comes with a complete > chapter for that: > > https://www.freetype.org/freetype2/docs/reference/ft2-error_enumerations.htm l Sure, sorry, forgot to mention this b/c it uses that idea anyways but wraps it up somewhat nicer (as I think) since it does not need to store anything in variables. >> I wonder if >> >> https://stackoverflow.com/questions/31161284/how-can-i-get-the-corresp >> onding-error-string-from-an-ft-error-code >> >> is the best solution > > It is, but the code formatting in the link is extremely ugly and thus hard to > read and understand. What don't you like about the formatting? >> (seems quite hacky :P) > > I don't think so. It definitely makes the FreeType library itself smaller > since there is no need to store the error strings... > >> and/or if I (or someone else) should add a function like `strerror' >> to FreeType's API? > > Not necessary, I believe. Am I the first (or third) person to request/use that? I believe such a function (that minimises boilerplate on FreeType's users' end) would be nice when using FreeType in combination with loggers since strings are definitely easier to review/debug for humans than numbers. How about a default-no-but-optional-yes-macro in `ftoption.h'? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Error Description Strings
I wonder what's the best solution to get FreeType's error strings from its error numbers? E.g. "cannot open resource" from `FT_THROW( Cannot_Open_Resource )'. Since I cannot locate anything in the docs I wonder if https://stackoverflow.com/questions/31161284/how-can-i-get-the-corresponding -error-string-from-an-ft-error-code is the best solution (seems quite hacky :P) and/or if I (or someone else) should add a function like `strerror' to FreeType's API? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Tiny Docs Patch
I suggest this tiny patch in the documentation of the driver properties:
```
diff --git a/include/freetype/ftdriver.h b/include/freetype/ftdriver.h
index 2384dc61..c893c545 100644
--- a/include/freetype/ftdriver.h
+++ b/include/freetype/ftdriver.h
@@ -383,7 +383,7 @@ FT_BEGIN_HEADER
*
* {
* FT_Library library;
- * FT_UInt hinting_engine = FT_CFF_HINTING_ADOBE;
+ * FT_UInt hinting_engine = FT_HINTING_ADOBE;
*
*
* FT_Init_FreeType( );
'''
As stated above in line 348: `FT_CFF_HINTING_ADOBE' is deprecated.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Move `src/tools/ftfuzzer' to the testing repository
> [...] and don't break URLs in the ChangeLog. [...] Even if it breaks the rule of 78? ;P (anyways, sure + consider it done :)) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Move `src/tools/ftfuzzer' to the testing repository
As discussed earlier this week I would like to move the sources of the legacy fuzz target to the testing repository. I have already copied it to the new repository: https://github.com/freetype/freetype2-testing/tree/master/fuzzing/src/legacy . It would now be time to remove it from the freetype2 repo; please find the according patch attached. Is the Changelog message (in combination with the README.md at the new location) enough to explain the move or should I add more information? Thanks + hope you're all fine :) Armin 2018-07-20-remove-ftfuzzer-from-freetype2.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fuzzing for FreeType moved to FreeType's GitHub Account
Hi all, a quick update: I have just moved FreeType's testing repository to FreeType's GitHub account: https://github.com/freetype/freetype2-testing. If you have used `cherusker/freetype2-testing' before, I would kindly ask you to check out `freetype/freetype2-testing' in the future since its master branch will be noticeably more stable. I will use my own forked version of `freetype2-testing' to play around with experimental features; there will be a lot of rebasing and breaking going on ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [GSoC] Plans for the Finale of Fuzzing for FreeType
> Hi Armin, Hi pat, great to see you :D > My graduate student Zeming has been making good progress this term on TTF > bytecode analysis. So we don't have a corpus, but we can now easily manipulate > bytecode for existing fonts. If there's anything specific you have in mind, we > should figure out whether we can make that happen. Oh cool! Feel free to use any fonts that are suitable for you in https://github.com/cherusker/freetype2-testing/tree/master/fuzzing/corpora :) A quick wish list: - fonts that contain (small) glyph bitmaps (all drivers) - fonts with kerning information that can be accessed via FreeType (drivers: CFF, PFR, TrueType, Type 1) - fonts that contain multiple masters / font variations (drivers: CFF, TrueType, Type 1) - CID-keyed fonts (drivers: CID Type 1, CFF) - fonts that explore unicode variation sequences (https://www.freetype.org/freetype2/docs/reference/ft2-glyph_variants.html) (all drivers) All fonts should be really small: they should only contain a handful of glyphs (just enough to cover different/edgy aspects within a font). Small does not imply "simple" however: "complicated" fonts of any shape and form are welcome (many faces, many instances, combination of many aspects, ...). Furthermore, if possible, fonts should be licensed with the SIL Open Font License. These are really the most important aspects at the moment; thank you so much upfront for looking into this :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [GSoC] Plans for the Finale of Fuzzing for FreeType
Hello dear readers of this wonderful mailing list :) I want to give you a quick update on the fuzzing side of things: The targets are growing on a daily basis and will be integrated into OSS-Fuzz in a matter of hours, maximum a day or two :) They will not be complete by then (technically, they will never be complete) but they are in such a state that Kostya and I decided it's worth throwing them into the machinery and watch the outcome. Apart from that, I plan to achieve the following things during the 3rd (and final) stage of GSoC 2018 (I am so sad, I cannot believe it's more than 50% over already :/) (1) Further work on the API checklist (https://github.com/cherusker/freetype2-testing/blob/master/fuzzing/README.m d) and adding even more API functions to that list (esp. parts of the "Support API" that is not sufficiently being used indirectly). (2) Play with driver properties. (3) Build another set of fuzz targets for fuzzing glyph related stuff (stroking, rendering, ...) that happens independently of the driver-driven targets (that are the actual focus of my GSoC project). Some things from the driver-driven targets will then be moved to these glyph-driven targets. (4) Integrate some profiling to identify bottlenecks and maybe put scary bits into separate targets and/or isolate them otherwise (if necessary). So far, so good. I hope you're still with me, b/c I do also have a question for everyone in here: Does anyone know font geeks? === If possible, I would love to ditch the "old" corpus since its fonts are huge (they are proper fonts) and repetitive (not exactly the initial fuzz corpus of your dreams). While I do know more/less exactly what the perfect fuzzing fonts should look like, I would much rather spend my time improving and expanding the fuzz targets than creating those fonts. So, if there are any font enthusiasts listening (or if you know any people who would love doing that) please step forward; that would really be a great help :) Ben (bungeman) already did a great job in providing a base set of sample fonts that are optimised for fuzzing (small fonts, few glyphs, concentrating on a few, very distinctive features) but there could be a lot more (https://github.com/cherusker/freetype2-testing/tree/master/fuzzing/corpora/ truetype/bungeman etc.). For reference: I will also contact HarfBuzz and see if they have interesting stuff and IF they do, if they would share that with FreeType :) I hope everyone is doing great and to my GSoC co-workers: have a happy coding finale :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Done_MM_Var + FT_Library
> Note, however, that you can use > > face->glyph->library > > since FreeType always creates an `FT_GlyphSlot' object if the face index is > >= 0. In other words, it is not necessary to carry both `FT_Face' and > `FT_Library'. O, that is an amazing life hack, thanks! :D Couldn't find the library in `FT_FaceRec' directly and expected it to be in `FT_Face_Internal' which is why I stopped looking for it anywhere else. Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Done_MM_Var + FT_Library
Thanks for the explanation :) > the most natural choice was `FT_Library'. I see. Judging from an API user's perspective (and from a rather special angle, maybe not THE standard usage) I think I would've preferred to rather use an `FT_Face' as additional parameter instead of `FT_Library' since I need that `FT_Face' anyways to get `FT_MM_Var' from `FT_Get_MM_Var' in first place. Further, it would create some kind of parameter symmetry between getting + freeing `FT_MM_Var'. This is highly biased of course. Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_Done_MM_Var + FT_Library
Today I played with multiple masters and naturally I came across `FT_Done_MM_Var'. I wonder, why I have to set `FT_Library` explicitly to deallocate `FT_MM_Var'? On the surface, it would be convenient if `FT_MM_Var' could keep track of its library (or face) internally and `FT_Done_MM_Var' could extract that value automatically. This would (1) make working with C++ deleters more convenient and (2) I could avoid bubbling the `FT_Library' pointer through the whole program just to deallocate a specific gimmick of a specific face. Thought I quickly share my thoughts on that with you but I'm sure there are good reasons why `FT_Library' is required here. Thanks for shedding some light on this matter + have a wonderful evening everyone :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] All those glpyhs ...
Hi all, out of curiosity for everyone who works on FreeType somewhat longer than I do: how often do compilers tell you it's spelled "glYPh" not "glPYh"? :D Is it just me and will my fingers get in sync eventually or is this a rather widespread phenomenon and should I better get used to that? :D Have a great weekend, Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [GSoC] Update From the Fuzzing Front
> Looks good! Are you going to document your approach in `freetype2-testing's > `README.md' file? Absolutely, definitely! :) However, I plan to have a separate README for "working with/extending the the fuzz targets" to avoid polluting the main README of the testing repository. The same is true for the (looong) table of fuzzed FreeType interface functions. But I'm not sure yet how "complex" the documentation (and the whole `freetype2-testing' repo) should get in the end. After all the fuzz targets should be "simple" tools that are as tiny as possible and 98% self-explanatory. Hence I use a few "hacks" (in OOP sense) to get better trade-offs between flexibility and "as little code as possible". > Everything looks very clean :-) Thanks a lot, that's encouraging to hear :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [GSoC] Update From the Fuzzing Front
Hi everyone, this is a quick update about my GSoC project :) Recently, I explored ways of splitting the fuzz targets that keep engineering and runtime overhead at a minimum (esp. the upcoming engineering efforts) while providing flexibility when it comes to designing fuzz targets that target specific drivers (also adding, altering, and removing specific aspects of said targets quickly). At this point, I am convinced that my current approach (strategy/iterator/visitor) is flexible enough to provide everything that will be needed from the fuzz targets while it adds only a moderate code overhead (I managed to go without factories + proxies which I'd usually do :P). So far, I concentrated on the TrueType target while designing the core and some "extensions". In the next days, I will add dedicated targets for the CFF + CID drivers and finally start tackling code coverage head-on. I really can't wait for that :D Also: currently, I keep track of all (un)used interface functions of FreeType (`FT_*') internally. The plan is to migrate this overview to the README.md to add some transparency about what is (technically) covered and what is missing. Feel free to have a look at https://github.com/cherusker/freetype2-testing (esp. fuzzing/src) and feedback as you see fit: code style, comments, OOP, C++, etc. I am always happy to exchange thoughts :) Have an amazing weekend! Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Unused Variables `xMin' and `xMax'
Commit ae248034106b600e8e3fa9ccc17f63db44b04db3 (yesterday) rendered the local variables `xMin' and `xMax' obsolete; they light up as compiler warnings now. Can we remove them (patch attached)? Have a quiet and nice Sunday everyone, Armin unused.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Review commits
>> I'll take care of it. btw which editor you suggest to use? > > You can use whatever you like. I personally use Visual Studio Code with > Microsoft's C/C++ plugin. > > Regarding formatting: maybe have a look at clang-format. It's flexibly > configurable and takes care of formatting for you. Thinking about formatting > is a waste of brain cycles. I use Emacs and most things of FreeType's codestyle work out of the box with it. Emacs is, of course, a whole different beast to get used to, if you haven't worked with it before. If you're interested though, I will gladly share my settings :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Static website themes for API reference
> [...] Let me know if there are any questions/comments! A few quick thoughts (attention -- highly biased content ahead! :D): #1: MkDocs, #2: Material, #3: ReadtheDocs - In terms of navigation, I think the order is #3 (best), #2 (2nd), and #1 (worst). - When speaking of space efficiency, the order is #1 and #3 (best), #2 (worst). - Search: #2 obviously has the best search function (I like instant search and highlighting of keywords). #1 has at least instant search, but keywords do not get highlighted which is a bit sad. #2 does neither -- no instant search and no highlighting. Generally, all search results look adequate (from what I was able to test), however #2 seems a tiny bit more spot than the rest. - And finally, when talking about what meets my eye, I would go for #2 (best), #3 (2nd) and #1 (worst). Please take all of that with a grain of salt :) > I am also considering trying out https://jekyllrb.com/ [...] I think Mono (http://www.mono-project.com/) works successfully with Jekyll. Have a great day/night, Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Continuous Integration is Live
> We are perhaps miscommunicating. No - I don't think so; at least the direction from-you-to-me works fine; that's exactly what I understood ;) I might have to work on the from-me-to-you direction though; sorry, for being ambiguous. I just didn't like the idea of using `dash` explicitly since it's focused on Debian and does not come pre-installed on, e.g., Fedora. However, calling `sh` should do the trick, independently of any distro -- on Debian systems that would call dash, on Fedora etc. it would call bash, executing in a special `sh` mode. The question that I then had was just a question of preferred style -- whether to call the script directly via the shebang or indirectly via specifying a shell. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Continuous Integration is Live
> A basic smoke test would be e.g. loading a font and rendering all glyphs (and > throwing the bitmaps away) or something. That would catch build system > mistakes for static and shared versions. That sounds easy enough -- I put that on my list and will tend to it if there is some free time :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
