> ttdebug is definitely one that needs freetype internals.
Correct, together with `ftvalid` and `compos`.
> But ftdump/ftview/ftgrid aren't using special / non-public APIs
> much?
All other programs only use the public API – they are *demo*
programs :-)
Werner
> [...]
>
> But before that, we probably want to get ft2-demos having its own
> ./configure (or cmake equivalent) first. It is a bit wierd that
> detection of librsvg happens at freetype's configure (and freetype
> itself has no use of librsvg), and CC= is also set there. I am a
> little
>> But you still doesn't show us an *exact* recipe or log files that
>> demonstrates the problem you encounter.
>
> Below you can see the error: (the Readline library that '/bin/sh'
> needed was more recent than our custom Readline installation; so
> '/bin/sh' could not find the function it
>> Please describe your setup carefully before jumping to quick
>> solutions.
>
> The problem occurred on an Arch GNU/Linux, and the '/bin/sh
> --version' is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After
> checking the Git repository and noticing that my particular problem
> occurred
> You mean former (instead of latter), ftinspect already depends on Qt?
Yes, sorry.
Werner
> Again the goal is to remove dependencies like XQuartz and make it
> work without it. Adding Qt or Py dependencies is not a solution. Or
> this a different project.
For the latter we already have `ftinspect`.
Werner
>>
>> Do you mean here?
>>
>> https://gitlab.freedesktop.org/freetype/freetype/-/tree/master/builds/unix
>> ...
>
> Please start at README and README.git or here:
> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/docs/INSTALL.UNIX
>
> There is this peculiar autogen.sh to be run
Hello Mahaveer,
thanks for your proposal. However, can you please tell us what
exactly you want to improve? FreeType is a glyph rendering library;
usually, it takes a *glyph index* (and not a Unicode character) as an
input and returns a bitmap rendering of a glyph's outline. Handling
Hello Peter,
thanks for your interest in FreeType.
> I'd like to work on this project: Integrate ftbench into FreeType's
> build structure(s). I have implemented both approaches mentioned
> therein.
>
> I modified ftbench to save its screen output to a file, which is
> then processed by my
Hello Claire,
> I would like to become a contributor to your organization. How do I
> become a contributor?
FreeType is a library to render glyphs of a font, written in the
C programming language. Becoming a 'contributor' essentially means
that you have experience with handling such a
Hello Nitish,
> As I was exploring the idea list, I noticed that the build system
> project was listed as an idea for GSoC 23. I'm interested in this
> project, but I'm uncertain if the ideas listed on
> https://freetype.org/gsoc.html are intended for GSoC 24. At the top
> of the page, it
Craig and others,
have a look at the Merge Request
https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/316
This is a completely cleaned-up version of Craig's
'gsoc-craig-2023-final' branch, ready for being included into
'master'.
I've heavily formatted the code to be in sync
> See attached patch
Applied, thanks!
Werner
> I'm afraid I don't have an exact overlap-less example handy because
> the equivalent static font also hints a bit differently, hiding the
> issue. But I'm referring to the fact that the upper serifs cover the
> upper parts of the stems but the pixels above the stems are darker, so
> the
> I've been looking into various FreeType issues related to the
> combination of CFF2 and hinting. As part of that I ran into the
> phenomenon represented in the attached capture of ftgrid. Which, to
> summarize, has a rendering artifact caused by overlap.
What exactly is the artifact? I don't
Folks,
GSoC 2023 is over; a few days ago the last project has finished – all
FreeType students have passed :-)
We had three projects:
* Ahmet's code to improve 'ftbench' so that it can emit benchmarking
test reports:
> There was an intentional change to src/base/ftobjs.c. I made the
> function that finds the best unicode charmap public so that I could
> use it from the autofitter.
OK, I see. I was confused because the `FT_BASE_TAG` is missing for
this function in `ftobjs.c`.
Werner
> I have added and tested type 3 lookup handling, and also added the
> comments you asked for.
Thanks. Minor nits that I've seen while skimming through:
s/indicies/indices/
s/flatenning/flattening/
> I will begin on the final branch if there's nothing else to be done.
OK. Please rebase
> I need some help figuring out how to handle the type 3 lookups.
> I need to do 2 things:
> - Figure out which features contain type 3 lookups
> - Determine the number of variations the feature contains
Simply add all glyphs a type 3 lookup provides to the list of glyphs.
No further special
> I recently had to extract a TrueType font from a TTC font collection
> as part of fixing bugs in the podofo library[1].
In general, FreeType is not the right tool for such operations.
FreeType is a *rendering* library that provides a thin API for
extracting SFNT tables, mainly the ones
>> I simply noticed that it's possible for 2 characters to map to the
>> same glyph, which means that a glyph would map to 2 characters. I
>> don't have any examples in mind for when this would actually
>> happen. I was planning on either ignoring the situation to let it
>> be resolved
> I don't think this (caching flatten outlines) is a good idea.
Honestly, I don't have an opinion on this.
> Pretty much all serious implementations cache the rendered image.
> And pretty much all uses of FreeType don't render the entire glyph
> set. And must implementations care a lot more
> > OK. I think it is a bad side effect of the current auto-hinting
> > algorithm that there are different approaches.
>
> I just want to clarify: you understood that the reason I used
> different approaches for each letter was to compare the approaches?
> My intent is to use one of those
> I wonder what we should do with the 'festival' and 'lilysong' files
> (and related stuff) in LilyPond. Please have a look at
>
> https://gitlab.com/lilypond/lilypond/-/issues/1245
>
> This stuff is completely undocumented...
Oops, I've sent this to the wrong e-mail list, sorry.
> > Thanks. Do you have meanwhile found an explanation why o-tilde
> > looks so bad for Times New Roman at 16ppem?
>
> All 4 letters in each row have a different approach:
>
> õ: vertical stretch, no segment removal
> ñ: no vertical stretch, segment removal
> ã: vertical stretch and segment
Hello Milan,
I wonder what we should do with the 'festival' and 'lilysong' files
(and related stuff) in LilyPond. Please have a look at
https://gitlab.com/lilypond/lilypond/-/issues/1245
This stuff is completely undocumented...
Werner
> I hope my effort contribute to you. I wish to see you again.
:-) You are invited to continue your work even after GSoC has ended.
> Here is my last version of readme, [...]
Uh, oh, the formatting in the e-mail is completely broken...
> i will push submit my final submission regarding your
Hello Ahmet,
sorry for the late reply, I'm travelling right now.
> -Made documentation and comment line (will continue).
Very nice! Some minor nits, in case you have still time today:
* Please ensure that lines in the documentation are not longer than 78
characters
> I'm facing some issues after porting. while I'm passing unsigned
> char Ubuntu[34816] which is Ubuntu-R.ttf file. By using bin2c
> python script i converted into an C array. while is passed this
> array to the function i'm getting all those error. [...]
Please provide a *complete*,
> Is testing all these combinations really necessary?
I don't know :-) I just wanted to point out that feature combinations
have to be considered.
> [...] My intuition says very few of these combinations actually
> matter.
Yes, I agree.
> I wrote some pseudocode for a different approach that
Hello Ahmet,
> -I have changed the * and the sentence
Thanks. Unfortunately, I was unclear that '*x*' in my e-mail is meant
as Markdown syntax and not to be taken verbatim. In other words, 'x'
should be typeset in italics, similar to a mathematical variable.
Sorry for that, and please fix.
>> With 'bulk test' I mean that you don't time single iterations but
>> do timings for 10 iterations in a group, say, thus avoiding
>> issues with the granularity of the OS timing functions.
>
> I already changed the working way of the timing. I only start the
> benchmark at beginning and stop
> So, if my understanding is correct, hb_ot_shape_glyphs_closure will
> take an input character or characters and tell me all the glyphs
> that it gets transformed into, as well as the final form.
Yes.
> I'm not sure about this interpretation, because the documentation
> uses the term
> Hey, I am a newbie to open source , I only know c , want to
> contribute to your organization . help me
This question has been asked many times. Please visit and search the
e-mail archives at
https://lists.nongnu.org/archive/html/freetype-devel
Werner
> Thanks. One thing I don't understand, is the "+ 2" in the code below:
>
> AF_LatinBlue blue_sorted[AF_BLUE_STRINGSET_MAX_LEN + 2];
>
> for ( i = 0; i < axis->blue_count; i++ )
> blue_sorted[i] = >blues[i];
>
> If that + 2 is correct to be there, then we need a similar + 2
> Upon further investigation, I think my proposed change is correct.
Thanks a lot, committed!
Werner
> I discovered there was an issue when I tried using a test font I created
> with the following as one of its lookups (in ttx format):
>
>
>
>
>
>
>
>
>
>
> There is one lookup here, but 2 substitutions. My program needs
>> Perhaps a hybrid approach is the right one: Use the current
>> infrastructure up to a certain size, being as fast as possible because
>> dynamic allocation overhead can avoided, and resort to dynamic
>> allocation otherwise.
>
> FreeType is not shy about allocating buffers to load a glyph. This
> I will try the dynamic heap allocations for the rendering
> buffer. This might be the largest of them, I think. In addition,
> this should help with the rendering speed when rendering complex
> shapes like
> https://fonts.google.com/specimen/Cabin+Sketch. Currently, FreeType
> makes several
> Something else: I think that the 'TOTAL' line doesn't make sense
> right now. Please separate this line slightly from the rest of the
> table and print the *cumulated timing* (in 's', not 'µs') of all
> tests, something like
>
> Total duration for all tests: 25.3s
>
> and
>
> Total
>> I still think that for such cases the number of iterations of the
>> affected tests should be increased to get more precise values.
>
> the times are for single iteration. (chunk median/chunk size)
Yes, but the number of iterations is the same regardless whether a
test takes 10µs or 1000µs –
> As I was testing my attempt at supporting GSUB lookups, I found that
> hb_ot_layout_lookup_collect_glyphs, is actually not what I need,
> because I assumed that each lookup contains exactly one
> substitution, when it actually may contain multiple. What I really
> need is a way to get each
> here is the results with chris’ suggestion. (thanks chris)
Much better, thanks!
> still a bit noise on only load and load_advances. are results
> acceptable?
As far as I can see, the biggest differences occur if the 'Baseline'
and 'Benchmark' columns contain very small values. I still
>> Should I proceed to detect outliers? Since we do not get the same
>> error rate consistently, I think we will not find the target we
>> expected by outliers.
>
> Why do you think so? Please explain your reasoning. Just remember
> that backup processes (like cleaning up the hard disk,
FreeType 2.13.2 has been released.
It is available from
https://savannah.nongnu.org/download/freetype/
or
https://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
Folks,
I plan to do a new, minor FreeType release until the end of August,
mainly to fix a problem with variable CFF2 fonts. Is there anything
urgent that should be tackled, too?
Werner
Ahmet,
> I have edited the code aligning with the Hin-Tak’s suggestion. Here
> is the two results pages, also pushed on gitlab.
Thanks. It seems to me we are getting nearer. However, there are
still large differences.
* Chris mentioned a potential problem with `clock_gettime` in the
code
>> To summarize: Benchmark comparisons only work if there is a sound
>> mathematical foundation to reduce the noise.
>
> I am probably not qualified, but I am following the discussion for
> some time. And I think there is a problem with the benchmarking
> itself. If I understand correctly the
>>> And dropping support, and/or compatibility/ awareness of intended
>>> usages of outcome in other *cough* microsoft *cough* hinting
>>> models?
>>
>> Well, the Infinality stuff was basically unmaintained; it
>> essentially consisted of a large bunch of exceptions for some
>> special fonts.
>> It's not clear what you are actually asking. ttfautohint is an
>> incarnation of FreeType's auto-hinter, translated into TrueType
>> bytecode, more or less. This is not related to interpreting
>> bytecode.
>
> But does it contain hidden assumptions about how bytecodes are
> interpreted (by
> Yesterday's opentype font meeting touched upon hinting and
> ttfautohint briefly. I see the infinality patch is already gone
> (next release, 2.13.2 I guess - bits of it was removed in 2.13.1
> already). Question is, does its removal impact the functionality of
> ttfautohint?
No.
> Are we
>> What happens if you use, say, `-c 10', just running the
>> `Get_Char_Index` test? Are the percental timing differences then
>> still that large?
> Actually Get_Char_Index, on the three pages I have sent in the
> prev. mail, is higher than 6% only 4 times out of 15 total. (which is
> seem on
> Just remember that backup processes (like cleaning up the hard disk,
> running some cron jobs, etc.) can pop up anytime, thus influencing
> the result.
s/backup/background/
> I have added the total table that you suggested.
Thanks.
> I think Get_Char_Index is not the problem, the results varies all
> the time.
As far as I can see, there is a direct relationship between the total
cumulated time of a test and the timing variation: The smaller the
cumulated time,
> It is one of those things I never remember - winding rule of
> truetype and postscript are different, one is even-odd, the other is
> non-zero. [...]
You are on the completely wrong track here. What I'm talking about is
strictly local and not (directly) related to having two different
> I'm still missing something. Why would the direction of the contour
> matter if, in either case, it's the same set of points?
It doesn't directly matter for your code. However, FreeType's
auto-hinter handles these cases differently (namely, to detect stems),
which might in turn influence
> You said that for an i - like shape:
>> Both contours have the same direction.
>
> What kind of problems does this rule protect against?
Sorry, this was sloppily formulated. It's about the *local* direction
of contours, that is, whether a horizontal contour segment goes from
left to right
> If you're testing this yourself, keep in mind that the adjustment
> will only be applied to n with tilde. Any other letter with a tilde
> can be used as a control group.
Right now I'm abroad (actually, in New York :-) – it will take some
time until I can do such tests, sorry.
Werner
>> What exactly means 'Baseline (ms)'? Is the shown number the time
>> for one loop? For all loops together? Please clarify and mention
>> this on the HTML page.
>
> Clarified that the times are milliseconds for the cumulative time
> for all iterations.
Thanks. The sentence is not easily
Hello Anurag,
> From what I understood, the main performance improvement that
> fontdue claims to have is that it stores the font outlines
> differently, i.e. it seems to perform the curve flattening at
> initial load and stores the outline in the form of "v_lines" and
> "m_lines", presumably
> It is warming up as the given number of seconds with -w flag before
> every benchmark test.
>
> There are still differences like 100%.. Also, 1 sec warmup means
> (test count)*(font count) 70 secs for the results.
Mhmm, I'm not sure whether a warmup *time span* makes sense. I would
rather
> [...] I have confirmed by commenting/uncommenting steps of the
> hinting process that af_glyph_hints_align_edge_points is the
> function that snaps the tilde back to flat, so if my understanding
> is correct, the points at the top and bottom of the tilde are
> forming edges and are being
> I have done the changes you want.
Thanks!
>> 36.5% run difference is bd. AFAICS, you haven't yet worked on
>> omitting 'warmup' iterations, right?
>
> I am planning to increase the iteration count by 10% and ignore the
> results for them.
You mean you are going to ignore the first 10%
> I am currently working on implementing optimizations from fontdue in
> the `dense` module.
Any progress code-wise? Two weeks have passed, and I only see minor
adjustments to the MarkDown document conversions – and no report from
you :-)
Werner
> I have an algorithm I'm testing for the tilde unflattening. I went
> with doing it before all steps, because it worked better with my
> idea, but the function af_glyph_hints_align_weak_points is undoing
> my changes.
Hmm. Have you checked the OpenType specification how the IUP
instruction
Here is my new bunch of remarks. In total, we are getting nearer to
meaningful results :-)
* The build process seems to be ok now, very good!
* After doing `make baseline` (and `make benchmark`) I see as the last
line
```
Processing 100%...\nBaseline created.
```
This `\n' looks
> > Just take the extrema of *all* points – for fonts this should be
> > good enough, because it is standard to have points at the curve
> > extrema, thus making the bounding box of the curve identical to
> > the bounding box of the points (both on and off points).
>
> Ok, thanks. This is
Hello Craig,
again sorry for the late reply.
> During this time, I realized that knowing the bounding box of the
> tilde contour would help a lot. In fact, the logic for the other
> vertical separation adjustments assumes that it can get the bounding
> box by taking the minimum/maximum
>> Many-to-one: accent marks, e.g. umlauts
>> One-glyph-to-many-unicode-characters: ligatures, e.g. "ff", "fi".
>
> I don’t see how these two cases are different. An accented glyph like
> ⟨ɑ̃⟩ is made up of two Unicode characters, ɑ+◌̃ (U+0251 U+0303);
> similarly a ligated glyph like ⟨fi⟩ is
>> A mapping from input Unicode characters to glyph indices based on
>> the GSUB + cmap tables and not on cmap alone.
>
> Right now, the only cases where the GSUB table is helpful that I am
> aware of, for the purposes of this project, are for handling glyph
> alternates and combining characters.
> Right now, I don't understand the needs well enough to know what to
> generalize or to test whether the general solution works well
> enough. I'd rather start with specific use cases rather than a
> general solution with unclear goals.
Well, there are no 'unclear goals': the general solution
> Since hinting glyphs that are descendants of combining characters
> will help few fonts, what other ways does the database need to use
> the GSUB table? The only other use case I'm aware of are one to one
> substitutions providing alternate forms of a glyph.
Probably yes, but who knows. It
> I'd like to not call "FT_Glyph_To_Bitmap()" but just do
> 'FT_New_Glyph()' on my own, but that always crashes. Why?
What does the debugger say? This might give a hint.
Are you sure that the memory allocation routine in your code is the
one used by FreeType? `FT_MEM_ALLOC` is an internal
> about percentages, i runned the bench with -c 200 to have instant
> results for development process. here in the benchmark file
> attached, it made more acceptable result when increased the -c flag
> to 2000.
This is much better, thanks! However, there are still tests which
have a difference
> The next thing I'm doing for the adjustment database is making
> combining characters work. Currently, only precomposed characters
> will be adjusted. If my understanding is correct, this would mean
> finding any lookups that map a character + combining character onto
> a glyph, then apply
> Yep! https://github.com/wenzhuman/fonttools
Thanks. Unfortunately, this lacks top-level documentation, AFAICS,
describing the changes in comparison to upstream 'fonttools'.
Additionally, the git clone uses the 'master' branch for changes,
which is problematic.
It would be great if someone
> A long time ago I had some grad students write a compiler
> infrastructure for TrueType bytecode.
Ah, I faintly remember :-)
> Maybe it's mostly bit-rotted, but if someone were interested in
> working on this, I could try to help.
Thanks. Is this code available in a public repository?
[leaving 'freetype-devel' in the CC]
>> Let's assume that you can't discern colors A and B, where both map to
>> exactly the same gray value C (or to almost identical values). If a
>> glyph uses those two colours exclusively, you will have problems with
>> both a colour and a gray-level version
> How to throw away the bitmap resulting from running
> FT_Glyph_To_Bitmap(), and replacing it with a new one that may be
> one pixel large or smaller in width and/or height?
It's not exactly clear to me what you want to do, but what about using
`FT_New_Glyph` and/or `FT_Glyph_Copy`?
> > A somewhat related question - colour fonts are used beyond
> > emoji's. While there are 5 kinds of emoji fonts now, and most
> > people are using one of 4... but if you check Google Fonts, there
> > are 10 colour fonts, one is emoji, but 6 are Arabic (useful for
> > annotating the
>> ... please post a link to the report if you do so :-)
> https://gitlab.gnome.org/GNOME/librsvg/-/issues/997
By the way, is there any progress whether Adobe's compact SVG native
viewer library can be used as a FreeType hook? It comes with a Cairo
backend, among others...
>> If Craig's modifications to the auto-hinter code become mature it
>> would be very helpful if they got added to `ttfautohint`, too
>> (however, this wouldn't be a trivial thing to do, unfortunately).
>
> Hmm, what would make it so hard?
The 'new rules' for the auto-hinter must be converted
>> ... please post a link to the report if you do so :-)
> https://gitlab.gnome.org/GNOME/librsvg/-/issues/997
Thanks!
Werner
> I'll look into this after I resolved all backlog issues of ftinspect
> (MM/GX default and PSName issue, UI bug in #26, and colored SVG
> fonts).
Great, and thanks in advance!
Werner
>> I would expect that, if the diacritic is to be hinted as a
>> horizontal bar, that would occur only at the smallest sizes, and
>> would equally affect the combining diacritic too.
>
> Somebody more knowledgeable can correct me, but I think combining
> diacritics happens with:
>
> Outline1
> Btw, anybody done QT6 build of ftinspect lately?
Well, looking into `src/ftinspect/{meson.build,CMakeLists.txt}` I only
see build support for Qt5. Apparently, Qt6 support was tested
experimentally only.
Charlie, can you comment, please?
Werner
> [...] I seem to have found a problem with the rsvg/cairo-based hook
> with the Google Nabla color font.
>
> [...] I found that rsvg+cairo hook renders it B/W [...]. Strangely
> enough, with the skia-based hook, I see the expected color look.
> [...] this seems to suggest that the SVG in this
> One question, is c++ built libfreetype binary completely compatible?
> It seems the opposite is (c++ built ft2-demos can use c-built
> freetype) is.
I think that in general it is possible to use C libraries as-is in C++
but not vice versa.
> Basically I am thinking of doing a
>
>
> I’ve attached an interesting hinting problem seen ‘in the wild’.
> [...] I would expect that, if the diacritic is to be hinted as a
> horizontal bar, that would occur only at the smallest sizes, and
> would equally affect the combining diacritic too.
The Noto fonts use `ttfautohint` for
> * i modified benchmark program not to report 'time per op’ but
> rather 'cumulative time per N iterations'
> * changed the table design
> * sentence 'smaller values are better’ is present
> * embed a small CSS fragment at the top of the page
> * linked to the original baseline and benchmark
> I added a "-s" command line option to both ftview and ftgrid to swap
> rsvg out with skia and run the same binary twice, one with "-s" and
> one without, just to look at them side by side. Fixed the pixel
> positioning discrepancies. Patch posted online below
>
>
>
> another small patch for ft2-demos. Should be obvious/trivial.
Thanks, applied!
> I had a quick look at swapping the renderer hook on the fly. It
> seems that it is set when the module is loaded (i.e. the first font
> that needs it, I think), and I actually cannot see when it is
> unloaded,
> The default zoom level for ftgrid seems to have changed between
> 2.13.0 and 2.13.1 from 4 to 6?
Yes. If Alexei is back he can explain this in more detail :-)
Werner
>> If we are going to overhaul the build system, I’ve long wanted to
>> have FreeType demos build as a separate package that links against
>> a system-installed FreeType library (not the source directory).
>
> I second that! I think only ttdebug definitely wants to link against
> freetype at the
> I would try to let AX_HAVE_QT() macro to find appropriate set:
> https://www.gnu.org/software/autoconf-archive/ax_have_qt.html
An alternative to that may be autotroll
https://github.com/tsuna/autotroll
that is used in ttfautohint.
Werner
>> If ftinspect and, potentially, other software is not going to be
>> built via autotools, is there a case to move to another build
>> system?
Well, yes. Meson will eventually become the main tool for building
FreeType, I think (or rather, it definitely won't become CMake as the
default).
>> Perhaps a misunderstanding: I want to know how *the code* should be
>> changed. Can you provide a pseudo-patch or something like that?
>
> I just means something like this - it being before
> "modules[FT_MAX_MODULES]" (a structure changeable in size per
> build/release) in particular.
>> Hmm, what exactly do you suggest? `FT_LibraryRec` is an internal
>> structure not exposed to the public, so it could be changed easily
>> without any backward compatibility issues.
>
> Exactly as what I wrote - if a next major version of freetype (3)
> happens, and one is allowed to break
>> After pressing the (uppercase) 'P' key, an image called
>> `ftview.png` is stored in the current directory – at least on my
>> GNU/Linux box.
>
> I still can't find the ftview image,
Strange. Are you running on a GNU/Linux box? Can you try to use
`strace` to find out where the file gets
Toshiya-san,
Hin-Tak reports the following:
> I set up both freetype2 and ft2-demos for multiple remotes and track
> both gnu savannah and gitlab in both. For most parts freetype2 to
> stay in sync (I think occasionally one stays behind the other for a
> day or two), but ft2-demos on
1 - 100 of 3661 matches
Mail list logo
