Re: serving compressed images

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 uncom

Re: Add support for FT_Face cloning

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 t

Re: freetype.org domain

ear up ownership, so while I 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. > &g

Re: Meson build, continued

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 to

Re: Meson build, continued

t : > 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 8dcb5c0789a8065947eb66d08ceae730b6afa

Re: compressed streams

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

Meson build, continued

Let me know what you think about 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

Re: cmake patch

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

Re: compressed streams

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

Re: about the meson build systel

h HAVE_UNISTD_H and HAVE_FCNTL_H added as compile-time macros instead. Le lun. 24 août 2020 à 23:27, David Turner a écrit : > > > Le lun. 24 août 2020 à 22:34, Werner LEMBERG a écrit : > >> >> Hello David, >> >> >> > - builds/meson/ftconfig.h.in: te

Re: about the meson build systel

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 build

Re: about the meson build systel

s out. Here's a new 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

Re: about the meson build systel

? > > 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: - m

Re: about the meson build systel

uild > system. Have 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 bu

Re: new compiler warnings in freetype 2.10.2 32-bit

ery 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

Re: [patch] Simplify ftconfig.h

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

Re: new compiler warnings in freetype 2.10.2 32-bit

e problematic calls of strncat 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 ... > > >

Re: [patch] Simplify ftconfig.h

r our API documentation > can be built correctly. Additionally, 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_UNUSE

Re: [patch] Simplify ftconfig.h

x27;t invest too much > time here. This is something 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++ bu

Re: [patch] Simplify ftconfig.h

x27;ve fixed this meanwhile. So only two 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

Re: [patch] Simplify ftconfig.h

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

Re: [patch] Simplify ftconfig.h

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

Re: [patch] Simplify ftconfig.h

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 in

Re: I'm back

ession test suite before trying this. - David [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 co

Re: Overlap oversampling

mentations. Can you tell me how to actually test that the 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, >> >&

Re: [patch] Simplify ftconfig.h

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 sup

Re: [patch] Simplify ftconfig.h

eview 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 a

[patch] Simplify ftconfig.h

00:00 2001 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 u

Re: Overlap oversampling

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

Re: intel compiler support interest?

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 fo

Re: FT_Add_Module() and related functions

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 > https:/

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

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 w

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

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 in

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

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 instead

Re: GSOC Build tests

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 c

Re: GSOC Build tests

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&view=results > > this

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

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 re

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

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

Re: Logging Library-GSOC

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 yo

Re: Build system considerations

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 ca

Re: Logging Library-GSOC

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

[patch] Remove obsolete HAVE_STDINT_H probing

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

Patches to remove Jamfiles from freetype2 and freetype2-demos

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

Re: Logging Library-GSOC

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 FreeType

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

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 tha

Re: Build system considerations

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 tha

Re: Build system considerations

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 tha

Re: The TrueType rendering accuracy nightmare

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, > https://typedesign.netlify.

Re: The TrueType rendering accuracy nightmare

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

Re: Build system considerations

plementing hb_shape() can be really subtle. 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 customizati

Re: [freetype2-demos] Fix compiler warnings

ted the commit 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 Fro

[freetype2-demos] Fix compiler warnings

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

Re: [patches] Minor build system improvements

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 rul

Re: Build system considerations

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. > > S

Re: [Freetype-devel] Re: Build system considerations

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 >

Re: Build system considerations

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 has many

Re: Build system considerations

lbert > > > > > In the latest HarfBuzz release we added a meson build system. Over 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, >

[patches] Minor build system improvements

e current build 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 simple

Re: I'm back

atches/ (TODO) OpenBSD: only using freetype 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. 2

Re: I'm back

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 exactly?

Re: Compiler warnings when building utilities in ft2demos

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 conte

Build system considerations

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 consider

Re: I'm back

g them today. If 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 ha

I'm back

tter to do this in small incremental steps. Voila, I'd be happy to read your suggestions, Happy to be here. - David Turner

Re: [ft-devel] loss of precision in FT_Outline_Decompose

2013/7/16 Luiz Henrique de Figueiredo > 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 midpoint c

[ft-devel] (no subject)

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

Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome

2013/3/27 Werner LEMBERG > > > 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 coul

Re: [ft-devel] rounding errors when splitting

2013/2/24 Werner LEMBERG > > > I wanted to know your opinion on the rounding errors when splitting > > Bezier segments. [...] > > > > the alternative method would overflow one bit quicker for conic and > > 3 bits quicker for cubic segments. > > I think this enhanced precision is only worth the e

[ft-devel] Fix for C++ compilation

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

Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013/1/23 Werner LEMBERG > > 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); > de

Re: [ft-devel] ttsbit.c vs ttsbit0.c

2013/1/10 Behdad Esfahbod > It looks to me that David rewrote ttsbit, the code loading SFNT embedded > bitmaps, to be more "memory-optimized", but then had to keep the old code > for > when "old internals" config option is enabled. That means the > functionality > is duplicated now, in ttsbit.c

Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)

2012/1/17 Erik Dahlstrom > 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 various PI

Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)

Forgot to reply on-list, sorry 2012/2/1 David Turner > > > 2012/1/28 suzuki toshiya > >> >> 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 ex

Re: [ft-devel] FreeType License and patents

Hello Alexei, On Thu, Jan 19, 2012 at 4:08 AM, Alexei Podtelezhnikov wrote: > On Fri, Jan 13, 2012 at 2:13 PM, Werner LEMBERG wrote: > > 3. Grant of Patent License. > > > > > > Do freetype authors hold or have they filed for a patent? Don't you > need it first before granting any patent li

Re: [ft-devel] [ft] FreeType License and patents

On Tue, Jan 17, 2012 at 3:53 PM, Dave Crossland 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 licens

Re: [ft-devel] [ft] FreeType License and patents

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 of Apache-2 licensed code. On Fri, Jan 13, 2012 at 8:34 PM, Eric Rannaud wrote: >

Re: [ft-devel] Determining Upper Bound of memory consumption for a system using FT cache subsystem

utely correct estimates of all the bytes consumed is impossible. Hope this helps. - David Turner 2010/3/10 Maggy Anastasia > Dear FreeType Developers, > > I have a few questions regarding freetype memory consumption upper bound; I > am using Freetyper version 2.3.7 > > (1) sta

Re: [ft-devel] Improvement of ft_ansi_stream_io

Looks fine to me - David 2009/6/19 Werner LEMBERG > > 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, > >

Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.

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 > > >> > both FT_New_Memory, and FT_New_Library (functions called within > >> > FT_Init_FreeType) are allocating memory,

Re: [ft-devel] git

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. I

Re: [ft-devel] Regarding Position-Independent-Code, modules, etc..

2009/4/14 Dmitry Timoshkov > "Oran Agra" 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 code easier to maintain and c

Re: [ft-devel] Re: Git and ChangeLogs

2009/4/15 Werner LEMBERG > > > 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 gene

[ft-devel] Re: Git and ChangeLogs

HANGES.TXT, 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 > On Wed, Mar 25, 2009 at 03:37:13PM +0100, David Turner wrote: > > I also tried to apply your previous set of

[ft-devel] Regarding Position-Independent-Code, modules, etc..

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. M

[ft-devel] Regarding Position-Independent-Code, modules, etc..

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. M

Re: [ft-devel] Searching for an FT2 tester program

2009/4/5 Oran Agra > 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 version builds w

Re: [ft-devel] Searching for an FT2 tester program

2009/4/5 Oran Agra > Hi, > Here's what I wrote him regarding this request. > Please tell me if you still want me to move these to ftobjs.h? > > > > Arranging a set of patches where each of them is a meaningful unit of > changes takes a lot of w

Re: [ft-devel] Searching for an FT2 tester program

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

Re: [ft-devel] Searching for an FT2 tester program

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 schem

Re: [ft-devel] Searching for an FT2 tester program

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 t

Re: [ft-devel] A few problems i've found in the latest code from cvs

Ah ah, the error is the comma after the last pcursor declaration, it should be a semi-column. I applaud Werner's attempt to make the ft2demos code build with really really old compilers, but I wonder if this is needed :-) 2009/3/11 Oran Agra > Hi, > Regarding the compilation error in ft2demos, i

Re: [ft-devel] Why my memory is not been freed?

2009/3/7 Jun.Wang > > 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 FT_Done_Face(),

Re: ABI breakage in 2.3.8 (bad bad bad !!) -- FW: [ft-devel] Accessing FSType (Type 1 or CID)?

This is done, I'm preparing a message to send to freetype-announce. Werner, if you are overworked, I'd like to prepare the release myself. Are there specific steps I need to know to do that ? Thanks 2009/3/3 David Turner > It'd be nice if we could remove the 2.3.8 packages

Re: ABI breakage in 2.3.8 (bad bad bad !!) -- FW: [ft-devel] Accessing FSType (Type 1 or CID)?

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 > > > 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. > > >Werner

Re: [ft-devel] problems with CVS->git conversion

2009/3/3 Werner LEMBERG > > > 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 the fo

Re: [ft-devel] Problem cross-compiling freetype-2.3.8 for ARM

2009/2/25 Jean-Claude Repetto > 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, >

Re: ABI breakage in 2.3.8 (bad bad bad !!) -- FW: [ft-devel] Accessing FSType (Type 1 or CID)?

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

Re: [ft-devel] problems with CVS->git conversion

Hi Werner, 2009/3/3 Werner LEMBERG > > the `empty log message' problem in the conversion from CVS to git > still bites me. It is far more trickier than expected :-( > > The steps I've suggested in a previous mail (using parsecvs, then `git > format-patch' & `git am') works in principle. Howeve

[ft-devel] ABI breakage in 2.3.8 (bad bad bad !!)

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 include/f

Re: [ft-devel] Problem cross-compiling freetype-2.3.8 for ARM

This has been recently fixed in the CVS repository, see this for details: http://git.freetype.org/?p=freetype2.git;a=commitdiff;h=7bb1c4ce1221edb3ed900666fee3eae790255820 2009/2/25 Jean-Claude REPETTO > Hello, > > I am trying to compile freetype-2.3.8 for ARM. I am using the toolchain > availabl

  1   2   3   4   >