> Is it necessary that project in this organization can be done only
> on Linux or window can also be used?
Both work.
> The source code can be completely cloned on windows?
Yes.
> As I am facing some problem in Windows, so please reply soon
Uh, oh, don't use the phrase “please reply soon”.
Hello Anshuman,
>> Also, Which git repository hosting device Freetype uses - Github or
>> GitLab?
This question deserves a special answer: Right now, please use the
gitlab instance on 'freedesktop.org' from which the FreeType
repository should be cloned.
Hello Utkarsh,
> I want to contribute in the topic Add a ‘capability database’ to
> FreeType's auto-hinter.
Great!
> I have understand what the problem demands. So can you please tell
> me to where I can find the API and source code for this problem? As
> I am not getting these.
What
>> Have you actually played around with the `ftview` tool? Right now,
>> this is the only recommendation I can give to exactly find out
>> what's going on...
>
> Yes, I did. I tried to reproduce the output of version 2.6.1 of the
> 'ftview' demo tool with version 2.10.1. But even with the exact
Hello Manish,
> Want to join the community to discuss the further process with
> mentors and contribute towards the Projects for Google Summer of
> Code 2021.
>
> Looking forward to becoming part of the FreeType Community.
This sounds great, thanks. Please look up similar questions that
Hello Sarthak,
> I am interested to work on this year's GSoC Project - "Develop a
> test framework for checking Freetype's rendering output".
Great!
> So I have done some googling from my side and it helped me to make
> many things clear, I have also read some of last year commits and
>
Hallo Utkarsh!
> I am interested to participate as a student in Freetype
> organization. Can you please send me a sample to give you the
> proposal so that my proposal selected chances get higher.
It doesn't work like that. First of all, you have to select one of
the topics listed at
Hello Giorgos!
> I would like to contribute to one of your GSoc 2021 projects and
> more precisely in the "Improve FreeType demo programs" project. The
> last few days (from the organizations announcing) I look into the
> git-repo code and I am quite excited.
Great!
> I would like to ask you
> [smooth] Reduce copying during integration phase.
>
> We now record `cover' and `area' directly into the linked
> list. This makes rendering faster by 10% or even more at larger
> sizes.
Very nice :-)
Werner
> Here are two more images that contrast the rendering output of
> FreeType 2.6.1 with that of a patched version of FreeType 2.10.1
> using the old default LCD filter. The filter definitely has a
> conceivable impact that brings the output closer to that of FreeType
> 2.6.1. But there are
> What would be the process of attempting to add animation to fonts?
No chance IMHO. Given that you can have little animated GIFs and the
like embedded in a web page, I don't see any necessity for such a
feature. Please remember that fonts are intended primarily to be
printed.
> Here is a
> I experience fonts rendered with the newer versions of FreeType as
> looking pale/'washed out' and somehow blurrier on my low DPI screens
> compared to their rendering with FreeType version 2.6.1 (with
> FT_CONFIG_OPTION_SUBPIXEL_RENDERING enabled).
This is far too vague. Please send
[Please use 'reply to all' so that the information gets sent to the
list, too.]
> I try to compile FreeType in the home directory, but it still
> doesn't work, and the same error occurs.
>
>
> CreateProcess(NULL, gcc -ansi -pedantic -I./objs \
> -I./builds/windows
> [Justyna] To be more precise, my case is PDLCJH+OCR-A font. This is
> incremental font build of OCR-A font.
The correct term is not 'incremental font' but 'subsetted font': The
PDF generator takes your input font and omits all glyphs not necessary
in the output file, thus creating a subset
Hello Justyna,
> Before flagging the font as 'tricky' you are checking its name and
> comparing it with the trick_names table defined in ttobjs.c file.
> This causes that some fonts which aren't tricky are also flagged and
> as a result we can't use autohinting on it.
What names are you
> Google has published more info on this vulnerability now at:
> https://googleprojectzero.blogspot.com/p/rca-cve-2020-15999.html
Thanks!
Werner
Hello Laurence,
> I wondered if you are able to benchmark timings for VF instance
> generation from FreeType. I’d like to know how far away my own
> Samsa JavaScript implementation is from FreeType C.
this is an interesting idea! The natural place to add such code is
FreeType's `ftbench`
> (With GitLab's CI, you don't need a 10 minute cron an can instead
> make CI rsync every commit to master as it comes)
Well, never touch a running system :-) The mirroring stuff is many
years old, but I'm open to any improvements.
Werner
Alexei and others,
what do you think of moving the 'freetype-web' git repository
https://cgit.freedesktop.org/freetype/freetype-web/
to FreeType's gitlab group, too? The actual copying of its contents
to 'www.freetype.org' happens every 10 minutes with a small cron
script on my freedesktop
>> If you have suggestions and/or ideas for new GSoC projects that fit
>> into FreeType, please tell us! The list of projects can be found at
>>
>> https://www.freetype.org/gsoc.html
>
> finish VF driver ?
Idea re-added, thanks.
Werner
>> If you have suggestions and/or ideas for new GSoC projects that fit
>> into FreeType, please tell us! The list of projects can be found at
>>
>> https://www.freetype.org/gsoc.html
>
> finish VF driver ?
Idea re-added, thanks.
Werner
I've just imported the 'freetype2-demos' repository to
freedesktop.org. I used the opportunity to strip off the digit 2,
similar to what has been done for the 'freetype' repository.
https://gitlab.freedesktop.org/freetype/freetype-demos
Please no longer use the Savannah repositories!
I've just imported the 'freetype2-demos' repository to
freedesktop.org. I used the opportunity to strip off the digit 2,
from the repository name, similar to what has been done for the
'freetype' repository.
https://gitlab.freedesktop.org/freetype/freetype-demos
Please no longer push to the
> Tested the new GitLab instance by doing
> https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/3
Thanks a lot!
> Next step: find out what it means for the code to not have a hard
> count of 2, as suggested in the HarfBuzz repo.
Mabe use a hard count of 3? AFAIK, only Indic
We are in the process of migrating FreeType's git repository and
infrastructure from Savannah to freedesktop.org.
https://gitlab.freedesktop.org/freetype/freetype
Savannah's git repository will become read-only for developers soon
but stay in sync with the new location as a mirror.
I've just
We are in the process of migrating FreeType's git repository and
infrastructure from Savannah to freedesktop.org.
https://gitlab.freedesktop.org/freetype/freetype
Savannah's git repository will become read-only for developers soon
but stay in sync with the new location as a mirror.
I've just
> using the latest harfbuzz version, I have this warning [...]
>
> ../src/autofit/afshaper.c:135:5: warning: 'hb_ot_tags_from_script' is
> deprecated: Use 'hb_ot_tags_from_script_and_language' instead
> [-Wdeprecated-declarations]
This is harmless but admittedly annoying. I didn't find the
Folks,
this year GSoC is different in comparison to previous years: The
amount of time a student is going to work on a project has been
reduced by 50%. In other words, it's no longer 350h but only 175h.
As a consequence, projects must be down-sized to adjust to the
available time.
If you
Folks,
this year GSoC is different in comparison to previous years: The
amount of time a student is going to work on a project has been
reduced by 50%. In other words, it's no longer 350h but only 175h.
As a consequence, projects must be down-sized to adjust to the
available time.
If you
Dominik,
I've just merged the 'colr' branch to master (with some minor tweaks
as discussed) and pushed it to the FreeType git repository at
https://gitlab.freedesktop.org/freetype/freetype
Let's see whether mirroring to Savannah works as expected...
>> (1) How can your code be tested? It
> The proposed patch looks like this
> https://github.com/drott/freetype2-colr/commit/a4c2f36b1f6a7a6799248d7e13745f290fa24a69
>
> This would only be needed as long as the feature is not officially
> released, since then we could use version check macros to achieve
> the same.
>
> What do you
>> Running continuous integration on Savannah isn't really an option.
>
> The regression server can poll Savannah every 10 minutes. [...]
Due to our move to freeedesktop.org (hopefully really soon) this
is no longer a problem.
>> However it is not really practical for me to set up servers for
> I took some notes on what formatting details I need to pay attention
> to in the future (in particular with regards to argument lists,
> double spaces after types and between doc sentences, use of tilde in
> docs, and I took some hints on how to phrase commit messages with
> regards to
> I will try to make a PR once you have migrated to gitlab or
> elsewhere.
Great!
> but until then I'd rather not waste the effort until you've
> committed to a more modern git interface.
I fully agree.
Thanks for your offer!
Werner
Hello Greg,
thanks for chiming in!
> Running continuous integration on Savannah isn't really an option.
Yes.
> If the project moves to gitlab as was discussed months ago. I would
> not be opposed to porting my azure configs to gitlab ones.
Hopefully, this is done soon. Anurag?
> However
> What is the status of the test framework project?
Dormant.
> It was attempted during GSoC 2020 but the submitted code does not
> satisfy one of the design criteria: just work. Several parts of the
> project can be improved.
I fully agree. Collaboration with the student was difficult,
> [A preliminary remark: We have to improve FreeType's terminology. For
> example, in `ftconfig.h` there is some talk about 'build directory'.
> Users might assume that this refers to the directory where
> compilation puts its object files. However, this is not the case. I
> will probably
[A preliminary remark: We have to improve FreeType's terminology. For
example, in `ftconfig.h` there is some talk about 'build directory'.
Users might assume that this refers to the directory where
compilation puts its object files. However, this is not the case. I
will probably do
>> In other words, this change
>>
>> -INCLUDES := $(subst /,$(COMPILER_SEP),$(OBJ_DIR) \
>> - $(DEVEL_DIR) \
>> +INCLUDES := $(subst /,$(COMPILER_SEP),$(DEVEL_DIR) \
>> $(BUILD_DIR) \
>>
Alexei,
> + * builds/toplevel.mk: Place `FTMODULE_H' in include/.
Have you tested this commit on a Unix box with a build where 'srcdir'
!= 'builddir', and where 'srcdir' is read-only? My gut feeling says
that your commit is not correct.
We have the following rules, which I consider the
>> [...] Can't run git master anymore :(
>>
>
> If I had to guess it's probably that FT_PIXEL_MODE_GRAY16 was added
> to the middle of the enum, changing the values of the later
> enumerators, changing the ABI.
Ouch. Fixed in git, please try! And thanks for the report and
analysis.
>> Oh, you are using the latest tarball for building FreeType! I have
>> missed that, sorry. Please use the git repository, which has this
>> Meson problem already fixed (and which I used for testing your
>> case).
>
> Don't you think that a bug in the build system is worthy of a new
> minor
> Please see ftoption_unset in builds/unix/configure.raw. This is how
> a robust build system should handle this. Our Cmake and meson
> scripts need to mature a bit to handle ftoption.h that was altered
> by whatever winds or failed builds.
As mentioned in another mail, this Meson support bug
> no test is done line 270, especially :
>
> ftoption_command += ['--enable=FT_CONFIG_OPTION_USE_HARFBUZZ']
>
> is set unconditionally
Oh, you are using the latest tarball for building FreeType! I have
missed that, sorry. Please use the git repository, which has this
Meson problem already
> rm -rf builddir && mkdir builddir && cd builddir
> meson .. \
> --prefix=$3 \
> --libdir=lib \
> --buildtype=release \
> --strip \
> --cross-file ../cross_toolchain.txt \
> --default-library shared \
> -Dharfbuzz=disabled > ../../config.log 2>&1
I tried
Dominik,
> With your agreement — and I am happy to hear feedback and answer
> questions — I would like to start upstreaming our implementation of
> COLRv1 support into FreeType. This contribution is meant as an
> addition to the current experimental support of COLRv0.
I've just pushed a branch
> [...], we can definitely use 8 bit output to represent SDF and
> render acceptable text using it. Now, we can either eliminate the
> current 16 bit output, or, we can keep both 16 and 8 bit output.
> What do you think will be the better option? I think we should keep
> a single output
> I have attached a patch that strip all the custom memory tracking
> stuff.
Thanks a lot, applied!
Werner
Anuj,
I think that the memory debugging functions in file `ftsdf.c` can be
greatly simplified. Since `FT_DEBUG_MEMORY` must be defined I can't
see a reason to not use the default FreeType debugging stuff. In
other words, `SDF_ALLOC` and friends can be replaced with `FT_ALLOC`
and friends
I've just added the SDF module to master (and deleted the 'sdf'
branch). The new demo program is called `ftsdf`.
Please test!
Werner
> Yes, it does work.
>
> ifeq ($(OS),Windows_NT)
> COPY := >nul cmd.exe /c copy
> else
> COPY := >nul copy
> endif # test NT
Thanks for testing! Committed.
Werner
>> Assigning the output of the 'shell' command to the temporary
>> variable fixes the error.
Aah, ok, thanks.
> Nice. The internet suggests redirecting to > nul, which might be
> prepended: i.e.
>
> COPY := >nul copy
>
> or something
Anuj, can you change the `COPY` line in file
> Hmmm. bV5CSType lists LCS_sRGB. [...]
OK, there are still open issues. I'll wait with applying the patches.
Werner
>> Note, however, that there is a problem with the graphics display:
>> On Linux, something has changed in the graphics driver of the demos
>> – instead of a single image I get four, with stripes (see attached
>> image).
>
> The issue is on windows as well. It is a mistake from my end, when
>
>> Note, however, that there is a problem with the graphics display
>
> In the long run, ftsdf needs to become more agnostic to the display
> mode.
OK. Anuj, do you time to work on this?
> Right now it writes directly to the buffer assuming 24-bit (rgb888).
> So the quick fix for now is
Anuj,
I've polished your SDF driver; see the 'sdf' branches in both the
'freetype2' and 'freetype2-demos' repositories. Basically, it's ready
to be merged with 'master' :-)
Note, however, that there is a problem with the graphics display: On
Linux, something has changed in the graphics driver
Amit, Mahesh,
> I am new to open source just contributed in HactoberFest and I
> really wanna contribute more but don't know from where to start. I
> visited your website through GSoC. I have gone through projects and
> want to contribute to it and its newer versions.
>
> Please help me and
> We have multiple programs running with font usage and we would like
> to explore how freetype can contribute to our new projects. Hence
> request you to provide a detailed information on the type of fonts
> or usage of the fonts and if you have any licensing terms (FOSS)
> which can be
> > Which commit (from your GSoC branch) are you referring to?
>
> The changes in `include/freetype/internal/ftdebug.h' in commit
> 802176853 are missing in `logging' branch.
Fixed, thanks, and force-pushed! Please test.
Werner
> The updated code is working fine when we are using the `FT2_DEBUG'
> environment variable with tags(-v / -t / -vt), but without these
> tags I am getting corrupted memory issue with the `features_buf'
> char array in `src/base/ftdebug.c(ft_log_handler)' on both Ubuntu
> and Windows.
D'oh. I
I've just pushed the branch 'logging' to the git repository that
contains the Priyesh's GSoC project, with all commits beautified, and
with many necessary additions.
Please have a look!
Werner
> I'm updating Debian's copyright file for FreeType 2.10.4.
>
> Whose name should be attributed for copyright of the python scripts
> in builds/meson?
I've just added our standard copyright boilerplate.
Werner
> I had tried that before with the same error / result.
Please provide a minimum working example (MWE) that compiles and can
be executed on the command line.
> Is having the BDF module enabled required
No.
> or some other options for font with bitmap strikes to work
> correctly?
For the
> Cool, thanks. Out of curiosity, where did the higher number come from?
> Why is it not the official version number?
Here's the explanation
https://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning
and the history of FreeType's libtool and .so numbers is in
> The freetype2.pc file generated by Meson carries the version number
> 6.17.4 or something (the .so version number), but the one generated
> by configure says "Version: 23.4.17" -- who is right?
'Right' – this is a good question...
> For what it's worth, some build systems like RetroArch's
> The empty line after `* @description:` caused the refdoc build to
> fail,
Applied, thanks!
Werner
> I wanted to know what the hardware minimum requirements for using
> FreeType and FreeType2 would be (minimum RAM, processing power, and
> flash memory if applicable). I was planning on using FreeType for a
> project involving a microcontroller and wanted to know its
> limitations.
FreeType's
> What do you think about a GSoC project to implement native Quartz
> and Wayland ports, considering the current landscape? This is
> somewhat contrary to the ftinspect goals, but I think that our test
> tools should stay rather low level.
Basically, I don't object. On the other hand I wonder
> 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 have made some changes to how ftview selects the color depth mode so
> that there are fewer conversions of the image data.
Thanks!
> As a result, the 32-bit mode is much more readily used. I would
> appreciate it if you test it especially if you have some rare
> hardware or x11 forwarding
>> withdrawn macro that wasn't intended for external usage
>
> We should drop it from the demos too, shouldn't we?
Yes.
Werner
A warning for distribution maintainers: Version 2.10.3 and later may
break the build of ghostscript, due to ghostscript's use of a
withdrawn macro that wasn't intended for external usage:
https://bugs.ghostscript.com/show_bug.cgi?id=702985
FreeType 2.10.4 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
FreeType 2.10.4 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
>> Does this vulnerability affect older (< 2.10.3) versions of
>> FreeType as well?
Yes, down to 2.6, AFAICS.
> It appears that something like this was fixed with 54abd22891 but
> the fix there came too late (after a narrowing conversion) leaving
> some values unchecked.
I think the problem
I've just fixed a heap buffer overflow that can happen for some
malformed `.ttf` files with PNG sbit glyphs. It seems that this
vulnerability gets already actively used in the wild, so I ask all
users to apply the corresponding commit as soon as possible.
Tomorrow I will do a 2.10.4 release.
I've just fixed a heap buffer overflow that can happen for some
malformed `.ttf` files with PNG sbit glyphs. It seems that this
vulnerability gets already actively used in the wild, so I ask all
users to apply the corresponding commit as soon as possible.
Tomorrow I will do a 2.10.4 release.
>> For my taste the 'FT' glyphs are a bit tall. What do you think of
>> reducing the height a bit?
>
> It has to be grid-fitted into a 16x16 icon, which is rather
> universal with larger sizes scaled up. There is 1 pixel margin on
> all sides. I could not convince myself to adjust these margins
> I have added icons to ftgrid, ftview, and ftstring. The EPS version
> is attached too. I thought that little branding would not hurt.
> Please comment.
Very nice, and thanks for the work!
For my taste the 'FT' glyphs are a bit tall. What do you think of
reducing the height a bit? This
> So, we've had a report that building Ghostscript against Freetype
> 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
> use only.
>
> Ghostcript supplies callbacks for memory management
> (i.e. FT_MemoryRec) and we used FT_CALLBACK_DEF() for those, which
> seemed logical when
FreeType 2.10.3 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
FreeType 2.10.3 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
> can I use FreeType to open a raw file with FT_New_Face by filename
> and access the bytes or is it unable to parse raw files.
What is a “raw file?”
Werner
Hello Eric,
sorry for the late reply.
> In cff/cffgload.c, at the end, in the function cff_slot_load: The
> bearings are set early on from calls to a get_metrics() font method.
> Those values are in font design units. Then towards the end of the
> cff_slot_load, there is a call to
> Please consider moving scripts into the build/meson folder for
> consistency. This is where cmake keeps its stuff.
Done.
Werner
> All right, here's the same set of patches with Black applied.
Applied to the repository, with some changes here and there. Please
check!
Werner
> 1. Sum the rendered widths of the following 52 characters:
>ABCDEFGHIJKLMNOPQRSTUVWXYZabcd
> 2. Divide by 52 with round to nearest. The way to do it is to add
>26 and divide by 52.
> 3. Multiply by 8. It's not eight spaces like some rumors say, but
>eight times the average letter
> All right, here's the same set of patches with Black applied. The
> differences are minor, except for the use of double-quotes instead
> of single ones (I don't care personally).
Thanks! Will check your stuff within the next few days.
Werner
> I'll tell Werner that black is better, speaking in my capacity of a
> professional python font developer!
I believe you :-)
Werner
>> Let's not clog the src folder please
>>
>> src/base/amiga (not src/amiga)
>> src/base/unix (not src/unix)
>
> What about using a _.c suffix, as in:
If at all I prefer a `-.c` suffix. Underlines are an
abomination :-)
> src/base/ftsystem_amiga.c
> src/base/ftsystem_win32.c
> etc..
>
> We
> a quick find -name *.c gives files in src/ and also :
>
> ./builds/amiga/src/base/ftdebug.c
> ./builds/amiga/src/base/ftsystem.c
> ./builds/mac/ftmac.c
> ./builds/unix/ftsystem.c
> ./builds/vms/ftsystem.c
> ./builds/wince/ftdebug.c
> ./builds/windows/ftdebug.c
> ./builds/windows/ftsystem.c
>
> These are some horrible numbers that essentially test FT_Load_Glyph
> from compressed unifont.pcf.gz in reverse order: [...]
>
> real0m6.062s
>
> The same string forward is much faster: [...]
>
> real0m0.486s
Ouch.
> Is it well known that rewinding the compressed stream is so
>
> I asked if there were flags to dump the images at some point
I have to apoligize, too – I forgot that Alexei implemented this
feature.
Werner
> Hey guys! Thought you might be interested in this project that claims to be
> 4-5x faster than font-rs and even faster than Pathfinder!. I would have
> loved to integrate the code in FreeType, but 1) I am not competent enough,
> 2) I got exams, so I'll save that opportunity for the future
>
> Any decision yet on whether it should be gitlab.com or
> freedesktop.org?
Nope. We haven't yet contacted the freedesktop.org people. Do you
want to do that?
Additionally, I don't want to rush this so that more people can chime
in – it's still holiday season for many people here in Europe.
> Have you considered dropping infinality especially after v40 have
> been integrated and used to great acclaim?
No, I haven't considered that.
> It is hard to maintain it with hardly any benefits. Reading
> ttinterp.c is prohibitively hard because Infinality is so invasive.
Yes, I know, and
> Ok I believe I was able to commit to savannah but the message is a
> bit cryptic:
Everything's fine, thanks.
> I also added a readme as requested in CI/readme.md.
Thanks. Please reformat the file to make the lines not longer than 78
characters.
> Can anyone confirm this worked and tell me
> I have written the final report for my project.
>
> You can check it out here:
> https://gitlab.com/-/snippets/2007070
Looks great, thanks!
Werner
Dear Anuj, Priyesh, and Greg,
GSoC soon ends! Here are some last remarks.
* Starting with Sept. 1st, your GSoC branches in the FreeType
repository should be frozen. If you want to continue with your work
(which I hope you will do) please copy your branches to new ones and
continue work
> should I write a builds/win32/ftsystem.c ?
I guess yes; it's probably the simplest solution.
Werner
501 - 600 of 5354 matches
Mail list logo
