Hello everyone,
long time no see :-)
I'd like to know if Werner and others are interested in switching the
FreeType repository to git in the near future ?
I've been a heavy user of the tool since several months, and while there are
really a few bat-shit insane user-interface
issues with it
2009/2/23 Mike Moening mi...@reteksolutions.com
In the 2.3.8 documentation it states that each thread should have its own
FT_Library object.
Currently we keep one FT_Library per FT_Face.
We have a C++ wrapper object per font face which wraps these two together.
We use FT_New_Memory_Face()
Tad !
An experimental git repository is now in place, see http://git.freetype.org
Note that:
- this was created by taking a snapshot of the current CVS repository;
running git-cvsimport on it then 'git-filter-branch --msg-filter' with the
attached (basic) script to improve the
Hello,
I'm currently updating the Android FreeType sources to the latest CVS. In
doing so, I noticed something that unfortunately
escaped me before that: we added a new field to a publicly declared
structure, thus breaking the ABI.
More specifically, the declaration of PS_FontInfoRec in
Hi David,
that's ok, but I'm surprised this didn't get caught. The problem is even
worse than I thought because PS_FontInfoRec is
also used to define the fonts_infos in the PS_BlendRec structure (I don't
think we have any client code that accesses
this though).
I have submitted a fix to the CVS
2009/2/25 Jean-Claude Repetto jrepe...@free.fr
David Turner a écrit :
This has been recently fixed in the CVS repository, see this for details:
http://git.freetype.org/?p=freetype2.git;a=commitdiff;h=7bb1c4ce1221edb3ed900666fee3eae790255820
Hello,
Thanks to mpsuzuki, Werner and David
2009/3/3 Werner LEMBERG w...@gnu.org
Would it make sense to first convert to GIT then later change the commit
messages there.
I tried that, and it doesn't work properly.
Ah, can you tell me which problem exactly ? I could do the migration myself.
By the way, I started documenting it at
It'd be nice if we could remove the 2.3.8 packages from the Savannah server.
I'll try to do that.
2009/3/3 Werner LEMBERG w...@gnu.org
I have submitted a fix to the CVS repository (which wasn't too
trivial).
Thanks. I'll release a new FreeType version probably in a week or so.
2009/3/7 Jun.Wang xjw...@sunmedia.com.cn
I did the memory debug with a little modify.
1. In FT_Done_FreeType( FT_Library library ), I disabled the line:
FT_Done_Library( library ), so the memory report will disaply the current
memory.
???
2. I call FT_Done_FreeType() before
Hello,
thanks a lot for your work. Can you add some clarification to the ChangeLog
of the first patch that explain why it is needed ?
Regarding the second patch, the internal code uses the convention of naming
functions as:
object_method( Object* o, )
It would be nicer if you could keep
Thanks you werner, I did read the second set of patches, and my comments
still stand.
Another major issue that I have with the code is that it is very error-prone
and very cumbersome
to have these 1000 macros for declaring and defining classes. I would really
prefer if we could
use a simpler
Thank you Oran, this looks better indeed. However, this is a patch against
your previous patch and a patch against the current git sources would be
better.
I also tried to apply your previous set of patches to the git repository,
and it failed due to inconsistencies with the ChangeLog file. Can I
2009/4/5 Oran Agra o...@monfort.co.il
Hi,
I've pushed the PIC changes into GIT (including moving the changes from the
public headers to ftobjs.h).
Please let me know if there are any problems.
I've checked that it builds with the jam system (non PIC) with VS2005.
And also that the PIC
Hello,
just to let you know that I have recently tried to cleanup a bit the recent
Position-Independent-Code
that was contributed to the FreeType sources. While this works is really
nice, I believe it represents
a vast challenge in terms of maintanability for the people who don't care
about PIC.
Hello,
just to let you know that I have recently tried to cleanup a bit the recent
Position-Independent-Code
that was contributed to the FreeType sources. While this works is really
nice, I believe it represents
a vast challenge in terms of maintanability for the people who don't care
about PIC.
, but this is only used to document
high-level changes that affect
client developers.
Maybe we need another file like docs/INTERNAL-CHANGES.TXT ?
2009/3/25 Huw Davies h.davi...@physics.ox.ac.uk
On Wed, Mar 25, 2009 at 03:37:13PM +0100, David Turner wrote:
I also tried to apply your previous set
2009/4/15 Werner LEMBERG w...@gnu.org
Please no. This is even more work.
IMHO we should force everyone to commit *small* chunks, split into
easily readable code fragments. This would help more than anything
else.
OK, then I think we should definitely make the ChangeLog format easier
to
2009/4/14 Dmitry Timoshkov dmi...@codeweavers.com
Oran Agra o...@monfort.co.il wrote:
Waiting to see your suggested solution.
I'd once again suggest to stop making FreeType code ugly and force
broken platforms to upgrade their compiler toolchain instead.
Actually, I'm trying to make the
Welcome back tom :-)
In my opinion, reading the following is a definitive requirement for anyone
working with git:
http://eagain.net/articles/git-for-computer-scientists/
Git is very flexible, but the mental model one requires to maintain to use
it is much more demanding than traditional VCSes.
As noted by other posters, FT_Init_Library is a convenience function. You
may want to use FT_New_Library instead to provide your own custom allocator.
2009/6/22 Werner LEMBERG w...@gnu.org
both FT_New_Memory, and FT_New_Library (functions called within
FT_Init_FreeType) are allocating
Looks fine to me
- David
2009/6/19 Werner LEMBERG w...@gnu.org
I got the following:
There is not need to call ft_fseek() every time when execute
ft_fread(). Here is the patch:
ftsystem.c:
FT_CALLBACK_DEF( unsigned long )
ft_ansi_stream_io( FT_Stream stream,
correct
estimates of all the bytes consumed is impossible.
Hope this helps.
- David Turner
2010/3/10 Maggy Anastasia maggymaggyma...@gmail.com
Dear FreeType Developers,
I have a few questions regarding freetype memory consumption upper bound; I
am using Freetyper version 2.3.7
(1) static
Hello,
Just to make it clear, I'm too in favor of adding an Apache2-like patent
clause to the license.
And for the sake of full-disclosure, my employer does releases quite a
large amount http://source.android.com of Apache-2 licensed code.
On Fri, Jan 13, 2012 at 8:34 PM, Eric Rannaud
On Tue, Jan 17, 2012 at 3:53 PM, Dave Crossland d...@lab6.com wrote:
But its GPLv2 only :-(
Apache 2 is GPLv3 compatible.
So I'd suggest either using Apache 2, or using FreeType License 1.1
and GPLv2-or-later.
Apache 2 or GPLv2-or-later have the same problems: they require changing
the
Hello Alexei,
On Thu, Jan 19, 2012 at 4:08 AM, Alexei Podtelezhnikov
apodt...@gmail.comwrote:
On Fri, Jan 13, 2012 at 2:13 PM, Werner LEMBERG w...@gnu.org wrote:
3. Grant of Patent License.
Do freetype authors hold or have they filed for a patent? Don't you
need it first before
Forgot to reply on-list, sorry
2012/2/1 David Turner da...@freetype.org
2012/1/28 suzuki toshiya mpsuz...@hiroshima-u.ac.jp
Also I've checked ANSI C (C89) spec draft, available on:
http://flash-gordon.me.uk/ansi.c.txt
In the description of sizeof operator, I could not find explicit
2012/1/17 Erik Dahlstrom e...@opera.com
Hi,
after I submitted my first patches I found a bunch of other PIC issues. I
see that you have fixed some of the same things I found too, mostly missing
includes to the various error-headerfiles, and a bunch of unitialized
variables for clazz and the
2013/1/23 Werner LEMBERG w...@gnu.org
Folks,
just a heads-up which might influence applications: I've just fixed a
bug in the TrueType handler to correctly compute the `height' value of
the `FT_Face' structure. Up to now, the following was done:
ascender_int = round(ascender_26.6);
My recent patch to reformat the subpixel code broke C++ compilation, sorry
about that.
However, here's a fix
It turns out that C++ doesn't allow you to declare (and not define) a
static constant.
- David
0001-Fix-C-compilation.patch
Description: Binary data
2013/3/27 Werner LEMBERG w...@gnu.org
It's an issue when ttfautohint is using dummy glyphs as a workaround
for hinting composite glyphs. Untill know it was assumed that it
was a problem free workaround. My report shows that it seems to be
creating problems on OSX Chrome. Of course it
Hello,
Here's a small set of patches that slightly improve the performance of
FreeType when compiled for ARM and x86_64 with GCC. I also checked that it
doesn't negatively affect x86 performance.
On ARM, loading glyphs is about 3% faster, and rendering gray bitmaps is 6%
faster.
On x86_64,
2013/7/16 Luiz Henrique de Figueiredo l...@impa.br
At two places in FT_Outline_Decompose there is a division by 2 that
loses one bit of precision. A client walking manually through the
contours of a glyph and mapping the control points to floats by
dividing by 64 and then doing any required
this in small
incremental steps.
Voila, I'd be happy to read your suggestions, Happy to be here.
- David Turner
Le jeu. 30 avr. 2020 à 03:30, Alexei Podtelezhnikov a
écrit :
> On Wed, Apr 29, 2020 at 8:34 PM David Turner wrote:
> >
> > Starting a thread here to discuss potential build system improvements
> for FreeType.
> >
> > The current FreeType 2 build system
system at all!
- David
From 4095fc04234a73b825dc122b86d903835988863d Mon Sep 17 00:00:00 2001
From: David Turner
Date: Thu, 30 Apr 2020 11:03:33 +0200
Subject: build: Simplify module.mk syntax
This patch modifies the syntax expected from module.mk
files to make it considerably simpler. Now, each fi
r the
> > next few months I expect us to remove our cmake one and eventually the
> > autotools one (which is the "official" one right now).
> >
> > Hope that helps,
> > behdad
> >
> > On Wed, Apr 29, 2020 at 5:34 PM David Turner wrote:
> >
>
Le jeu. 30 avr. 2020 à 10:40, Nikolaus Waxweiler a
écrit :
> One thing regarding build systems and IDE/tool integration:
>
> Cmake and others can generate a
> https://clang.llvm.org/docs/JSONCompilationDatawas a portabililty
> nightmarebase.html
>
Yes, none of that is urgent :) Feel free to not push them to master for now
(branch or no branch).
I'd still value your input on the content though, hope it's not too scary :)
Le ven. 1 mai 2020 à 10:25, Werner LEMBERG a écrit :
>
> > Here are two cumulative patches that try to simplify the
Le ven. 1 mai 2020 à 10:12, Albert Astals Cid a écrit :
>
>
> I apologize if somebody felt personally wronged by my comment.
>
> Since I don't see anything wrong with it, I would be very happy if you
> could please explain what's wrong with it so I can try to improve myself in
> the future.
>
>
From: David Turner
Date: Thu, 30 Apr 2020 02:12:59 +0200
Subject: Fix compilation warnings
Fix various compiler warnings when building the FreeType 2
demo programs:
- graph/x11/grx11.c: Changed the return type of
gr_x11_surface_listen_event() to match the expected type.
- src/: Remove
mmit message to look like
what is currently in the git log.
> and track them in ChangeLog, which is debatable
>
> Yes, it seems a bit odd these days, but I'll let Werner be the judge on
that :-)
From 1b44f35d259622ebb837d9d00833502ac751df13 Mon Sep 17 00:00:00 2001
From: David Turner
ype 1.3.1 !!
ReactOS: ??
Skia: https://github.com/google/skia/tree/master/third_party/freetype2
modules: no raster1, type1, pfr, bitmapped formats
options: seems to be using the default, i.e. no subpixel rendering, no
harfbuzz, no adobe glyph list
Le ven. 24 avr. 2020 à 16:02, David Turner a écrit :
Le ven. 24 avr. 2020 à 22:46, Nikolaus Waxweiler a
écrit :
> Woah
>
> My favorite pet issue I never got around to fixing: make stem darkening
> for the autohinter be as good as the CFF variant. Also, at least basic
> stem darkening for bytecode'd TTFs.
Can you clarify what that means
Thank you, filed as https://savannah.nongnu.org/bugs/index.php?58275 now
Le mer. 29 avr. 2020 à 18:18, WILSON, MICHAEL a
écrit :
> Good afternoon,
>
>
>
> When building FreeType, GCC is warning of strncpy() calls which are not
> nul terminated.
>
> Probably not a big problem in view of the
Starting a thread here to discuss potential build system improvements for
FreeType.
The current FreeType 2 build system has many flaws. To its credit, it was
designed in a very different time, when things like CMake / Meson / Ninja/
Maven / GN / Bazel didn't even exist, when Autotools was
f someone is opposed to that, please speak up!
- David
> best regards
>
> Vincent Torri
>
> On Fri, Apr 24, 2020 at 10:02 PM David Turner wrote:
> >
> > Hello freetype-devel@ list members,
> >
> > It's been a very very long time, but I have some free time in
Le jeu. 14 mai 2020 à 20:35, piotrunio-2...@wp.pl a
écrit :
> The standard ppem of the test font is: 16
> The standard string of the test font is: !"#$%
>
> From the image, it is evident that both FreeType and TD renderer (my own
> renderer that relies on FreeType but uses my own rasterizer,
>
le. Any informed opinions on this?
I'm adding two git bundles related to the experiments I've described there
(nothing to consider for submission, imho, for now).
I'll prepare some patches to simplify our existing build files and
customization process as explained above, unless someone has bette
Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler a
écrit :
> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means
That's actually great feedback, thanks Piotr, we'll have a look.
Le dim. 17 mai 2020 à 20:47, Alexei Podtelezhnikov a
écrit :
> >> From the image, it is evident that both FreeType and TD renderer (my
> own renderer that relies on FreeType but uses my own rasterizer,
>
Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler a
écrit :
> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means
Here are two patches to remove the Jamrules/Jamfiles from the build and
documentation.
- David
From bfae69d8320e269975ba59f6293031242e9d7653 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 18 May 2020 09:16:12 +0200
Subject: [build] Remove Jamfile files from the tree.
These have not been
It turns out the macro is never used, anad is never included.
From 3d9ce21da3fb4af2a90147ee513add6542808dcd Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 18 May 2020 09:33:38 +0200
Subject: [build] Remove obsolete HAVE_STDINT_H probing macro.
This macro was updated by the unix
I agree with Alexei that it's probably a good idea to start writing a
prototype with whatever language / format you feel the more fluent first so
we can look at the algorithms and the outputted data.
This can later be rewritten into something more FreeType-specific (e.g.
fixed-floats are better
Le lun. 18 mai 2020 à 09:03, Priyesh kumar a
écrit :
> Hey,
> I wanted to ask that after selecting desirable external library how should
> I proceed:
> 1. Should I stick to the existing debugging facility in which filtering of
> log messages is based on debug level comparisons of various
Le lun. 18 mai 2020 à 10:49, Priyesh kumar a
écrit :
> Thanks for the reply...
>
> *>I recommend not baking details of the logging library into the rest of
> FreeType whenever possible. One thing that can be done is to send
> structured logs from FreeType, i.e. instead of >FT_Message() sending a
version of
the patch that does just that with a helper script.
I'd like to extend this scheme to more configuration variables in the
future, but after we complete this build transition.
- David
Thank you,
> Alexei
>
>
>
> On Mon, Aug 24, 2020 at 10:55 AM David Turner wrote:
> >
t; regards
>
> Vincent Torri
>
From 0035aef6df4d09924f987033228e56f32bd30166 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.
This adds a few files to build the FreeType 2 library
with the Meson build system:
- meson.build
Le lun. 24 août 2020 à 22:34, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > - builds/meson/ftconfig.h.in: template versions of
> > ftconfig.h to be used by the Meson build. It is processed
> > by Meson, which will turn #mesondefine statements into
> > #define / #undef depending on
Le ven. 18 sept. 2020 à 16:22, Alexei Podtelezhnikov a
écrit :
> 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:
src/base/ftsystem_amiga.c
src/base/ftsystem_win32.c
etc..
We are no longer limited
Le mar. 19 mai 2020 à 14:09, Hugh McMaster a
écrit :
> On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote:
> > > - Meson as the primary build system for FreeType developers, which
> > > includes the ability to run tests, sanitizers, coverage analysis,
> > > etc.
> >
> > It seems that Meson
Le mar. 19 mai 2020 à 09:30, Priyesh kumar a
écrit :
> Thanks for the reply,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *>Basically yes. As an improvement, I would like that the value of
> the>`FT_COMPONENT` macro can be displayed optionally, e.g.>[afhints] foo
> bar>[ttgxvar] sproink>...>The idea is that
Le jeu. 17 sept. 2020 à 15:42, Alexei Podtelezhnikov a
écrit :
> > Patch attached for avoid adding lib prefix when compiling with mingw and
> also letting to use FT_CONFIG_OPTION_ERROR_STRINGS from cmake command line.
>
> The lib prefix is your personal aversion.
It depends. There is value for
bout these.
- Digit
PS: This introduces several python scripts, I have been using the "yapf"
tool to format them. If you know of a better python reformatter, let me
know.
From 45017badeade312778b7e0107873e9649ff52e34 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Sun, 17 May 2020 18:45
Le ven. 18 sept. 2020 à 14:18, Alexei Podtelezhnikov a
écrit :
>
>
> On Fri, Sep 18, 2020 at 7:18 AM David Turner wrote:
>
>> Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG a écrit :
>>
>>> > These are some horrible numbers that essentially test
Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG a écrit :
>
> > 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
>
>
PS: This introduces several python scripts, I have been using the "yapf"
>> tool to format them. If you know of a better python reformatter, let me
>> know.
>>
>
> Black It's the best
>
>>
From 8dcb5c0789a8065947eb66d08ceae730b6afae87 Mon Sep 17 00:00
avid
[1] Except if each thread has its own FT_Library instance (and
corresponding set of FT_Face/FT_Size/FT_GlyphSlot objects.
I will keep trying to comment on the two GSoC projects, and eventually get
> to write about the health of the freetype as a community project.
>
> Cheers,
> behda
Le mer. 24 juin 2020 à 13:49, Alexei Podtelezhnikov a
écrit :
> Hello David,
>
> > create mode 100644 include/freetype/config/compiler_macros.h
> > create mode 100644 include/freetype/config/integer_types.h
> > create mode 100644 include/freetype/config/mac_support.h
> > create mode 100644
everyone.
>
> I definitely prefer '-' over '_'.
>
> Thanks, let's go with it. Here's the rebased and updated patch then.
>
> Werner
>
From 1d2fe6e959f4fb4a3321eab1a104298118273541 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Tue, 23 Jun 2020 20:54:41 +0200
S
itionally, such a change should be
> introduced right after a release.
>
> > here's another patch that tries to fix this. Sorry about that.
> > Also Ben Wagner noticed me that some third-party code is using
> > FT_UNUSED(), so I've moved it back to public-macros.h to avoid
&g
o issues for you, David :-)
>
>
> Werner
>
From 8abef31464aea930e3d947fa611845eff97d Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 6 Jul 2020 10:56:36 +0200
Subject: [build] Fix multi and C++ builds.
The following builds were failing due to previous changes:
make multi
make multi CC="c++"
Le mar. 30 juin 2020 à 15:27, Werner LEMBERG a écrit :
>
> > Here's the rebased and updated patch then.
>
> Thanks. However, what you've sent are actually two completely
> separate things: The splitting of `ftconfig.h` into smaller files, and
> the modification of `FT_BASE' and friends. Please
code works as expected though?
Thanks
- David
Le mar. 23 juin 2020 à 20:16, David Turner a écrit :
>
>
> Le mar. 23 juin 2020 à 05:42, Alexei Podtelezhnikov
> a écrit :
>
>> Hi again,
>>
>> The oversampling is implemented though inflating the outline and then
>>
Le dim. 14 juin 2020 à 07:06, Stephen McDowell a
écrit :
> Hi Alexei,
>
> It's only __builtin_shuffle that's a problem. I'm a simd novice at best
> hehe. I played around for a good long while trying to find an equivalent
> shuffle intrinsic, for now I was just working off of the GCC examples
Le mar. 23 juin 2020 à 05:42, Alexei Podtelezhnikov a
écrit :
> Hi again,
>
> The oversampling is implemented though inflating the outline and then
> averaging the increased number of cells using FT_RASTER_FLAG_DIRECT
> mechanism. The first two patches set the stage by splitting the code
> paths
From: David Turner
Date: Tue, 23 Jun 2020 20:54:41 +0200
Subject: [build] Simplify
This patch simplifies the content of ftconfig.h by
moving things around a little, i.e.:
- Move public compiler macros needed by the FreeType
API headers to ,
while all other macros that are only used
And the previous patch didn't handle CMakeLists.txt properly, so here's a
third version that fixes the issue.
Le mar. 23 juin 2020 à 22:25, David Turner a écrit :
> Good catch, here's the updated patch that also modifies
> builds/vms/ftconfig.h
>
> We might remove support for __BORL
and implement so far :)
Thank you
Le mar. 23 juin 2020 à 22:03, Alexei Podtelezhnikov a
écrit :
> On Tue, Jun 23, 2020 at 3:05 PM David Turner wrote:
> >
> > [build] Simplify
> >
> > This patch simplifies the content of ftconfig.h by
> > moving things around
Le sam. 6 juin 2020 à 15:31, Werner LEMBERG a écrit :
>
> Hello Greg,
>
>
> > So over the week I started writing continuous integration build
> > tests for several platforms. You can preview them here:
> >
> https://dev.azure.com/fundies/freetype2/_build/results?buildId=146=results
>
> this
Le sam. 6 juin 2020 à 21:53, Greg Williamson a écrit :
> So autotools is the current build system but that will only work on linux
> and mingw correct? I can certainly check freetype builds with autotools on
> those platforms but I don't think it's compatible with msvc & xcode. I
> can't really
Thanks Werner, the patch looks good to me :-)
Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > Since nobody does development on DOS or Windows 9x anymore, we can
> > finally drop the requirement to use file names limited to the 8.3
> > format, which was the reason
Le ven. 5 juin 2020 à 00:00, Werner LEMBERG a écrit :
>
> This is the first time ever that I got a git bundle to handle, and I'm
> stuck. I don't know how to apply it to the git repository. Trying
>
> git pull freetype2-remove-macro-includes.bundle
>
> results in
>
> fatal: Couldn't find
Hello everyone,
Le mar. 9 juin 2020 à 14:14, Alexei Podtelezhnikov a
écrit :
> Hi David,
>
> I actually thought about FT_Add_Module as a visionary interface for
> dynamically plugging alternative renderers:
>
> https://github.com/raphlinus/font-rs
> https://github.com/mooman219/fontdue
>
And here's the patch to fix freetype2-demos compilation first.
Le jeu. 4 juin 2020 à 02:42, David Turner a écrit :
> Since nobody does development on DOS or Windows 9x anymore, we can finally
> drop the requirement to use file names limited to the 8.3 format, which was
> the r
Le mar. 9 juin 2020 à 01:06, Alexei Podtelezhnikov a
écrit :
>
> >> We can remove as well, can't we? It is only used to
> >> define the macros. So it is either ft2build.h and macros or neither.
> >
> > Not until all the consumers of FreeType are adapted to use direct
> > header inclusion
Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > Since nobody does development on DOS or Windows 9x anymore, we can
> > finally drop the requirement to use file names limited to the 8.3
> > format, which was the reason why the FT_LONG_HEADER_NAME_H macros
> > were
)
Very fortunately, this is not part of a critical performance loop,
otherwise, we would do things differently.
> Vincent Torri
>
> On Fri, Jul 24, 2020 at 5:02 AM David Turner wrote:
> >
> > A better answer is to actually get rid of strcpy() / strcat() /
> sprintf() b
ve you begun this work ? If yes, is it available so i can
> try it ?
>
> thank you
>
> Vincent Torri
>
From 63b49d6dd47df4f90cd08bc41e7ce9524dfe926d Mon Sep 17 00:00:00 2001
From: David Turner
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.
This
Le jeu. 23 juil. 2020 à 13:19, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > Here's a patch to add a .clang-format style file to the directory.
>
> Thanks. I've slightly improved it, but I think there is still room
> for more fixes.
Good, can you share your updated version? We may not get
rncat are in function `Cur_U_Line'.)
>
> Hmm. The answer to
>
>
> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice
>
> recommends to switch off the warning if the code does exactly ...
>
>
> Werner
>
>
From dc5
ething after a switch to a new build system
> IMHO.
>
>
> Werner
>
From 0cfacffe05ae6eeffe2df0d0663fa4666a8b6afc Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 6 Jul 2020 10:56:36 +0200
Subject: [build] Fix multi and C++ builds.
The following builds were failing due to pr
Le jeu. 10 févr. 2022 à 05:32, Alexei Podtelezhnikov a
écrit :
> Hi All,
>
> As Werner is working on improving the SBIX table support
> (https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/139),
> a topic of compressed images came up. Right now, FreeType depends on
> libpng to
go around might as well ask.
> >>
> >> If you know a better place to ask these, please reply and add them.
> >
> > Just a quick ping, plus adding -devel since it looks like this
> > hasn't made it to archives.
>
> Indeed, I haven't seen your orig
I have specific worries about what is being proposed here:
- First, the proposed merge requests adds a ton of conditional code
paths that are impossible to properly review now or even maintain over
time. Since there is no proper distinction in the source code between what
is supposed
301 - 395 of 395 matches
Mail list logo
