Re: Gitlab-ci? Re: Another c++ compile failure...

[Vincent Torri]

hello

I don't understand the interest of compiling Freetype with a c++
compiler. The source code is written in C. By convention, CC is
usually for C compilers. To compile C++ code, CXX env var should be
used, not CC

best regards

Vincent Torri

On Thu, May 23, 2024 at 3:16 AM Alexei Podtelezhnikov
 wrote:
>
> Hi Hin-Tak,
>
> These macros were never used before. I fixed them. Now I think they
> made the code less readable and I might revert to the old code.
>
> Thanks,
> Alexei
>
> On Wed, May 22, 2024 at 6:12 PM Hin-Tak Leung
>  wrote:
> >
> > Actually it might be a good idea to stick CC=g++/clang++ as an additional 
> > job in .gitlab-ci.yml ? I mean, it already does gcc and clang.
> >
> > On Wednesday 22 May 2024 at 23:05:47 BST, Hin-Tak Leung 
> >  wrote:
> >
> >
> > Should be obvious - needs casting from "void *" to "unsigned char *" and 
> > etc...
> >
> > Shouldn't be too hard to see yourself with CC=c++ when building...
> >
> > In file included from 
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:22:
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgload.c:421:14:
> >  error: assigning to 'FT_Byte *' (aka 'unsigned char *') from incompatible 
> > type 'FT_Pointer' (aka 'void *')
> >   421 | if ( FT_DUP( exec->glyphIns, p, n_ins ) )
> >   |  ^~
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29:
> >  note: expanded from macro 'FT_DUP'
> >   378 |   FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) )
> >   |   ~~^~
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19:
> >  note: expanded from macro 'FT_MEM_DUP'
> >   375 |   (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), 
> >  )
> >   |   ^
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38:
> >  note: expanded from macro 'FT_MEM_SET_ERROR'
> >   231 | #define FT_MEM_SET_ERROR( cond )  ( (cond), error != 0 )
> >   |  ^~~~
> > In file included from 
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:23:
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgxvar.c:2718:12:
> >  error: assigning to 'FT_MM_Var *' (aka 'FT_MM_Var_ *') from incompatible 
> > type 'FT_Pointer' (aka 'void *')
> >  2718 |   if ( FT_DUP( mmvar, ttface->blend->mmvar, 
> > ttface->blend->mmvar_len ) )
> >   |
> > ^~~
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29:
> >  note: expanded from macro 'FT_DUP'
> >   378 |   FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) )
> >   |   ~~^~
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19:
> >  note: expanded from macro 'FT_MEM_DUP'
> >   375 |   (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), 
> >  )
> >   |   ^
> > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38:
> >  note: expanded from macro 'FT_MEM_SET_ERROR'
> >   231 | #define FT_MEM_SET_ERROR( cond )  ( (cond), error != 0 )
> >   |  ^~~~
> > 2 errors generated.
> > make: *** 
> > [/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/rules.mk:60:
> >  /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/objs/truetype.lo] 
> > Error 1
> > /__w/freetype2-demos-skia/freetype2-demos-skia
> > Error: Process completed with exit code 1.
>
>
>
> --
> Alexei A. Podtelezhnikov, PhD
>

Re: Implementing Skia OT-SVG hook bridge in ftinspect?

[Vincent Torri]

Hello

I would download Skia in a subdir (get latest tga) and write a meson
file with only what you need. I've already done that with Angle

before a freetype release checkout if a newer tag is out

On Wed, Sep 27, 2023 at 3:45 AM Charlie Jiang  wrote:
>
> Hi Hin-Tak, Werner and other folks,
>
> The recent posts from Hin-Tak provided us promising insights in
> implementing OT-SVG hook bridges in calling programs. I wonder if the
> current status of Skia hook is approriate for being incorporating into
> ftinspect. My considerations are:
>
> - Maturity of bridge code (namely, skia-port.[ch]): Are they performing
> well enough for a (experimental) integration? Do they work stably across
> Skia versions? I'm seeing different patches for different Skia versions;
>
> - Building Skia: Skia is built using tools (e.g. gn) completely
> different from what we're using for building ftinspect (CMake and
> Meson). I plan to not directly include the commands to build Skia into
> the ftinspect build system, but to ask user to provide Skia library
> paths. However, I'm concerned that Skia depends on (possibly another
> build of) freetype, which may cause conflict. Maybe Hin-Tak have some
> tips on handling this correctly?
>
> If done, I plan to flag this feature as experimental and optional
> (default disabled, enable in build system). However, I may lack the
> resources and experise to test the code thoroughly, so I wonder if
> Hin-Tak could help.
>
> BTW @Hin-Tak, The Qt6 support for ftinspect has almost completely not
> been worked on, I just wrote the conditional compilation (specifically,
> code about `QTextCodec`) because I learnt that `QTextCodec` was
> deprecated in Qt6, and that's the only part I've considered about Qt6.
> Therefore, further work is definitely required to ensure the whole
> program works on Qt6. Sorry for the confusion.
>
> Best regards,
> Charlie Jiang
>

request: metafont module

[Vincent Torri]

Hello

i've recently found this doc, published in 2019, about a METAFONT
module for Freetype :

https://www.tug.org/TUGboat/tb40-2/tb125choi-freetype2.pdf

also found this one : (must be subscribed to springer or research
gate, i have the pdf as I am a member of an academic institution) :

https://www.researchgate.net/publication/342022857_Rendering_high-quality_PK_bitmap_font_in_Linux_environment

is a metafont, GF and PK driver in Freetype been ever considered ?

Vincent

Re: rsvg vs skia comparison (the actual skia based ft2-demo ot-svg renderer hook code diff

[Vincent Torri]

On Mon, Jul 17, 2023 at 6:02 PM Hin-Tak Leung
 wrote:
>
> Missing API - same missingness as Skia's SVG parser before m103, as far as I 
> can see. (Or maybe I didn't look thorough enough :-)).
>
> Interesting to have another svg library, I guess. Associated with tizen so 
> probably backed by Samsung, and the non-google/apple mobile industry.

yes, it's for tizen. I know the guys. They also worked for the EFL.
It's crossplatform (i compile it regularly on Windows)

Vincent Torri

Re: rsvg vs skia comparison (the actual skia based ft2-demo ot-svg renderer hook code diff

[Vincent Torri]

Hey

Have you looked at ThorVG ?

https://github.com/thorvg/thorvg

Vincent


On Sun, Jul 16, 2023 at 7:49 PM Werner LEMBERG  wrote:

>
> > 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
> >
> > FT_Load_Glyph_Extended(face, glyph_id, flags) {
> >if (glyph_id not COLRv1)
> >   return FT_Load_Glyph(); /* pass it on */
> >
> >... do stuff and fill in a color bitmap and it's size/offset..
> > }
>
> This might work in the demo programs, yes.
>
>
> Werner
>
>

Re: Need help compiling freetype with debug output enabled

[Vincent Torri]

On Sun, May 21, 2023 at 6:21 AM Werner LEMBERG  wrote:
>
>
> > I am trying to look at the trace output using the FT_Trace_Set_Level
> > function.  I read that FT_DEBUG_LOGGING macro must be set for this
> > to work, so I tried doing this by passing:
> > -Dc_args='-D FT_DEBUG_LOGGING'
> > to meson setup.
>
> Alas, support for `FT_DEBUG_LOGGING` is not implemented in Meson.  You
> are very welcome to submit a Merge Request that adds it :-)

meson honors CPPFLAGS. try:

CPPFLAGS=-DFT_DEBUG_LOGGING' meson setup builddir

(or use export)

Vincent Torri

Re: Getting Involved With Freetype

[Vincent Torri]

On Fri, Mar 10, 2023 at 6:51 AM James Hu  wrote:
>
> Hi,
> I do have some past experience with LaTeX, but entirely from a user 
> perspective - I have no experience with LaTeX fonts or underlying rendering 
> techniques.
>
> I did some research and found a blog post by Parth about the status of his 
> GSoC project. It seems that Parth finished the TFM, PK, and GK font 
> rendering, but was unable to complete the VFLib portion. Since the VFLib 
> portion of the project was marked as difficult, I don't believe I am ready to 
> tackle that challenge yet. In the meantime, I've been reading through the 
> rest of the FreeType docs on font rendering/hinting and have become 
> interested in the auto-hinter project. I'll be sure to follow up if I believe 
> the project is suitable for me.

just FYI : dvi2ppm (http://www.linuxcertif.com/man/1/dvi2ppm/) uses
dvilib and vflib. So you have here another example of usage of vflib.
Maybe this could help

Vincent Torri

> Sincerely,
> James Hu
>
> On Thu, Mar 9, 2023 at 3:14 PM Werner LEMBERG  wrote:
>>
>>
>> Sorry for the late response.
>>
>> > Over the past few days I was successfully able to clone/make both
>> > the freetype and freetype-demo libraries.  I've also read through
>> > the documentation on the site and feel I have a rudimentary
>> > understanding of fonts, glyphs, and other font rendering concepts.
>> > However, I don't feel ready to tackle any of the issues linked here.
>> > I do have experience with C, but it was relatively basic compared to
>> > what I've been looking at in the freetype repo.  In other words, I
>> > haven't worked with codebases this large or complex.  Would this
>> > present a major problem if I want to get involved with FreeType?  In
>> > other words, is there room for learning more about C and font
>> > rendering as I go?
>>
>> This is hard to say.  A good foundation in writing C code is probably
>> a necessity.  On the other hand, I consider improving your knowledge
>> in font rendering as part of the project.
>>
>> > Currently, I am most interested in the VFLib.
>>
>> Good.  Do you have any experience with (classical) TeX or LaTeX?
>>
>> > From my understanding, TFM stores font information, while the actual
>> > glyphs are stored in PK/GF as bitmaps/raster formats.
>>
>> Correct.
>>
>> > So is the overall goal of the VFLib project then to add TFM and
>> > PK/GF rendering capability directly into FreeType? (Ideally without
>> > using VFLib as a dependency)
>>
>> Yes.  FreeType would load PK or GF fonts, and the TFM data would be
>> 'attached', similar to the already existing mechanism to attach
>> AFM/PFM files to Type 1 fonts.
>>
>> > In addition, is it possible to check if the original GSOC 2018
>> > contributor, Parth Wazurkar, is still following the mailing list (it
>> > seems that email addresses are hidden on the mailing list)?
>>
>> I don't think so; otherwise he would probably have already answered.
>>
>> > If not, is there an alternate way to get into contact with them?
>>
>> Try .
>>
>>
>> Werner

Re: Qt5 versions in Ubuntu (Re: [Freetype-devel] Re: compilation of `ftinspect` fails)

[Vincent Torri]

hello

you should have used the EFL toolkit

 * C code
 * no problem with versions
 * separate C logic from UI (with one C code, you can have several UI,
like one for desktop, one for smartphone, etc...)

examples of EFL usage:
https://www.calaos.fr/download/misc/videos/calaos_04.ogv
http://www.rasterman.com/files/wp2.avi

but i don't think you will switch to the EFL :-)

regards

Vincent Torri


On Thu, Jul 28, 2022 at 8:02 AM suzuki toshiya
 wrote:
>
> Dear Werner, Charlie,
>
> In the case of Ubuntu, the versions of Qt are following.
>
> 18.04LTS (until April 2023): 5.9.5
> 20.04LTS (until April 2025): 5.12.8
> 21.10: 5.12.2
> 22.04LTS (until April 2027): 5.15.3
> Kinetic:  5.15.4
>
> I think supporting Qt 5.12 is helpful for lazy late adapters like me :-),
> but Charlie, please don't spend much time for them. As Werner comments,
> notification "your Qt is too old to build ftinspect" is sufficient goal
> for GSoC project.
>
> Regards,
> mpsuzuki
>
> On 2022/07/28 14:27, Werner LEMBERG wrote:
> >
> >>> Please add code to the meson and cmake build files that checks whether
> >>> the Qt version you need is installed.  If not, make them exit with an
> >>> error.  After you are done you can revert the work-around for older
> >>> Qt5 versions :-)
> >>
> >> OK, I've push the reverted version with check conditions in CMake and
> >> Meson scripts to the `gsoc-2022-chariri-3` branch (open a new branch
> >> in case you want to still use Qt 5.12 to checkout my progress).
> >
> > I've updated my openSUSE box, and I'm now using Qt 5.15.2.  However, I
> > still ask you to adjust the meson and cmake build files to request a
> > proper minimum version for Qt (this is not urgent, though).
> >
> >> Let me know if the old `gsoc-2022-chariri-2` (containing the 5.12
> >> workaround) is no longer needed.
> >
> > I don't need it, thanks.
> >
> >
> >  Werner
> >
>

Re: GSoC 2022: Alternative Rendering Engines

[Vincent Torri]

On Thu, Apr 14, 2022 at 4:23 AM Alexei Podtelezhnikov
 wrote:
>
> On Tue, Apr 12, 2022 at 9:57 AM Matsumura, George  wrote:
> > The blog post mentions "a large constant factor because it’s doing
> > complicated exact-area calculations for each pixel" as a performance
> > impediment when drawing into the accumulation buffer. If one were
> > willing to settle for fewer gray levels in the resulting image, could
> > something like multisampling be used to eliminate the need for these
> > area calculations entirely, especially given that SIMD is already being
> > used to exploit parallelism? I'm sure there's a reason why this isn't
> > done, but if someone could enlighten me as to exactly why I would highly
> > appreciate it.
>
> There are basically two approaches to rendering: Windows does
> multisampling, the rest of the world integrates. I do not want to make
> any claims about the speed of the either approach. There are claims
> out there that other renderers beat FreeType using parallelism by the
> expected factor equal to the number of CPUs, maybe more, maybe less.So
> we want to see if we can borrow some of those approaches. The main
> reason why FreeType is very careful about adopting alternative
> approaches is ultra-portability of FreeType to pretty much anything
> under the Sun because of pure C89 or C99. The performance non-parallel
> rendering is not bad. Also, you can do parallelism on levels above
> FreeType and outside of its control.

A note about threads on Window: even if the mingw-w64 project provides
a pthread implementation (called winpthread) which could be useful for
multiplatform code, it is known that winpthread is a bit slower than
native Win32 threads. So I would avoid winpthread on Windows.

Vincent Torri

Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"

[Vincent Torri]

On Tue, Apr 5, 2022 at 12:44 PM Charlie Jiang  wrote:
>
> Hello Werner,
>
> Thanks for your quick reply!
>
> > However, a
> > quick search in the internet gives me
> >
> >https://gitlab.gnome.org/GNOME/librsvg/-/tree/main/win32
> >
> > Does this help?  Otherwise, compiling the demo programs without
> > 'librsvg' is fully sufficient for improving the demo programs.
>
> Unfortunately, as the page indicates, Gdk-Pixbuf is required to build
> librsvg from stratch, which is considerably hard (it has even more
> indirect dependencies). However eventually I will sort it out (maybe
> after the whole improvement is completed).

what about looking at ThorVG (https://www.thorvg.org/) ?

Vincent Torri

Re: Update FreeType's build systems (GSoC Project Idea #1)

[Vincent Torri]

On Mon, Mar 28, 2022 at 2:49 PM Afrid Hussain  wrote:
>
> Hello Werner and Freetype Development Team,
> As you said, I have tried installing the freetype using all the three 
> methods. Here is the result (✅ means worked)
> ==> For Ubuntu Linux
> ✅ Classical Method (./autogen.sh && ./configure && make && make install)
> ✅ Cmake
> ✅ Meson (requred version for meson is >=55, Meson version is not updated in 
> ubuntu repositories, but got from official meson github repo)
>
> ===> For MacOS
> ✅ Classical Method
> ✅ Cmake
> ✅ Meson
>
> ===> For windows
> Coming to windows I was having trouble building on it. I need some guidance 
> to build freetype library on windows. Can anybody help me?

for an environment similar to linux : install MSYS2 (msys2.org, follow
all the steps there) and you have a posix-like terminal, with packages
installed with a windows port of pacman. Then compile like on linux

Vincent Torri

Re: FreeType CI build fails on Windows

[Vincent Torri]

On Tue, Jan 11, 2022 at 8:05 AM Werner LEMBERG  wrote:
>
>
> Hello Vincent,
>
>
> > do you know if Mark would accept to add meson as build system ?
>
> Who is Mark?

Mark Adler. If meson is added in zlib, that would simplify the process

Vincent Torri


Vincent Torri

> And for the Windows CI build we use meson...
>
>
> Werner

Re: Projects for GSoC 2021

[Vincent Torri]

hello


On Fri, Jan 15, 2021 at 10:52 AM Werner LEMBERG  wrote:
>
>
> 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 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 ?

Vincent Torri

Warning with the latest harfbuzz version

[Vincent Torri]

Hello

using the latest harfbuzz version, I have this warning :

In file included from ../src/autofit/autofit.c:33:
../src/autofit/afshaper.c: In function 'af_shaper_get_coverage':
../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]
  135 | hb_ot_tags_from_script( script,
  | ^~
In file included from
E:/Documents/programmes_x64/msys2/opt/ewpi_64/include/harfbuzz/hb-ot.h:34,
 from ../src/autofit/afshaper.h:29,
 from ../src/autofit/afglobal.h:26,
 from ../src/autofit/afcjk.c:28,
 from ../src/autofit/autofit.c:23:
E:/Documents/programmes_x64/msys2/opt/ewpi_64/include/harfbuzz/hb-ot-deprecated.h:63:1:
note: declared here
   63 | hb_ot_tags_from_script (hb_script_t  script,
  | ^~

regards

Vincent Torri

Re: meson build system

[Vincent Torri]

On Tue, Jan 5, 2021 at 7:24 PM Werner LEMBERG  wrote:
>
>
> > 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 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 release ?

also :

https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/meson.build#n267

missing test for png

and what about using
https://mesonbuild.com/Reference-manual.html#summary at the end of
meson.build ?

Vincent Torri

Re: meson build system

[Vincent Torri]

On Tue, Jan 5, 2021 at 3:59 PM Werner LEMBERG  wrote:
>
> > 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 that, omitting the `--prefix` and `--cross-file` lines.
>
> > ninja $verbninja install > ../../make.log 2>&1
>
> I tried that, too, and for me everything works as expected.
>
> > In ftopion.h :
> >
> > #define FT_CONFIG_OPTION_USE_HARFBUZZ
> >
> > which seems wrong
>
> I don't get this.  For me, the generated file `builddir/ftoption.h`
> has HarfBuzz properly commented out.

ok, there is something odd, indeed :

with a freetype tarball, without launching meson, ' find . -name
ftoption.h' gives :

./devel/ftoption.h
./include/freetype/config/ftoption.h

first one : hb not commented
second one, hb commented

but when I launch meson out of tree (in builddir/) there is a third
(!) ftoption.h, the one generated by meson


> Is it possible that another `ftoption.h` file is present in your
> include path that takes precedence for whatever reason (e.g.,
> cross-compiling)?  Admittedly, I have never tried cross compilation
> with meson, so there might be bugs lurking around...

So I think you are right. ftoption.h in my builddir/ sub dir is taking
precedence

Vincent Torri



>
> Werner

Re: meson build system

[Vincent Torri]

On Tue, Jan 5, 2021 at 3:15 PM Alexei Podtelezhnikov  wrote:
>
> On Tue, Jan 5, 2021 at 8:38 AM Vincent Torri  wrote:
> > In ftopion.h :
> >
> > #define FT_CONFIG_OPTION_USE_HARFBUZZ
> >
> > which seems wrong
>
> Another person is bitten by the command line that 'sed' ftoption.h one
> way only... Neither Cmake, nor mason bother to 'sed' it back if the
> option is disabled.
> It is better to use -D than be lazy about editing files.

I use -D to disable hb. See my script. The meson output says that hb
is disabled. but ftoption.h still mentions that hb is used. And

I think that there is a problem with meson.build :

no test is done line 270, especially :

ftoption_command += ['--enable=FT_CONFIG_OPTION_USE_HARFBUZZ']

is set unconditionally

Vincent Torri

meson build system

[Vincent Torri]

Hello

i try to compile freetype 2.10.4 with harfbuzz support using meson, so
i compile in that order:
1) freetype without hb
2) hb with ft
3) ft with hb

compilation fails at step 1)

-
configuration :

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

ninja $verbninja install > ../../make.log 2>&1

-

meson output :

Found pkg-config:
E:\Documents\programmes_x64\msys2\opt\ewpi2_64\bin/pkg-config.EXE
(1.7.3)
Run-time dependency zlib found: YES 1.2.11
Library bz2 found: YES
Run-time dependency libpng found: YES 1.6.37
Dependency harfbuzz skipped: feature harfbuzz disabled
Found CMake: E:\Documents\programmes_x64\msys2\mingw64\bin/cmake.EXE (3.19.1)
Run-time dependency libbrotlidec found: NO (tried pkgconfig and cmake)
Compiler for C supports function attribute visibility:hidden: YES
Build targets in project: 4

Option default_library is: shared [default: both]
Found ninja-1.10.2 at E:\Documents\programmes_x64\msys2\mingw64\bin/ninja.EXE

-

compilation :

[1/44] Generating ftmodule.h with a custom command
[2/44] Generating ftoption.h with a custom command
[3/44] Compiling C object libfreetype-6.dll.p/src_base_ftfstype.c.obj
[4/44] Compiling C object libfreetype-6.dll.p/src_base_ftcid.c.obj
[5/44] Compiling C object libfreetype-6.dll.p/src_base_ftgxval.c.obj
[6/44] Compiling C object libfreetype-6.dll.p/src_base_ftbdf.c.obj
[7/44] Compiling C object libfreetype-6.dll.p/src_base_ftgasp.c.obj
[8/44] Compiling C object libfreetype-6.dll.p/src_base_ftbbox.c.obj
[9/44] Compiling C object libfreetype-6.dll.p/src_base_ftglyph.c.obj
[10/44] Compiling C object libfreetype-6.dll.p/src_psnames_psnames.c.obj
[11/44] Compiling C object libfreetype-6.dll.p/src_base_ftbitmap.c.obj
[12/44] Compiling C object libfreetype-6.dll.p/src_base_ftinit.c.obj
[13/44] Compiling C object libfreetype-6.dll.p/src_base_ftotval.c.obj
[14/44] Compiling C object libfreetype-6.dll.p/src_base_ftmm.c.obj
[15/44] Compiling C object libfreetype-6.dll.p/src_winfonts_winfnt.c.obj
[16/44] Compiling C object libfreetype-6.dll.p/src_type42_type42.c.obj
[17/44] Compiling C object libfreetype-6.dll.p/src_cid_type1cid.c.obj
[18/44] Compiling C object libfreetype-6.dll.p/src_pcf_pcf.c.obj
[19/44] Compiling C object libfreetype-6.dll.p/src_pfr_pfr.c.obj
[20/44] Compiling C object libfreetype-6.dll.p/src_autofit_autofit.c.obj

FAILED: libfreetype-6.dll.p/src_autofit_autofit.c.obj

"x86_64-w64-mingw32-gcc" "-Ilibfreetype-6.dll.p" "-I." "-I.."
"-I../include" 
"-IE:/Documents/programmes_x64/msys2/opt/ewpi2_64/include/libpng16"
"-IE:/Documents/programmes_x64/msys2/opt/ewpi2_64/include"
"-fdiagnostics-color=always" "-pipe" "-D_FILE_OFFSET_BITS=64" "-Wall"
"-Winvalid-pch" "-O3" "-D_WIN32_WINNT=0x0601" "-O2" "-march=x86-64"
"-DHAVE_UNISTD_H=1" "-DHAVE_FCNTL_H" "-DFT2_BUILD_LIBRARY=1"
"-DFT_CONFIG_OPTIONS_H=" "-fvisibility=hidden" -MD -MQ
libfreetype-6.dll.p/src_autofit_autofit.c.obj -MF
"libfreetype-6.dll.p/src_autofit_autofit.c.obj.d" -o
libfreetype-6.dll.p/src_autofit_autofit.c.obj "-c"
../src/autofit/autofit.c

In file included from ../src/autofit/afglobal.h:26,
 from ../src/autofit/afcjk.c:28,
 from ../src/autofit/autofit.c:23:
../src/autofit/afshaper.h:28:10: fatal error: hb.h: No such file or directory
   28 | #include 
  |  ^~
compilation terminated.

-

In ftopion.h :

#define FT_CONFIG_OPTION_USE_HARFBUZZ

which seems wrong

Vincent Torri

about libass stroker

[Vincent Torri]

hello

in libass Changelog, it is said that they implement a faster stroker
than freetype. I think that the code is done the 31st July 2017 :

https://github.com/libass/libass/commits/master?after=d149636f502f5774ae1a8fb4c554b122674393b2+209=master

what do you think of this ?

thank you

Vincent Torri

Re: Meson build, continued

[Vincent Torri]

Hello

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

don't you think that all those (source) files should be in src/ ? I
would find these more logical. Maybe in subdirectories of src (like
src/unix src/mac src/windows etc...)

thank you

Vincent Torri


On Fri, Sep 18, 2020 at 3:03 PM David Turner  wrote:
>
> 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).
> I'll let Werner choose which set is better :-)
>
>
>
> Le ven. 18 sept. 2020 à 14:54, Nikolaus Waxweiler  a 
> écrit :
>>>
>>> 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

Re: mmap and Windows

[Vincent Torri]

On Sat, Aug 29, 2020 at 7:45 PM Werner LEMBERG  wrote:
>
>
> > should I write a builds/win32/ftsystem.c ?
>
> I guess yes; it's probably the simplest solution.

ok, thank you

Vincent Torri

Re: mmap and Windows

[Vincent Torri]

On Sat, Aug 29, 2020 at 7:07 PM Behdad Esfahbod  wrote:
>
> Here's how HarfBuzz does it:
>
>  https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-blob.cc

thank you. hopefully, i already know how to create shared memory on Windows

regards

Vincent Torri

Re: mmap and Windows

[Vincent Torri]

On Sat, Aug 29, 2020 at 11:52 AM Werner LEMBERG  wrote:
>
>
> >> If this really makes a difference on Windows, and if you want to
> >> contribute such code, you are welcome to do so!
> >
> > I guess that mmap is useful with a font with a large size, right ?
> > if so, do you have a font to test with ?
>
> You want a very large font to play around?  I suggest to try
> `NotoSansCJK.ttc`, which is a 100MByte font:
>
>   https://github.com/googlefonts/noto-cjk/blob/master/NotoSansCJK.ttc.zip

thank you

should I write a builds/win32/ftsystem.c ?

Vincent Torri

Re: mmap and Windows

[Vincent Torri]

Werner

On Sat, Jul 25, 2020 at 12:37 PM Werner LEMBERG  wrote:
>
>
> Hello Vincent,
>
>
> > On Windows, there is no mmap, but there is shared memory support,
> > with CreateFileMapping and MapViewOfFile.
> >
> > If shared mem really improved loading of files on Unix, would you
> > consider adding shared mem support on Windows too ?
>
> If this really makes a difference on Windows, and if you want to
> contribute such code, you are welcome to do so!

I guess that mmap is useful with a font with a large size, right ? if
so, do you have a font to test with ?

thank you

Vincent Torri

Re: about the meson build systel

[Vincent Torri]

On Tue, Aug 25, 2020 at 5:55 AM Werner LEMBERG  wrote:

> BTW, how well does meson support cross compilation?

it does support cross-compilation a lot better than cmake

on Windows (though compilation fails because of mmap) :

$ ./configure.sh
The Meson build system
Version: 0.54.2
Source dir: E:/Documents/programmes_x64/msys2/home/vtorri/gitroot_64/freetype2
Build dir: 
E:/Documents/programmes_x64/msys2/home/vtorri/gitroot_64/freetype2/builddir
Build type: cross build
Using 'PKG_CONFIG_PATH' from environment with value:
'E:\\Documents\\programmes_x64\\msys2\\opt\\efl_64\\lib\\pkgconfig;E:\\Documents\\programmes_x64\\msys2\\opt\\ewpi_64\\lib\\pkgconfig'
Project name: freetype2
Project version: undefined
C compiler for the build machine: cc (gcc 10.1.0 "cc (Rev2, Built by
MSYS2 project) 10.1.0")
C linker for the build machine: cc ld.bfd 2.34
Using 'CFLAGS' from environment with value: '-g3 -ggdb3 -Og -pipe'
Using 'LDFLAGS' from environment with value:
'-LE:/Documents/programmes_x64/msys2/opt/ewpi_64/lib'
C compiler for the host machine: x86_64-w64-mingw32-gcc (gcc 10.1.0
"x86_64-w64-mingw32-gcc (Rev2, Built by MSYS2 project) 10.1.0")
C linker for the host machine: x86_64-w64-mingw32-gcc ld.bfd 2.34
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86_64
Host machine cpu: x86_64
Target machine cpu family: x86_64
Target machine cpu: x86_64
Program python3 found: YES
(e:/documents/programmes_x64/msys2/mingw64/bin/python.exe)
Has header "unistd.h" : YES
Has header "fcntl.h" : YES
Found pkg-config:
E:\Documents\programmes_x64\msys2\opt\ewpi_64\bin/pkg-config.EXE
(0.29.2)
Using 'PKG_CONFIG_PATH' from environment with value:
'E:\\Documents\\programmes_x64\\msys2\\opt\\efl_64\\lib\\pkgconfig;E:\\Documents\\programmes_x64\\msys2\\opt\\ewpi_64\\lib\\pkgconfig'
Run-time dependency zlib found: YES 1.2.11
Library bz2 found: YES
Using 'PKG_CONFIG_PATH' from environment with value:
'E:\\Documents\\programmes_x64\\msys2\\opt\\efl_64\\lib\\pkgconfig;E:\\Documents\\programmes_x64\\msys2\\opt\\ewpi_64\\lib\\pkgconfig'
Run-time dependency libpng found: YES 1.6.37
Using 'PKG_CONFIG_PATH' from environment with value:
'E:\\Documents\\programmes_x64\\msys2\\opt\\efl_64\\lib\\pkgconfig;E:\\Documents\\programmes_x64\\msys2\\opt\\ewpi_64\\lib\\pkgconfig'
Run-time dependency harfbuzz found: YES 2.6.8
Found CMake: E:\Documents\programmes_x64\msys2\mingw64\bin/cmake.EXE (3.17.2)
Run-time dependency libbrotlidec found: NO (tried pkgconfig and cmake)
Compiler for C supports function attribute visibility:hidden: YES
Build targets in project: 4

Option default_library is: shared [default: both]
Found ninja.EXE-1.10.0 at
E:\Documents\programmes_x64\msys2\mingw64\bin/ninja.EXE
[1/43] Generating ftoption.h with a custom command
[2/43] Generating ftmodule.h with a custom command
[3/43] Compiling C object freetype@sha/src_winfonts_winfnt.c.obj
[4/43] Compiling C object freetype@sha/src_type42_type42.c.obj
[5/43] Compiling C object freetype@sha/src_cid_type1cid.c.obj
[6/43] Compiling C object freetype@sha/src_pfr_pfr.c.obj
[7/43] Compiling C object freetype@sha/src_pcf_pcf.c.obj
[8/43] Compiling C object freetype@sha/src_type1_type1.c.obj
[9/43] Compiling C object freetype@sha/src_cff_cff.c.obj
[10/43] Compiling C object freetype@sha/src_bdf_bdf.c.obj
[11/43] Compiling C object freetype@sha/src_raster_raster.c.obj
[12/43] Compiling C object freetype@sha/src_smooth_smooth.c.obj
[13/43] Compiling C object freetype@sha/src_pshinter_pshinter.c.obj
[14/43] Compiling C object freetype@sha/src_lzw_ftlzw.c.obj
[15/43] Compiling C object freetype@sha/src_cache_ftcache.c.obj
[16/43] Compiling C object freetype@sha/src_base_ftbdf.c.obj
[17/43] Compiling C object freetype@sha/src_base_ftbbox.c.obj
[18/43] Compiling C object freetype@sha/src_base_ftbase.c.obj
[19/43] Compiling C object freetype@sha/src_psnames_psnames.c.obj
[20/43] Compiling C object freetype@sha/src_base_ftpatent.c.obj
[21/43] Compiling C object freetype@sha/src_base_ftpfr.c.obj
[22/43] Compiling C object freetype@sha/src_base_ftsynth.c.obj
[23/43] Compiling C object freetype@sha/src_base_ftwinfnt.c.obj
[24/43] Compiling C object freetype@sha/src_base_fttype1.c.obj
[25/43] Compiling C object freetype@sha/builds_windows_ftdebug.c.obj
[26/43] Compiling C object freetype@sha/builds_unix_ftsystem.c.obj
FAILED: freetype@sha/builds_unix_ftsystem.c.obj
x86_64-w64-mingw32-gcc @freetype@sha/builds_unix_ftsystem.c.obj.rsp
../builds/unix/ftsystem.c:33:10: fatal error: sys/mman.h: No such file
or directory
   33 | #include 
  |  ^~~~
compilation terminated.
[27/43] Compiling C object freetype@sha/src_base_ftstroke.c.obj
[28/43] Compiling C object freetype@sha/src_autofit_autofit.c.obj
In file included from ../src/autofit/autofit.c:33:
../src/autofit/afshaper.c: In function 'af_shaper_get_coverage':
../src/autofit/afshaper.c:135:5: warning: 'hb_ot_tags_from_script' is
deprecated: Use 'hb_ot_tags_from_script_and_language' instead

Re: about the meson build systel

[Vincent Torri]

Hello David

any news on the meson build system ?

regards

Vincent Torri

Re: Logging Library-GSOC

[Vincent Torri]

Hello,

On Tue, Aug 18, 2020 at 1:03 PM Priyesh kumar  wrote:
>
> Hi Werner,
> I was trying to compile FreeType on Windows using Cygwin and I was
> getting the following error while executing `sh autogen.sh' command even
> though I have installed the required packages from the Cygwin package 
> installer:
> --
>
> Can't locate Automake/Config.pm in @INC (you may need to install the 
> Automake::Config module) (@INC contains: /usr/share/automake-1.16 
> /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_p
>
> erl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl 
> /usr/share/perl5/core_perl) at /c/cygwin/bin/aclocal-1.16 line 36.
>
> --
> The commands like `make devel;make' which do not use `sh autogen.sh' script 
> are executing fine...
> I have searched about this error online but didn't get any helpful answers.
> Could you please take a look at it as it the only remaining platform to test 
> the changes.

If you want I can tell you how I compile freetype on Windows using
MSYS2 and mingw-w64 (or even on linux with cross compilation)

regards

Vincent Torri

Re: Migrate to github

[Vincent Torri]

On Mon, Aug 17, 2020 at 10:54 PM Anurag Thakur
 wrote:
>
> (I searched the mailing list archives, but could not find anything related to 
> this topic, so here goes: )
>
> Freetype is an essential library, generating what billions of eyes see 
> worldwide everyday, this means that any improvement made here would have a 
> huge impact all around the world. It also means that it is an attractive 
> attack vector for hackers, so the code must be bug free. I believe that the 
> current development setup is suboptimal for a library this important and 
> would like to suggest some improvements.
>
> #1: Migrate development over to github:
> Host the git repo on GitHub, use the GitHub issues and PR tracker instead of 
> GNU Savannah and e-mail
>
> Benefits:
> 1. Makes contribution easier:
> GitHub is the most popular code hosting platform used by millions of 
> projects, and as a result, most open-source developers already know how to 
> use it, reducing the need to learn new tooling as compared to GNU Savannah 
> and email which are much less common.
>
> 2. Visibility:
> It is much easier for a curious developer to navigate a GitHub repository 
> than to clone the repo and scour mailing lists looking for patches and code 
> reviews.
>
> 3. Easier for newbies :
> GitHub has *excellent* documentation about almost everything related to git 
> and GitHub, so new developers can get acquainted with version control easily 
> and quickly. It should also help GSOC students focus on their task instead of 
> navigating around obsolete UI.
>
> 4. Attracts younger developers:
> Stuff like hacktoberfest, the GitHub student developer pack ensures student 
> Dev's from around the world are on GitHub, effectively increasing potential 
> contributors. Even if not code, it makes it easier for developers to just 
> stop by and give suggestions in comments to PRs or issues.
>
> 5. Productivity features:
> GitHub has many features that make contributing to as well as reviewing code 
> easier. A beautiful interface, code review tools to suggest changes per 
> line!, a powerful issue tracker with labels, duplicates, milestones etc., 
> ability to create a wiki, managing releases, a mobile app so you can post 
> suggestions on open issues while laying on your bed!! etc.
>
> It even has a cli!!
>
>
> Overall, it is much easier to open issues on GitHub, send patches via PRs and 
> the tight integration means you can easily manage PRs that close specific 
> issues, milestones etc.
>
> #2: Join GitHub sponsors program:
> Text rendering has a profound impact on the user experience and there would 
> be many people willing to sponsor improvements to text rendering, 
> particularly linux folks, so it would be great if there was a way to channel 
> their support.
>
> Benefits:
> Increase incentive for developers to contribute to freetype, the money could 
> be used to hire part time devs, support website infrastructure, etc.
>
> #3: Use GitHub actions:
> GitHub actions can be used to setup a ci for freetype and make issue/PR 
> tracking easier with bots.
>
> Benefits:
> You can have all kinds of testing and fuzzing for all supported architectures 
> *for free* , this would be very helpful in improving code quality and 
> preventing regressions, and would ultimately lead to increase in robustness 
> of the library. It would also be helpful in automating workflows, for example 
> generating docs on a new release using GitHub actions with freetype-docwriter.
>
> Overall, the proposed changes would decrease friction for new developers, 
> increase the amount of contributions, incentivise development, and provide a 
> pleasent user interface for code contribution, review and management.
>
>
> There are many successful FOSS projects being developed on GitHub: opencv, 
> harfbuzz, curl, rust, vscode and thousands more, so it would be great to join 
> them.
>
> These are my points (I am a newbie too), I hope this post starts a discussion 
> and we are able to reach a conclusion.

you mentioned ci (there are several ones) but in addition : coverity
(static analysis) and coveralls (API coverage)

regards

Vincent Torri

Re: about the meson build systel

[Vincent Torri]

i have forgotten my meson command :


meson .. \
  --prefix=/opt/freetype \
  --libdir=lib \
  --buildtype=release \
  --cross-file ../cross_toolchain.txt \
  --default-library shared \
  -Dzlib=system \
  -Dbzip2=enabled\
  -Dpng=enabled \
  -Dharfbuzz=enabled

Vincent Torri

On Tue, Jul 28, 2020 at 7:26 AM Vincent Torri  wrote:
>
> On Tue, Jul 28, 2020 at 7:18 AM Vincent Torri  wrote:
> >
> > hello
> >
> > i've just tried. One thing : with bzip2 enabled, bz2.pc file is not
> > found. Is there any reason why you check it ? Officially (bzip2 1.0.8
> > here : https://sourceware.org/pub/bzip2/) there is no pc file
> > distributed with it.
> >
> > in the gitlab repo : https://gitlab.com/federicomenaquintero/bzip2,
> > it's bzip2.pc and not bz2.pc.
> >
> > maybe your linux distro is adding bz2.pc, but i don't think it's this
> > one that should be used in your meson.build (or try also bzip2 in
> > addition to bz2)
> >
>
> and compilation failed on Windows because of mmap does not exist on
> that platform.
>
> Maybe i'll add windows support for that.
>
> regards
>
> Vincent Torri

Re: about the meson build systel

[Vincent Torri]

On Tue, Jul 28, 2020 at 7:18 AM Vincent Torri  wrote:
>
> hello
>
> i've just tried. One thing : with bzip2 enabled, bz2.pc file is not
> found. Is there any reason why you check it ? Officially (bzip2 1.0.8
> here : https://sourceware.org/pub/bzip2/) there is no pc file
> distributed with it.
>
> in the gitlab repo : https://gitlab.com/federicomenaquintero/bzip2,
> it's bzip2.pc and not bz2.pc.
>
> maybe your linux distro is adding bz2.pc, but i don't think it's this
> one that should be used in your meson.build (or try also bzip2 in
> addition to bz2)
>

and compilation failed on Windows because of mmap does not exist on
that platform.

Maybe i'll add windows support for that.

regards

Vincent Torri

Re: about the meson build systel

[Vincent Torri]

hello

i've just tried. One thing : with bzip2 enabled, bz2.pc file is not
found. Is there any reason why you check it ? Officially (bzip2 1.0.8
here : https://sourceware.org/pub/bzip2/) there is no pc file
distributed with it.

in the gitlab repo : https://gitlab.com/federicomenaquintero/bzip2,
it's bzip2.pc and not bz2.pc.

maybe your linux distro is adding bz2.pc, but i don't think it's this
one that should be used in your meson.build (or try also bzip2 in
addition to bz2)

Vincent Torri

On Fri, Jul 24, 2020 at 2:24 PM David Turner  wrote:
>
> Hello Vincent,
>
> +cc freetype-devel
>
> Yes, I'm working on a local branch and I've sent an experimental patch to the 
> mailing list some weeks ago. Here's a more recent version rebased on top of 
> latest changes.
>
> There is a list of TODO() at the end of the meson.build file if you're 
> curious. Next step will be a proper "meson dist" that does the right thing. 
> Then introduce regression/unit-testing.
>
> Hope this helps,
>
> - David
>
>
> Le ven. 24 juil. 2020 à 06:26, Vincent Torri  a 
> écrit :
>>
>> hello
>>
>> if i'm not mistaken, you said that you would add meson as build
>> system. Have you begun this work ? If yes, is it available so i can
>> try it ?
>>
>> thank you
>>
>> Vincent Torri

Re: [ft2-demos][win32] Compiler Warnings

[Vincent Torri]

On Sun, Jul 26, 2020 at 5:52 PM Alexei Podtelezhnikov
 wrote:
>
>
> > As you said, I think some recent changes in the
> > config file is causing this, it's not there in my own
> > branch.
>
> DLL_EXPORT and DLL_IMPORT were dropped but still needed to handle static 
> libraries.

you're wrong.

to build a static library of freetype, FT_EXPORT MUST be set to nothing

Vincent torri

Re: [ft2-demos][win32] Compiler Warnings

[Vincent Torri]

On Sun, Jul 26, 2020 at 1:37 PM Alexei Podtelezhnikov
 wrote:
>
>
> > are you compiling static library of freetype ? If you compile a shared
> > library, you should not have this warning
>
> Yes, I am compiling a static library. And yes, they disappear when I compile
> a dynamic library.
>
>
> It should be controlled by DLL_EXPORT or lack thereof.

if DLL_EXPORT is not set, then FT_EXPORT is defined as
__attribute__(( visibility( "default" ) )), hence the warning

for a static lib, FT_EXPORT should be set to nothing. @Anuj Verma add
-DFT_EXPORT to CPPFLAGS at configure time

Vincent Torri

Re: [ft2-demos][win32] Compiler Warnings

[Vincent Torri]

On Sun, Jul 26, 2020 at 8:02 AM Anuj Verma  wrote:
>
> Hello,
>
> There are a couple of warnings in the win32 subsystem of the
> freetype-2 demos. I have attached a patch to fix those.
>
> I can also see a lot of the below warning
> ```
> src/base/ftsystem.c: In function 'FT_Stream_Open':
> src/base/ftsystem.c:282:3: warning: visibility attribute not supported in 
> this configuration; ignored [-Wattributes]
>}
>^
> ```
> I don't know what it is. I think it's specific to windows as I don't
> see this on linux. I'm using GCC 8.3.0 and GNU Make 4.3 to
> compile on windows.

it is related to FT_EXPORT in ftconfig.h

are you compiling static library of freetype ? If you compile a shared
library, you should not have this warning

Vincent Torri

Re: mmap and Windows

[Vincent Torri]

On Fri, Jul 24, 2020 at 5:01 PM Vincent Torri  wrote:
>
> On Fri, Jul 24, 2020 at 3:47 PM Nikolay Sivov  wrote:
> >
> >
> >
> > On Fri, Jul 24, 2020 at 4:25 PM Vincent Torri  
> > wrote:
> >>
> >> hello
> >>
> >> On Windows, there is no mmap, but there is shared memory support, with
> >> CreateFileMapping and MapViewOfFile.
> >>
> >> If shared mem really improved loading of files on Unix, would you
> >> consider adding shared mem support on Windows too ?
> >
> >
> > You can already do that on Windows by mapping it yourself and using 
> > FT_New_Memory_Face().
> >
>
> thank you
>
> Vincent Torri

but then, why adding mmap support in the buildsystem ? you can remove
it (simpler build system) and unix users will also mmap the file
themselves

Vincent Torri

Re: mmap and Windows

[Vincent Torri]

On Fri, Jul 24, 2020 at 3:47 PM Nikolay Sivov  wrote:
>
>
>
> On Fri, Jul 24, 2020 at 4:25 PM Vincent Torri  wrote:
>>
>> hello
>>
>> On Windows, there is no mmap, but there is shared memory support, with
>> CreateFileMapping and MapViewOfFile.
>>
>> If shared mem really improved loading of files on Unix, would you
>> consider adding shared mem support on Windows too ?
>
>
> You can already do that on Windows by mapping it yourself and using 
> FT_New_Memory_Face().
>

thank you

Vincent Torri

mmap and Windows

[Vincent Torri]

hello

On Windows, there is no mmap, but there is shared memory support, with
CreateFileMapping and MapViewOfFile.

If shared mem really improved loading of files on Unix, would you
consider adding shared mem support on Windows too ?

Vincent Torri

Re: new compiler warnings in freetype 2.10.2 32-bit

[Vincent Torri]

hello

some comments:

strcasecmp does not exist when compiling with Visual Studio (_stricmp
does though and is doing the same job). mingw-w64 use a #define for
that.Why not adding ft_strcasecmp like ft_strdup ?

note that using strdup with Visual Studio and passing
_CRT_NONSTDC_NO_DEPRECATE removes the warning.

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() 
> because there will always be compilers complaining about them.
>
> Here's a patch that does that for freetype2-demos, please take a look.
>
> Le jeu. 23 juil. 2020 à 13:16, Werner LEMBERG  a écrit :
>>
>> > There seems to be a new warning in 2.10.2 (compared to 2.10.1) when
>> > compiling for 32-bit: [...]
>>
>> Fixed in git, thanks.
>>
>> > Also have had a bunch of strncat related warning (probably gcc 1 specific, 
>> > or some compiler switch specific) in ft2-demos, for a while:
>> >
>> > ===
>> > inlined from 'RunIns' at src/ttdebug.c:2105:11:
>> > /usr/include/bits/string_fortified.h:136:10: warning:
>> > '__builtin___strncat_chk' output may be truncated copying 31 bytes
>> > from a string of length 31 [-Wstringop-truncation]
>>
>> (The 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 ...
>>
>>
>> Werner
>>

Re: Logging Library-GSOC

[Vincent Torri]

On Tue, Jul 21, 2020 at 6:27 AM Werner LEMBERG  wrote:
>
> > I have also updated the GitHub repo containing this example @ here
> > <https://github.com/Priyeshkkumar/FreeTypeExamples/tree/master/Windows/main>
>
> Alas, I don't use Windows so I can't check this.

install on your linux distro mingw-w64 toolchain to compile. Install
wine to test it

Vincent Torri

Re: Logging Library-GSOC

[Vincent Torri]

On Thu, Jul 16, 2020 at 9:51 AM Werner LEMBERG  wrote:
>
>
> >> *Have you set `FT2_DEBUG=any:7` in the environment?*
> >
> > Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with
> > OpenSans-Bold.ttf font.
>
> OK.
>
> > Also, I wanted to ask is this the right approach for profiling?
>
> I'm not an expert, sorry.  However, you might also try `valgrind
> --tool=cachegrind` (on GNU/Linux), which gives you detailed
> information on used CPU cycles including instruction and data caches.

also
valgrind --tool=callgrind + kcachegrind
and
oprofile could be useful

Vincen Torri

Re: Logging Library-GSOC

[Vincent Torri]

On Thu, Jul 16, 2020 at 8:30 AM Priyesh kumar  wrote:
>
> Hi,
> I was trying profiling on the example program given @ here.
> I have used the profiling tool inbuilt in Visual Studios but was unable to
> extract useful information from it, therefore I have tried a solution provided
> on Stack Overflow @ here . It basically uses `clock()` function to calculate 
> the
> running time of the program.

you can use query performance counter/frequency on Windows. I find
them a bit more accurate than anything else :

static LARGE_INTEGER freq;
static LARGE_INTEGER count1;
static LARGE_INTEGER count2;

you call once, at the beginning :
QueryPerformanceFrequency();

before the code you want to profile :

QueryPerformanceCounter();

at the end :

QueryPerformanceCounter();

number of seconds (as a double ):
double t = (double)((count2.QuadPart - count1.QuadPart) / freq.QuadPart);

regards

Vincent Torri




> So, basically I have used two variables of type time_t one at the start and 
> one
> at the end of the program marking the clock time at those steps and in the end
> the program prints the time taken by the program in seconds.
> For averaging out the result I have used a  for loop running the example code 
> 10
> times every time the code is is executed and at the end of each iteration it 
> writes the difference
> between the start time and end time to a file in seconds.
> I have attached the file in which it writes the results.
> I have tested the above solution on Ubuntu 20.04 LTS and got the following 
> results:
> No Debugging mode (avg time: 0.0164531 sec)
> Debugging using FT_DEBUG_LEVEL_TRACE mode (avg time: 0.0988122 sec)
> Debugging using FT_LOGGING mode (avg time: 0.0512144)
>
> Please look into this and provide feedback...
>
> Thanks,
> Priyesh
>
>
>
> On Tue, Jul 14, 2020 at 4:43 PM Priyesh kumar  wrote:
>>
>> Hi again,
>> I accidentally sent the previous mail
>> Continuing to the previous mail...
>> Also in the requirements, you told me to provide an option in MakeFile `make 
>> dist` to build the
>> external library. But dlg uses meson build system and I don't have any idea 
>> how to combine
>> meson build system with MakeFile, therefore could you provide me some 
>> references from where
>> I can read about doing this...
>>
>> Thanks,
>> Priyesh
>>
>> On Tue, Jul 14, 2020 at 4:37 PM Priyesh kumar  
>> wrote:
>>>
>>> Hi,
>>> I have added an option in `FT2_DEBUG` environment variable to 
>>> enable/disable the
>>> printing of FT_COMPONENT and Timestamp with a log message.
>>> The discussion related to dlg's features is still going, therefore in the 
>>> meantime I was
>>> thinking of extending the support on Windows.
>>> After looking: builds/windows/vc2010 , builds/windows/visualc and 
>>> builds/windows/visulace
>>> I can see that they all depend on builds/windows/ftdebug.c, therefore I 
>>> wanted to ask that
>>> Do I have to change only this file or there are some other files that I 
>>> have to take care of?
>>>
>>> Also in the requirements, you told me to provide an option in MakeFile 
>>> `make dist
>>>
>>> On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar  
>>> wrote:
>>>>
>>>> Hi armin,
>>>>
>>>> > This would print wrong-ish timestamps that couldn't really be used for 
>>>> > profiling (I mean, it could; you just have to know which timestamp 
>>>> > belongs to which message).  I would suggest to
>>>> > rather store a flag after reading `\n` and attach the timestamp to the 
>>>> > following message.
>>>>
>>>> I am also following this approach for printing timestamp and FT_COMPONENT.
>>>> Actually dlg uses a flag `dlg_features` in which different features like  
>>>> `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for 
>>>> FT_COMPONENTS) are summed up using binary OR operator.
>>>> For the first log message, these flags are kept ON so that timestamp and 
>>>> FT_COMPONENT values are printed, and for the next coming log messages the 
>>>> following logic is used:
>>>> If the current log message contains a `\n` in it then the flags will be 
>>>> toggled ON for the next coming log message assuming that it is end of a 
>>>> log message,
>>>> and if the current log message doesn't contain `\n` then these flags are 
>>>> toggled OFF for the next coming log message assuming that it is in 
>>>> continuation of current log message.
>>>&

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

[Vincent Torri]

On Wed, Jul 15, 2020 at 7:14 AM Werner LEMBERG  wrote:
>
>
> > I have added all the optimization modes to the module.
>
> Great, thanks!
>
> > By far the fastest method is to subdivide the curve into a number of
> > line segments.  [...]
>
> OK.  I'm glad that you took the time to implement the various
> algorithms so that we have such a comparison.
>
> > The major downside of the BB and subdivision methods is that they
> > require a considerable amount of memory usage (almost 3x of the size
> > of bitmap) because we need to keep a track of the distances and
> > signs of all the grid points.
>
> I don't think this is an issue.  For other rendering modes like LCD
> there are similar requirements, and platforms that are going to use
> SFDs certainly have plenty of memory.  It would be nice, however, if
> you can add this constraint to the documentation, and, if possible,
> also add a logging message that either predicts the necessary
> (approximate) amount of memory before the computation, and/or the
> actual memory use after generating an SFD.

what about adding the other two methods (or one of them) and decide
which one to choose with an option of the build system ? So one method
fast build consume more memory than other one which is slower.

Vincent Torri

Re: [patch] Simplify ftconfig.h

[Vincent Torri]

On Mon, Jul 6, 2020 at 11:58 AM Werner LEMBERG  wrote:
>
>
> > Werner, please don't commit something if you think there are still
> > problems in it, that's what code reviews are,
>
> Normally, I do that.  However, I've already invested a lot of time in
> writing ChangeLog entries...
>
> > See attached patch for a fix.
>
> Applied, thanks.  Note, however, that there are still issues with
> `make multi CC=c++` (I'm using g++ 7.5.0):
>
>   c++ -ansi -pedantic \
>   -Ifreetype2.compiled [...] \
>   freetype2/src/base/ftsystem.c
>   In file included from freetype2/include/freetype/config/ftconfig.h:45:0,
>from freetype2/src/base/ftsystem.c:29:
>   freetype2/include/freetype/config/public-macros.h:83:61: error:
> expected unqualified-id before string constant
>#define FT_EXPORT( x )  FT_PUBLIC_FUNCTION_ATTRIBUTE extern "C" x
>^
>   freetype2/include/freetype/fterrors.h:281:3: note:
> in expansion of macro ‘FT_EXPORT’
>  FT_EXPORT( const char* )
>  ^
>
> > Sorry about that.  We need a better way to automatically check our
> > builds.  [...]  I'll work on a proper rebuild-check script first
> > though...


github + travis-CI (and appveyor for windows) + coverity (static
analysis) + coverage (unit testing coverage)

i'm sure you can fork your repo in github. if you don't like github,
gitlab should offer the same kind of tools

Vincent Torri

Re: [patch] Simplify ftconfig.h

[Vincent Torri]

On Mon, Jul 6, 2020 at 11:17 AM Nikolaus Waxweiler 
wrote:

> Meson has a check-dist thing built in. Just saying 
>

and other nice things. I'm eagerly waiting for a meson build

Vincent Torri

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

[Vincent Torri]

On Sat, Jul 4, 2020 at 11:52 AM Werner LEMBERG  wrote:
>
>
> > I have created the demo program, it can be used to view raw SDF
> > without any bilinear filtering and there is no way to reconstruct
> > fonts from SDF because again it doesn't have bilinear filtering.  I
> > will add that soon.
>
> Thanks, will test soon.
>
> > There is a pretty weird issue that I ran into while testing the demo
> > on linux which doesn't happen on windows whatsoever. On linux
> > various computations give wrong output.  For example, division of
> > -328032 by 64 gives 1811934202, whereas it should be -5125.
> > Moreover FT_Vector_Length returns negative values even for small
> > vectors.  There is no overflow so what am I doing wrong?  (One of
> > the places it happens is:
> > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sdf/ftsdf.c?h=anuj-distance-field#n1129
> > where the `factor' is wrong after division with 64).

from a mathematical point of view only, you are doing a/64 + b/64
(this line and also a bit above, which can be factorized like that :
(a+b)/64. Maybe it is needed to divide first by 64 each term, i don't
know, i just wanted to point this


> I'm not aware of arithmetic computation problems within FreeType.
>
> Maybe you are experiencing a 32bit vs. 64bit issue?

if this is a problem of windows vs linux and 32 bits vs 64 bits, then
it is related to the 'long' type which is always a 32 bits type on
Windows, contrary to unix

>  It might also
> help to compile with UBSan to enable run-time checking of over- and
> underflow.  As an additional step, you could try to compile with clang
> instead of gcc.
>
>
> Werner
>

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

[Vincent Torri]

On Fri, Jun 26, 2020 at 3:38 PM Anuj Verma  wrote:
>
> > you also have DrMemory on Windows memory errors and leaks, and the
> > Visual Studio tools
> > (https://docs.microsoft.com/en-us/visualstudio/profiling/getting-started-with-performance-tools?view=vs-2017)
>
> That would be much more convenient, I'll check these out.

also : http://www.codersnotes.com/sleepy/

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

[Vincent Torri]

On Fri, Jun 26, 2020 at 3:01 PM Anuj Verma  wrote:
>
> > have you tried to use valgrind's callgrind tool + kcachegrind ? It can
> > be very helpful
>
> No, I haven't. The problem is that I use windows for development and
> valgrind doesn't work on windows.So, switching back and forth makes
> the process a bit tedious. I'll try to use it on WSL2.

you also have DrMemory on Windows memory errors and leaks, and the
Visual Studio tools
(https://docs.microsoft.com/en-us/visualstudio/profiling/getting-started-with-performance-tools?view=vs-2017)

Vincent Torri

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

[Vincent Torri]

On Fri, Jun 26, 2020 at 2:17 PM Anuj Verma  wrote:
>
> Hello Alexei,
>
> I tried the subdivision method that you suggested. I'll start with the
> performance.
>
> I generated 100 glyphs with a pixel size of 256 and a spread of 8
>
> A) Checking all grid points:15.43 seconds (~154ms per glyph average)
> B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
> C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)
>
> [for subdivision I equally divided the curve into 16 parts]
>
> Yes, the subdivision method is the fastest, I was not expecting this to happen
> considering it increases the number of duplicate checks and also increases the
> number of lines. Anyway, it is faster because of obvious reasons (we don't 
> have
> to `solve_cubic_equation' which is the slowest part of the entire process).

have you tried to use valgrind's callgrind tool + kcachegrind ? It can
be very helpful

Vincent Torri

> However, it is not always faster than the bounding box check, If we increase 
> the
> spread to 16, then it gets a bit slower, because while checking the proximity 
> the
> number of duplicate checks increases. But I believe that it can be avoided by
> only checking the grid points that are perpendicular to the line segment as 
> you
> said in a previous mail.
> Moreover the subdivision method gets rid of underflow issues that were caused
> while solving the cubic equation.
>
> The only downside that I can think of is that if we increase the pixel size 
> ridiculously
> then the number of divisions might have to be increased and that might make 
> the
> process slower. But, that is just my intuition and I can't say anything for 
> sure.
>
> Here is a screenshot (https://i.imgur.com/CUmGLUM.png) which compares the 
> direct
> method to the subdivision method. They look exactly the same. I have also 
> marked
> the effect of underflow on the SDF. The image is a bit large so you might 
> have to zoom
> in to see the artifact.
>
> Finally, my opinion about subdividing is changed and I say that it's 
> definitely worth
> subdividing the curve as it increases performance. But, as I said if the 
> spread is
> more than 8 then it gets slower as of now without any optimizations and I 
> still think
> we should keep the spread at least 32. So, to clarify weather 8 or 32 is a 
> good number
> I'm CCing Jim, as he uses SDF in skia he will be able to tell whether 8 is 
> enough.
> [
>   For Jim: Just to make it clear, `spread' is the max distance that will be 
> present in the final
>   SDF output. What is the max spread that you use in your SDF and is 8 enough 
> ?
> ]
>
> I have uploaded the demo directly and not the separate standalone 
> implementation
> you can check it out here : 
> https://github.com/preversewharf45/freetype2-sdf-demo
> You, can directly go here: 
> https://github.com/preversewharf45/freetype2-sdf-demo/blob/master/vendor/freetype2-sdf/src/sdfgen.c#L485
> to see the subdivision code. And yeah currently I'm subdividing equally which 
> might
> not be good. So using a more efficient algorithm to subdivide the curve will 
> be better.
>
> Sorry for a large mail and Thanks for your time,
> Anuj

Re: FT_Add_Module() and related functions

[Vincent Torri]

On Fri, Jun 12, 2020 at 3:23 PM Alexei Podtelezhnikov
 wrote:
>
> On Fri, Jun 12, 2020 at 7:22 AM Vincent Torri  wrote:
> >
> > On Fri, Jun 12, 2020 at 12:47 PM Alexei Podtelezhnikov
> >  wrote:
> > >
> > > On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri  
> > > wrote:
> > > >>
> >
> > > Almost certainly, they use FT_Outline_Render with the callback
> > > params.gray_spans doing all kinds of crazy color gradients.
> >
> > https://git.enlightenment.org/core/efl.git/tree/src/lib/ector/software/ector_software_rasterizer.c
>
> The first three functions in this file are exactly the type of
> FT_SpanFunc

they are all prefixed with SW_ because we also have a opengl rasterizer

>then you call:
> sw_ft_grays_raster.raster_render(thread->raster, );
> Do you  by any chance use FT_Get_Module to set up sw_ft_grays_raster?

git grep tells me that it is not used, but as I have said, i've never
touched this part

Vincent Torri

Re: FT_Add_Module() and related functions

[Vincent Torri]

On Fri, Jun 12, 2020 at 12:47 PM Alexei Podtelezhnikov
 wrote:
>
> On Fri, Jun 12, 2020 at 5:05 AM Moazin Khatri  wrote:
> >>

> Almost certainly, they use FT_Outline_Render with the callback
> params.gray_spans doing all kinds of crazy color gradients.

this function is not used. According to git, they use the glyph stroker API

the freetype code is used here :
https://git.enlightenment.org/core/efl.git/tree/src/lib/ector/software/ector_software_rasterizer.c
and is prefixed with SW_ (for software, as opposed to gl code that we
have too)

Vincent Torri

Re: FT_Add_Module() and related functions

[Vincent Torri]

On Fri, Jun 12, 2020 at 7:07 AM Werner LEMBERG  wrote:
>
>
> > I don't think we want to statically link any SVG renderer to the
> > library by default.  There are so many subtleties related to vector
> > graphics rendering, that there is no "good" default choice to make.
> > In other words, any default we select at link time would probably be
> > inappropriate for a lot of developers anyway.
>
> I agree.  However, I want to have a default SVG rendering engine
> detected automatically at configure time, and which can be easily
> overridden by a configure option.  Ideally, this is default is SVG
> Native
>
>   https://github.com/adobe/svg-native-viewer
>
> Unfortunately, development seems to be stalled; we probably have to go
> for something else.  Moazin right now is doing another GSoC project;
> according to an e-mail exchange with him he plans to work again on the
> SVG stuff after GSoC will have finished.

for what it worth, in our project, we use freetype engine to render svg

regards

Vincent  Torri

Re: Build system considerations

[Vincent Torri]

On Mon, May 18, 2020 at 8:44 AM David Turner  wrote:
>
>
>
> 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
>> people shouldn't rely on it anyway, even if there inevitably are
>> people that do.
>>
>
> I think providing a CMakeLists.txt that can be used directly to compile 
> FreeType as a sub-project in a CMake-based project is still a very useful 
> thing.
> As well as a FindFreeType.cmake or FreeTypeConfig.cmake module to be 
> installed to make the system library available.
>
> But that's just for the core library. I.e. the ability to build 
> documentation, install the library, or create distribution packages in CMake 
> are probably superfluous.
> I hope to see something like the following for the future:
>
> - Meson as the primary build system for FreeType developers, which includes 
> the ability to run tests, sanitizers, coverage analysis, etc.
> - Creating a distribution package should ensure the result supports 
> config/make and CMake out of the box to build a default configuration of the 
> library (with regards to features/modules, not external dependencies). The 
> meta-build script would be useful for this.
> - The distribution package should probably only contain what's needed to 
> build the library, and not all the extra tests we may use during development 
> (maybe we can separate them with git submodules, I don't know yet).
> - A developer that wants to use FreeType with a different module/feature 
> configuration would have to generate a new version of ftconfig.h/ftoption.h 
> and use that in his/her own build system.
>
> But as I said, baby steps, so let's not throw CMake support just yet.
>
> By the way, I've compared the size of the stripped libfreetype.so binaries 
> created by the 3 build systems:
>
> default: 712 KiB
> CMake: 812 KiB
> Meson: 896 KiB
>
> All generated on Linux from the same sources with the same ftconfig.h / 
> ftoption.h (in particular with all external dependencies enabled), and with 
> -fvisibility=hidden enabled for all of them.
> I don't understand why there is such a large differenc yet.

have you passed --strip to meson call ?
pass -v to ninja for verbose mode to see the differencies between make and ninja

regards

Vincent Torri

Re: Logging Library-GSOC

[Vincent Torri]

On Mon, May 18, 2020 at 9:28 AM David Turner  wrote:
>
>
>
> 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's 
>> components and only use the external library to write log messages to file 
>> instead of stderr?
>> OR
>> 2. Most external libraries provide some log levels capabilities themselves, 
>> so,  should I think in direction of utilizing those. In case yes, then how 
>> should that be utilized?
>>
> 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 string to whatever 
> log, the function could instead send a (component, level, message) tuple, 
> which would allow filtering externally (in the log library, through whatever 
> means are necessary). Also something useful when tracing is scoping traces 
> with start/stop events, but that would require new FT_TRACE_XXX() macros, so 
> should probably be considered a stretch goal. Just keep this in mind if you 
> intend to modify that part of the code.
>
>>
>> In the 2nd case, FreeType's logger will completely depend on the external 
>> library, and developers will also need to learn some new information to use 
>> the logger. And In the worst-case scenario, if the external library drops 
>> some functionality, we will need to make amendments to the logger.
>>
> I still don't know what the benefits of these external logging libraries will 
> be. Can you clarify what are we supposed to gain from this in practical 
> terms? Every dependency we add to the library becomes a maintenance burden, 
> so I would be in favor of the least coupling possible.
>

what about dlopen this external log lib ?

Vincent Torri

Re: Build system considerations

[Vincent Torri]

On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
>
>
> > currently, to have harfbuzz support, freetype must be compiled
> > without hb support, then build hb with freetype support, then
> > freetype with hb.
> >
> > it would be nice to remove this circular dependency
>
> AFAIK, this would only be possible by splitting either HarfBuzz or
> FreeType into two packages, and this won't happen.

or moving/coying some functions from freetype to hb, or conversely  ?

Vincent Torri

Re: Build system considerations

[Vincent Torri]

On Thu, Apr 30, 2020 at 2:34 AM David Turner  wrote:
>
> Starting a thread here to discuss potential build system improvements for 
> FreeType.

currently, to have harfbuzz support, freetype must be compiled without
hb support, then build hb with freetype support, then freetype with
hb.

it would be nice to remove this circular dependency

regards

Vincent Torri

Re: Build system considerations

[Vincent Torri]

On Thu, Apr 30, 2020 at 2:34 AM David Turner  wrote:
>
> 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 considered the best 
> system to configure your build (ah!), and GNU Make 3.81 was considered new 
> and bleeding edge, and didn't necessarily exist for all platforms. I'm not 
> even sure pkg-config was available on all Linux distros until quite a long 
> time. As I said ... very different times.
>
> Despite that, it was also designed to make FreeType buildable on a maximum 
> amount of systems, and I attribute part of its success to that specific 
> feature, especially in the embedded world. While we probably no longer care 
> about developers using DOS and OS/2 systems to build the library, I would 
> really appreciate if any replacement could continue in this direction.
>
> I think it would also be acceptable if the build system used to develop 
> FreeType itself, might be different than the one used by other developers 
> that simply want to use it in their own projects. For example something that 
> can build and run tests easily with sanitizers, fuzzing, remote bots and 
> other goodies, or can integrate well with a continuous integration system. 
> While at the same time, being able to generate simple Makefiles / CMakefiles 
> / BUILD / BUILD.gn / whatever corresponding to a specific configuration of 
> the library (which is what 95% of developers using the library need).
>
> I have experience with CMake (I find it a vast improvement over auto-tools 
> for package / feature detection, but a hot mess for about anything else), 
> GN/Ninja (very powerful, but essentially requires too much dependencies to 
> get the most out of it) and Bazel (can be hard to get into, very powerful, 
> but requirements are a bit crazy at the moment). I'm curious about Meson.

i prefer meson compared to cmake because :
 * more readable syntax (the main point for me)
 * meson honors CFLAGS/LDFLAGS
 * cross compilation is simpler

regards

Vincent Torri

Re: I'm back

[Vincent Torri]

Hello

not a pressure issue, but i would like to have VF driver. A Summer of
Code task has begun, never finished, though.

about build system, i would say meson only for Windows, Linux, BSD*
and Solaris, and no change for the other OS. That would simplify the
build system. are Jamfiles really useful these days ? In addition,
having a lot of build system is a pain to have them always up to date

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 the coming 
> weeks to work on FreeType. Werner invited me to write a small announcement 
> here and I'm currently looking at the official bugs list.
>
> I'd like to know what are, in your opinion, the most pressing issues to work 
> on at that point?
>
> Apart from that, I had the following things in mind:
>
> - Improving / refactoring the build system a little. E.g. it should be 
> possible to simplify the rules.mk/module.mk files considerably, and 
> auto-generate most of the Makefiles / Jamfiles / CMakefiles from a single 
> source of truth (exact format to be defined), at least the parts that deal 
> with the headers / sources / configuration headers and the module 
> dependencies.
>
> - Improve testing (unit and regression tests to be exact) There are lots of 
> possibilities here, and it will probably better to do this in small 
> incremental steps.
>
> Voila, I'd be happy to read your suggestions, Happy to be here.
>
> - David Turner

Re: Replace FreeType's tracing and debugging facilities with an external logging library

[Vincent Torri]

hello

i use msys2 to compile freetype on Windows. it will be like using a
terminal on unix

regards

Vincent Torri

On Fri, Mar 20, 2020 at 9:41 PM john doe  wrote:
>
> Greetings. I'm using the windows environment as per the project idea on the 
> subject field of this mail. Its actually difficult and unfriendly going about 
> the project. seeking for appropriate directives as per starting up the 
> free-type on windows.
>
> Thanks

'post' table format 2.0 : typo in the computation of names count ?

[Vincent Torri]

Hello

in opentype spec :

https://docs.microsoft.com/en-us/typography/opentype/spec/post#version-20

it is said that :

"If the name index is between 258 and 65535, then subtract 258"

but in src/sfnt/ttpost.c line 219, 257 is substracted. Is it normal ?

thank you

Vincent Torri

Re: [ft-devel] Question about default SVG library integration in FreeType build system

[Vincent Torri]

On Fri, Jul 19, 2019 at 1:23 PM Moazin Khatri  wrote:
>>
>> imho, just set CPPFLAGS and LDFLAGS accordingly so that header files
>> and libraries are found. These environment variables exist for such
>> purpose
>
>
> Thank you for your suggestion, Vincent.
>
> However, ultimately when we do decide on a default library, we'd wanna have 
> proper configuration for the SVG library in the build system. Isn't using 
> `CPPFLAGS' and `LDFLAGS' sort of a temporary solution?

no. It's for compilation. At runtime, the shared library will be found
as usual. There are a lot of libraries that do not ship a .pc file

Let's wait for the devs to share their opinion anyway

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Question about default SVG library integration in FreeType build system

[Vincent Torri]

On Fri, Jul 19, 2019 at 12:46 PM Moazin Khatri  wrote:
>
> Hi Werner,
>
> I am currently working on modifying the FreeType build system to add support 
> for a default SVG renderer.
>
> For something like `librsvg', things are simpler as I can just look at how 
> FreeType is currently dealing with libraries like `harfbuzz', `zlib' and 
> `libpng', and try to do the same for `librsvg'. Since, `librsvg' is easily 
> available, the process will be very similar.
>
> However, the other two libraries under focus, `resvg' and `svgnative' both 
> aren't available via package-managers at the moment. One approach I could 
> take is assume that at some point these libraries will be available via 
> package-managers, so what I could do is, install them locally, and do the 
> configuration necessary to get `pkg-config' work with them, then I could just 
> use the same procedure as with `librsvg'. Does this approach sound good? Are 
> there better ways here? Let me know what you think. :)

imho, just set CPPFLAGS and LDFLAGS accordingly so that header files
and libraries are found. These environment variables exist for such
purpose

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG: Brief Update Week 6

[Vincent Torri]

On Wed, Jul 17, 2019 at 8:44 PM Moazin Khatri  wrote:
>>
>> Using `FT_Property_Set' instead of `FT_Set_SvgHooks' is a good
>> suggestion, thanks!  Moazin, what do you think?  We would have one API
>> function less.
>>
>>   https://www.freetype.org/freetype2/docs/reference/ft2-properties.html
>
>
> I just implemented this. It works on my machine but there are compiler
> warnings. Turns out, conversions of the sort:
> + renderer->hooks.init_svg = (SVG_Lib_Init_Func)value;
> are forbidden by ISO C. Basically, conversions from
> (void*) --> function pointer

trye to add in between :

(void(*)())

Vincent Torri

> The warning message is:
>>
>> ISO C forbids conversion of object pointer to function pointer type [...]
>
>
> The function `FT_Property_Set' takes a `const void*' and this can't be
> changed. Any possible workaround?
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC'19] ftinspect questions

[Vincent Torri]

On Thu, Jul 4, 2019 at 7:55 AM Werner LEMBERG  wrote:
>
> > The online QT installer fails to check some file.  The download of
> > the offline QT installer fails (and it is more than 3Gb !!)
>
> I don't understand this remark.  Are you talking about using Qt on
> Windows in general,

in general, i don't want to download a 3Gb installer, which would
install even more data n my computer.

>or is this comment addressed to a problem with the
> `ftinspect' setup?

not at all.

>  If it is the former, I'm quite sure that such
> issues have already be discussed on Qt forums.
>
> As far as I know, Qt *does* work

I'm sure it is working on Windows. But as i can't anyway download it...

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC'19] ftinspect questions

[Vincent Torri]

On Wed, Jul 3, 2019 at 10:15 PM Werner LEMBERG  wrote:
>
>
> > is this tool availablle on Windows too ?
>
> It should be, more or less – it is Qt code using a `.pro' file (which
> must be manually adjusted).  However, I haven't tried it, and there
> may be stuff that works on Unix boxes only.
>
> It would be great if you could test it and report problems.

The online QT installer fails to check some file
The download of the offline QT installer fails (and it is more than 3Gb !!)

so I fear that i can't test it on Windows.

I would prefer another cross platform toolkit for windows, or even
using the native Windows widgets

Vincent

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

On Fri, May 24, 2019 at 5:22 PM Alexei Podtelezhnikov
 wrote:
>
> On Thu, May 23, 2019 at 10:41 PM Alexei Podtelezhnikov
>  wrote:
> >
> > On Thu, May 23, 2019 at 2:10 PM Vincent Torri  
> > wrote:
> > > > There is a comment "code adapted from enesim which was adapted
> > > > from moonlight sources". Are they based on FreeType2?
> > >
> > > https://github.com/Enlightenment/efl/blob/master/src/lib/ector/software/ector_software_rasterizer.c
> > > (If we could get RLE encoded span line, that would be quite nice).
> >
> > You are already capturing spans generated by FreeType directly. As
> > they come sequentiially, this is already as close as it gets to RLE,
> > isn't it? RLE is length-color-length-color-etc, which is what a
> > sequence of coverage-spans is. Do I miss something about RLE?
>
> The function _rle_generation_cb does too many realloc's:
> https://github.com/Enlightenment/efl/blob/master/src/lib/ector/software/ector_software_rasterizer.c#L729
> FreeType delivers one span at a time and realloc is called each time.
> FreeType can probably deliver an initial fake zero-length span to
> communicate the number of cells in the stream. Each cell can produce 1
> or 2 spans, so you can allocate memory in larger chunks. Is this worth
> it?

i'm adding Cedric, one of the dev to this thread. Let's see what he says

thank you

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

Hello

I have added the comment of one of the developper involved in the
vector rendering in the EFL. It is inlined below

Hope this helps

regards

Vincent Torri


On Wed, May 22, 2019 at 3:55 AM suzuki toshiya
 wrote:
> * output: efl_gfx
> If I can spot the location of the SVG document parser, the
> rendering of parsed SVG is done by _efl_gfx_path_XXX() in
> src/lib/efl/interfaces/efl_gfx_path.c
> (
> https://github.com/Enlightenment/efl/blob/master/src/lib/efl/interfaces/efl_gfx_path.c
> )
>
> There is a comment "code adapted from enesim which was adapted
> from moonlight sources". Are they based on FreeType2?

It has evolved a bit. As we support dynamic behavior, we have an
intermediate representation in the form of efl_canvas_vg_node. In the
case of path information, it is handled by efl_canvas_vg_shape
(
https://github.com/Enlightenment/efl/blob/master/src/lib/evas/canvas/efl_canvas_vg_shape.c
). This is then converted to an Ector primitive (this offer the
capability to "deduplicate" path computation, compute them in another
thread/on GPU and cache them). Ector then use Freetype
sw_ft_grays_raster to generate the span line in
ector_software_rasterizer.c
(
https://github.com/Enlightenment/efl/blob/master/src/lib/ector/software/ector_software_rasterizer.c
). There is quite a lot of potential speed improvement from our
perspective in the higher part of our use of Freetype. Maybe a small
amount also in Freetype API (If we could get RLE encoded span line,
that would be quite nice). But overall our current level of
performance in software is above our goal, so our work on this as
slowed down. We have some more improvement to do on the GL part and
might be a more active part of our work in the near future.

> If I'm asked to rewrite whole of elf_gfx_xxx() to fit FreeType2,
> simply I would respond "oh, too big, please modularize the
> part just to support SVG, I would reconsider after seeing it".
> Is it easy for EFL expert?


Our current use of freetype API is pretty limited. We do care of doing
the full rendering ourself as this enable animation support more
easily (We want to be able to have a representation the loaded SVG in
the form of object that the user can manipulate directly). I am not
sure that the goal of Freetype and EFL in this would really align.
Still, if there was a way to reuse a simple SVG parser, we would
likely invest the time to do so, just because it will reduce the
amount of code we have to maintain. We would also be interested in
evolution of  SW_FT_DEFINE_RASTER_FUNCS that provide RLE encoded data.
Even if it is not matching exactly our current format, improving our
code to use a new format with this kind of information would be
something we would do easily.

Rendering vector graphics fast is a hard problem. Freetype current
code base has helped us a lot to get there and we would definitively
look at improvement provided by Freetype when it could help us. In
general, we do see vector graphics being slower because each step has
different constraint and require different strategy. I mean by that,
that generating span line is very CPU intensive, but low in memory
usage and so can be easily scaled on multiple thread. If we manage to
not do this computation quickly and not more than necessary, in simple
form (one layer), we can get close to bitmap rendering if not faster
(as we use RLE as input instead of bitmap, we have a reduced memory
bandwidth in that case). In case of multi layer shape, the complexity
of not rendering span line that overlap each other would be the
greatest improvement we could do in performance as this would reduce
the memory bandwidth required for the blitting step and make it close
to bitmap rendering. Maybe something that would also be necessary for
Freetype and an area of potential shared use.

Anyway, improving vector graphics speed is something we are interested
in and if we can reduce our code size, that is even better :-)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

On Wed, May 22, 2019 at 3:55 AM suzuki toshiya
 wrote:
>
> Dear Vincent,
>
> > Enligthenment, and more precisely the EFL (the libraries)
>
> Thanks. Please let me confirm a few points.
>
> * the supported elements
> In my understanding, the parser of SVG document is implemented
> in src/modules/evas/vg_loaders/svg/evas_vg_load_svg.c
> (
> https://github.com/Enlightenment/efl/blob/master/src/modules/evas/vg_loaders/svg/evas_vg_load_svg.c
> ),
>
> I think the elements supported by this loader are defined by
> TAG_DEF macro, thus, , , , , ,
> , , , and, , , , 
> are supported. Am I understanding correctly?

yes

> * input: xml support
> If I can spot the location of the SVG document parser, it seems
> that the parsing of SVG is helped by XML parsed in
> src/lib/eina/eina_simple_xml_parser.c
> (
> https://github.com/Enlightenment/efl/blob/master/src/lib/eina/eina_simple_xml_parser.c
> )

yes, it's a simple SAX-like parser



> * output: efl_gfx
> If I can spot the location of the SVG document parser, the
> rendering of parsed SVG is done by _efl_gfx_path_XXX() in
> src/lib/efl/interfaces/efl_gfx_path.c
> (
> https://github.com/Enlightenment/efl/blob/master/src/lib/efl/interfaces/efl_gfx_path.c
> )
>
> There is a comment "code adapted from enesim which was adapted
> from moonlight sources". Are they based on FreeType2?

here I have to ask. I'm not involved in the development of that part.
I'll ask the maintainers

Vincent

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

On Tue, May 21, 2019 at 6:00 PM suzuki toshiya
 wrote:
>
> Hi Vincent, Alexei,
>
> On 2019/05/21 22:04, Alexei Podtelezhnikov wrote:
> > On Tue, May 21, 2019 at 5:35 AM Vincent Torri  
> > wrote:
> >> as I have said, in our project, we parse ourselves the svg and use
> >> freetype renderer directly for the rendering. we do not depend on any
> >> external library
> >
> > I noticed. Thank you for the vote of confidence in FreeType rendering
> > engine. I am all for adding color, even gradient color, to the engine.
>
> Excuse me, I cannot remember about the project Vincent talks about,
> please let me know what it is. Enlightenment is what you're talking about?

Enligthenment, and more precisely the EFL (the libraries)

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

On Tue, May 21, 2019 at 10:43 AM  wrote:
>
> > what annoys me with resvg is that another compiler is needed. I guess that
> for
> > unix, there is no problem with package managers, as resvg is is already
> > compiled. For (native) Windows, i will be a bit more complicated
>
> I was thinking about that as well but what about using a different renderer
> for Windows?  _If_ resvg turns out to be `the perfect' solution for Linux
> that's a big big step.  Then, finding something else that's probably equally
> perfect for Windows might be a better solution altogether than having one
> thing that works `meh' across all platforms?  That's also the core idea
> about FT's modularity.

as I have said, in our project, we parse ourselves the svg and use
freetype renderer directly for the rendering. we do not depend on any
external library

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] An analysis of Librsvg

[Vincent Torri]

On Tue, May 21, 2019 at 6:35 AM Werner LEMBERG  wrote:
>
>
> > I've mentioned this discussion to the resvg dev, and he seems pretty
> > interested:
> >
> > https://github.com/RazrFalcon/resvg/issues/135
>
> Thanks.
>
> > I can imagine that in case of resvg, the dev could be willing to
> > implement some profiles (such as OT-SVG and SVG Native) which, when
> > used, could filter unwanted content completely.
>
> Sounds good.  Moazin plans to publish similar overviews for other SVG
> engines, too.  Right now it seems that some engines miss an important
> feature necessary for SVG OT, namely the possibility to select an
> object by its ID...

what annoys me with resvg is that another compiler is needed. I guess
that for unix, there is no problem with package managers, as resvg is
is already compiled. For (native) Windows, i will be a bit more
complicated

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Supporting OT-SVG out of the box

[Vincent Torri]

hello

just fyi, the enlightenment project has a SVG parser and we use
freetype for the rendering

regards

Vincent Torri

On Sun, May 12, 2019 at 6:34 PM Moazin Khatri  wrote:
>
> Hi Werner,
>
> As I start researching about SVG rendering libraries, one thing I'll be 
> concerned with will be the dependency tree and the size of those libraries.
>
> Thinking about the sizes, brought me to the question of how will we be 
> linking the default SVG Rendering library. For the sake of this question, 
> let's ASSUME we choose to use `svgnative' with its `cairo' backend. Which of 
> the following would be our case:
>
> 1. We specify `svgnative' and `cairo' as a dependency, just like 'libpng' is 
> defined currently (provided it is configured to be `yes' in ./configure 
> step). `libpng' is NOT directly a part of `libfreetype.a', rather it's 
> supposed to be already installed in the system and is dynamically linked 
> within `libfreetype.so'. The same goes for `harfbuzz' and `graphite2'. Am I 
> correct? Is this exactly what we will be doing with the `svgnative' and 
> `cairo'?
>
> 2. We make `svgnative' a part of our codebase. Take the responsibility of 
> compiling it within our build system. At the same time, we specify `cairo' as 
> an external dependency and dynamically link it within `libfreetype.so'.
>
> 3. We make everything a part of our codebase. Including `svgnative' and 
> `cairo' and all of their major dependencies. Sounds like a really horrible 
> idea given the size of these things. But I wanted to make sure I list 
> everything that I have in my mind.
>
> Which one is it going to be? Some variation of any one of these? None of 
> these?
>
> My understanding about linking had been really weak. I have learned a lot 
> more about it with my recent experiences with compiling `svgnative' with its 
> `skia' port (which I have now successfully done). So, if I have got any major 
> concept wrong or if I am unaware of common practices, I apologize, please 
> point it out and I'll read about it.
>
> Regards,
> Moazin
>
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSOC 2019

[Vincent Torri]

hello

what about the unfinished VF driver ? it is not part of this SoC ?

vincent torri

On Wed, Feb 27, 2019 at 9:02 PM Werner LEMBERG  wrote:
>
>
> Hello Shibajyoti!
>
>
> > My name is Shibajyoti Debbarma, Pre-Final Year Engineering Student
> > from India, looking forward to contribute to the Freetype Project
> > "Replace FreeType's tracing and debugging facilities with an
> > external logging library".  I have proficiency in C and C++
> > languages so can anybody kindly guide me how to get started and any
> > suggestions for me.
>
> Please go back to FreeType's GSoC page at
>
>   https://www.freetype.org/gsoc.html
>
> and read the paragraph at the top printed in red.
>
> I urge you to also read the GSoC student guide
>
>   https://google.github.io/gsocguides/student/
>
>
> Werner
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] VF driver status

[Vincent Torri]

Hello

is there any news about this driver ?

thank you

Vincent Torri

On Sun, Nov 25, 2018 at 3:14 PM Parth Wazurkar  wrote:
>>
>> >> > i would like to know the status of the VF driver (which was a
>> >> > part of the work for GSoC if I'm not mistaken)
>> >>
>> >> It's currently unfinished.  [...]
>> >
>> > any news about these drivers ? still unfinished ?
>>
>> Alas, no progress.  Parth?
>
>
> Yes, This semester has been a lot busier than I expected and
> I was not able to do work as planned and the task is still pending.
> I have a semester break in the next month and I had
> already planned to work on the project in this duration. Hopefully,
> I shall be able to produce some good results in the next month.
> I am also eager to complete it and see it get merged.. :-)
>
> Thank you
>
> Parth

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] VF driver status

[Vincent Torri]

Hello,

On Sun, Aug 26, 2018 at 2:40 PM Werner LEMBERG  wrote:
>
>
> > i would like to know the status of the VF driver (which was a part
> > of the work for GSoC if I'm not mistaken)
>
> It's currently unfinished.  Parth has just written to me that he wants
> to continue with coding soon after finishing his current exams.
> Hopefully, there will be something real within two months or so, and I
> definitely plan to add the TeX drivers to FreeType.

any news about these drivers ? still unfinished ?

regards

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] freetype and harfbuzz

[Vincent Torri]

Hello
On Tue, Nov 15, 2016 at 1:47 AM suzuki toshiya
 wrote:
>
> Dear Vincent,
>
> >>>> Actually, it is exactly the case a friend has, and I am asking this
> >>>> question for him because he is a bit busy.  He is working on an
> >>>> installer for Windows.  But it seems that the design of his
> >>>> installer makes difficult to resolve the circular dep with the 3
> >>>> steps mentioned above.
> >> Oh, the target is Windows! I cannot help much. I don't know how
> >> Windows developer builds harfbuzz (except of the cases with cygwin
> >> & mingw).
> >
> > cross compilation on Linux using mingw-w64, targetting 32 and 64 bits
>
> I see. I try to do something for Unix based systems...

is this circular dependency still there ?

regards

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] VF driver status

[Vincent Torri]

hello

i would like to know the status of the VF driver (which was a part of
the work for GSoC if I'm not mistaken)

thank you

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC 2018] New font drivers

[Vincent Torri]

good luck !

Vincent

On Mon, Apr 23, 2018 at 9:20 PM, Parth Wazurkar 
wrote:

> Thank you so much to all the mentors for selecting my project for GSoC
> this year!
> Looking forward to get started :)
>
> Regards
> Parth
>
>
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Wed, Apr 4, 2018 at 1:23 AM, Nikolaus Waxweiler <madig...@gmail.com> wrote:
>> Theoretically yes.  However, relying on `FT_CHAR_BIT' is not as reliable as 
>> using the `SIZEOF_INT' and `SIZEOF_LONG' autoconf tests.
>
> Hm. So to unify this, I'd have to use a generic "FT_SIZEOF_LONG == (64
> / FT_CHAR_BIT)" and replace the line wholesale while configureing with
> CMake or Autoconf.

note that on Windows, a long int is always 4 bytes long, contrary to
unix where it depends on the architecture.

Vincent Torri

>
> Please have a look at
> https://github.com/madig/freetype2/commits/modernize-cmake-build.
> Attached is a patch that cleans up quite a bit.
>
> The main differences are that the Autotools build produces 300-400 KB
> smaller shared objects and making a source package will not include
> the reference and obviously the generated Autotools files. A `refdoc`
> and `devel` target are also still missing, as does a pkg-config file.
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:52 PM, Nikolaus Waxweiler <madig...@gmail.com> wrote:
> (Oh, and: streamlining the build process for all build systems should
> make it much easier to add support for more. FreeType definitely needs
> more build systems.)

then you multiply the amount of work by the number of build systems
each time you modify build systems.

sticking to one build system with a good doc is the less error prone

regards

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:47 PM, Nikolaus Waxweiler  wrote:
> Good :) Is it usable your your purposes? Is there a specific reason
> you compile in MSYS instead of using a native CMake build?

MSYS2 is "native" in the sense that there is no additional DLL which
is required (contrary to cygwin)
andi said "native" because compiling with gcc is actually cross
compilation (native would mean Visual Studio, and Visual Studio is so
huge...)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:37 PM, Nikolaus Waxweiler <madig...@gmail.com> wrote:
> Because meson is younger than the other build systems ;)

well, some big projects are already using meson. Like gstreamer.

> I'd prefer
> the entire open source ecosystem to switch to meson, but oh well ;)
> CMake is the next best thing.
>
> Use `-DCMAKE_DISABLE_FIND_PACKAGE_x=TRUE` to disable searching for a
> package entirely (x is the CMake package name, so "BZip2" instead of
> "BZIP2"). Try `-DCMAKE_DISABLE_FIND_PACKAGE_HarfBuzz=TRUE`

cmake -G Ninja -DBUILD_SHARED_LIBS=ON
-DCMAKE_DISABLE_FIND_PACKAGE_HarfBuzz=TRUE
-DCMAKE_DISABLE_FIND_PACKAGE_BZip2=TRUE .. && cmake --build . --config
Release

is working (i do not have bzip2)

> Actually, I'm in the process of cleaning up the CMake build, can you
> try compiling my
> https://github.com/madig/freetype2/tree/modernize-cmake-build branch?

same command than above, i get the DLL

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 12:20 PM, Nikolaus Waxweiler <madig...@gmail.com> wrote:
>> note that Windows (non-UNIX platform) can be compiled on MSYS2 which 
>> provides a kind of POSIX environment. I compile on it evry day
>
> Interesting, have you looked at the CMake build? I'm still amazed how
> it takes less than 5 seconds or something on my 8-core Ryzen 1700 to
> go from `cmake -G Ninja -DBUILD_SHARED_LIBS=ON .. && cmake --build .
> --config Release` to a shared lib. Running configure alone takes more
> than 5 seconds :D

fast but fails : ../src/autofit/afscript.h:35:11: error:
'HB_SCRIPT_ADLAM' undeclared here (not in a function)

how do I disable harffbuz support ?

why not uing meson ?

btw is Jam still supported ?

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Time for a new FreeType release

[Vincent Torri]

On Tue, Apr 3, 2018 at 11:53 AM, Werner LEMBERG <w...@gnu.org> wrote:
>
>> So, let me rephrase the question: what would it take to unify all
>> ftconfig.* files into one ftconfig.h.in for all platforms?
>
> Two cases have to be supported.
>
> (1) A call to
>
>   make
>
> should run on *all* platforms.  In other words, GNU make by itself
> had to produce an `ftconfig.h' file from the template.
>
> Ditto for `make devel'.
>
> (2) A call to
>
>   ./configure
>
> should do what it does now.
>
> If you manage (1), please proceed :-) As Tosihiya-san said: having a
> single config file is certainly a good idea.
>
>> This reminds me: do we really need the devel/*.h files or can we
>> make something easier using build system hackery?  Most of the
>> defines can be turned into build system options anyway, a debug
>> build would be a simple --enable-debug-build or something that turns
>> everything on.
>
> I'm open to any changes under the hood as long as `make devel' works –
> without calling `./configure', and doing a static build.
>
>>> On the other hand, it would disable direct compilation from git for
>>> non-UNIX platforms, forcing people to first say `make tarball' or
>>> something like this to generate the necessary file(s).
>>
>> Well, you want to invoke some build system anyway, so the build
>> system does the heavy lifting for you while building?  Why ship
>> pre-filled config.hs?
>
> My thinko, see above.  If GNU make produces `ftconfig.h', then I don't
> object to larger changes :-)
>
>>> If we changed the FreeType build system to native automake, say,
>>> then we could have a single `config.h' file.  I'm sometimes tempted
>>> to do that...
>>
>> Why not use AC_CONFIG_FILES like in configure.raw?
>
> Because this needs a bourne shell...

note that Windows (non-UNIX platform) can be compiled on MSYS2 which
provides a kind of POSIX environment. I compile on it evry day

and automake adds in Makefile the distcheck rule which is really useful.

in case this helps...

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LD version script

[Vincent Torri]

On Tue, Jan 30, 2018 at 1:45 PM, Tom Kacvinsky <tkacv...@gmail.com> wrote:
> Hi all,
>
> I'll see what I can do.  To be honest, the only platforms that really
> support this
> are Linux and Solaris.  I definitely have access to Linux machines, but not
> a
> Solaris machine.  I might be able to get access to the latter.

virtualbox + openindiana ?

Vincent Torri

> Despite all of the talk about whether symbol versioning is useful (and this
> is not
> meant to be snarky), keep in mind the major commercial Linux distributions
> use
> symbol versioning, as well as the free Linux distributions.  I work for SUSE
> and
> my colleagues highly recommend getting symbol versioning into FreeType.  I
> agree with them and am willing to do the work as I find time -  as the
> saying goes,
> put my money where my mouth is.
>
> The only thing I would need is a way of getting the API functions to add to
> a
> symbol versioning linker file.  This way, the symbol versioning script
> doesn't
> need to be checked in, and if we add something to the API, we don't need to
> worry about missing it in the library version file.
>
> Regards,
>
> Tom
>
> On Tue, Jan 30, 2018 at 1:25 AM, Werner LEMBERG <w...@gnu.org> wrote:
>>
>>
>> > Admittedly, symbol versioning is very poorly supported and
>> > documented [...]
>>
>> Yes.
>>
>> > [...] All in all, this looks like something to stay away from.
>>
>> Maybe there are more knowledgeable people who want to contribute...
>>
>>
>> Werner
>
>
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType DLL support

[Vincent Torri]

On Fri, Jan 19, 2018 at 2:37 PM, Alexei Podtelezhnikov
 wrote:
> Hi again,
>
> My msys2 builds produces the following:
>
> libfreetype.a (static)
> libfreetype.def
>
> libfreetype.dll.a (import)

that's the way libtool name the import library. The gnu linker (ld)
looks at that name so no problem here (see
https://sourceware.org/binutils/docs-2.17/ld/WIN32.html ("direct
linking to a DLL" section))

Vincent

> msys-freetype-6.dll
> msys-freetype-6.dll.def
>
> This looks a bit strange. Do we (or libtool?) forget to rename
> libfreetype.dll.a? Is this so called import library? The import
> library has been produced only recently after we added
> dllimport/dllexport.
>
> My MSVC builds produce
>
> freetype.lib (static)
>
> freetype.lib (import)
> freetype.dll
>
> I do not like that the naming is inconsistent altogether. Any suggestions?
>
> Alexei
>
>
>
>
> Alexei

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType DLL support

[Vincent Torri]

On Sat, Jan 13, 2018 at 7:50 PM, Werner LEMBERG <w...@gnu.org> wrote:
>
>> Btw, visual studio's project/sln files can contain compiler
>> preprocessor definitions also.  You can do that FT_EXPORT redefine
>> hacks in those.  There is no need to polute the rest of Freetype
>> source/header.  The requirement is entirely visual studio specific
>> and mingw does not need it.
>
> But Visual C is a front-end to a command line compiler, isn't it?

it is.

>  In
> that it makes sense to have this stuff in FreeType's header file also;
> for example, people want to call nmake manually...

also it is necessary for applications or libraries  using freetype
that FT_EXPORT be defined to dllimport (which is currently the case).

I would like also to mention in the case of UNIX using gcc, that the
visibility of symbols can be changes by a compiler flags (remark that
there is a difference between gcc and windows compiler : on UNIX, gcc
exports all the symbols by default, which is the contrary on Windows).

so if, on UNIX, one  passes -fvisibility=hidden to gcc, FT_EXPORT
should be defined as __attribute__ ((visibility("default")))

Here is what is done in a project which I contribute to (EAPI below is
the equivalent of FT_EXPORT) :

#ifdef _WIN32
# ifdef EFL_ECORE_WIN32_BUILD   // useless in the case of freetype
#  ifdef DLL_EXPORT
#   define EAPI __declspec(dllexport)
#  else
#   define EAPI
#  endif
# else
#  define EAPI __declspec(dllimport)
# endif
#else
# ifdef __GNUC__
#  if __GNUC__ >= 4
#   define EAPI __attribute__ ((visibility("default")))
#  else
#   define EAPI
#  endif
# else
#  define EAPI
# endif
#endif

and we prepend EAPI in front of the declaration of public symbols

see https://gcc.gnu.org/wiki/Visibility for the documentation of
-fvisibility flag

Hth

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType DLL support

[Vincent Torri]

On Sat, Jan 13, 2018 at 8:35 AM, Werner LEMBERG  wrote:
>
>> by default, configure created by autoconf enables both static and
>> shared library. For me static library is useless, DLL's are what
>> should be used. And compilation is slower with both enabled as both
>> static and share lib are created
>
> I don't plan to change the default...

so ? i've not ask anyone to change the default behavior, i just
mentioned the facts. That's why there are options to configure and
that's why **I** pass --disable-static for all **my**  DLL.

Vincent

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 12)

[Vincent Torri]

On Fri, Jan 12, 2018 at 11:08 PM, Alexei Podtelezhnikov
<apodt...@gmail.com> wrote:
>
>
> On Fri, Jan 12, 2018 at 4:54 PM, Martin Gieseking <martin.giesek...@uos.de>
> wrote:
>>
>> Am 12.01.2018 um 22:45 schrieb Vincent Torri:
>> > and pass -D_DLL in unix Makefile when compiling the shared lib and
>> > everything will be fine
>>
>> I suggest to also check DLL_EXPORT here since the configure script
>> automatically adds -DDLL_EXPORT to CFLAGS if the build system is
>> configured to create a shared library with MinGW/Cygwin.
>
>
> Martin, Vincent,
>
> Thank you, I got it, libtool works :). You are saying both --disable-static
> or --enable-shared should work. Should not that be default?

by default, configure created by autoconf enables both static and
shared library. For me static library is useless, DLL's are what
should be used. And compilation is slower with both enabled as both
static and share lib are created

>
> Now, does your MinGW/Cygwin come with 'windres' to compile the version
> resource (ftver.rc) in? I know this is too much to hope for.

yes, i have windres

Vincent Torri

> Alexei

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 12)

[Vincent Torri]

and pass -D_DLL in unix Makefile when compiling the shared lib and
everything will be fine

On Fri, Jan 12, 2018 at 10:36 PM, Vincent Torri <vincent.to...@gmail.com> wrote:
> in ftconfig.h replace
>
> #ifdef _MSC_VER
>
> with
>
> #ifdef _WIN32
>
>
>
> On Fri, Jan 12, 2018 at 10:29 PM, Alexei Podtelezhnikov
> <apodt...@gmail.com> wrote:
>>
>>> > FreeType do not have DLL support for those tools yet. Patches are
>>> > welcome.
>>>
>>> I've just tried freetype 2.9 with MSYS2 + mingw-w64 :
>>>
>>> ./configure --host=i686-w64-mingw32 --disable-static
>>> make -j7
>>>
>>> and I have my DLL
>>
>> You have proper symbols exported and import library created, without the
>> need for dllexport, I assume. Cool.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 12)

[Vincent Torri]

in ftconfig.h replace

#ifdef _MSC_VER

with

#ifdef _WIN32



On Fri, Jan 12, 2018 at 10:29 PM, Alexei Podtelezhnikov
 wrote:
>
>> > FreeType do not have DLL support for those tools yet. Patches are
>> > welcome.
>>
>> I've just tried freetype 2.9 with MSYS2 + mingw-w64 :
>>
>> ./configure --host=i686-w64-mingw32 --disable-static
>> make -j7
>>
>> and I have my DLL
>
> You have proper symbols exported and import library created, without the
> need for dllexport, I assume. Cool.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 12)

[Vincent Torri]

On Fri, Jan 12, 2018 at 9:39 PM, Alexei Podtelezhnikov
<apodt...@gmail.com> wrote:
>
>
>> Not really. dllexport/dllimport is platform- and not compiler-specific.
>> GCC and Clang on MinGW also support them
>
> FreeType do not have DLL support for those tools yet. Patches are welcome.

I've just tried freetype 2.9 with MSYS2 + mingw-w64 :

./configure --host=i686-w64-mingw32 --disable-static
make -j7

and I have my DLL

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC has ended

[Vincent Torri]

On Sat, Sep 9, 2017 at 4:47 PM, Werner LEMBERG <w...@gnu.org> wrote:
>
> GSoC 2017 has ended, and two participants (Kushal and Ewald) have
> successfully finished.  Congrats to both of you!
>
>   Ewald: Adding support for Type 1 fonts to Adobe CFF Engine
>   http://lists.nongnu.org/archive/html/freetype-devel/2017-08/msg00148.html
>
>   Kushal: Test framework for FreeType's rendering output
>   http://lists.nongnu.org/archive/html/freetype-devel/2017-08/msg00154.html
>
> It was a nice collaboration, and I hope that you have enjoyed it, too.
> Ewald's code will eventually be added to master after the next
> FreeType release (which I will publish this month).  It's not clear
> yet where Kushal's code will be added – maybe it belongs into a
> separate git repository, together with fonts used for testing.  I'm
> open to any suggestions.
>
> Both Ewald and Kushal have stated that they want to continue their
> work on FreeType, which makes me feel better :-)
>
> This was the first time FreeType participated in GSoC, and I believe
> it was a success.  If you have suggestions for further GSoC ideas,
> please drop me an e-mail so that I can update and extend our webpage!
>
>   https://www.freetype.org/gsoc.html

adding virtual fonts to freetype

i've already proposed you to look into that, but life is decreasing my free time

Vincent TORRI

>
>
> Werner
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] windows: why the .lib file isn?t generated (Re: Freetype-devel Digest, Vol 151, Issue 38)

[Vincent Torri]

On Fri, Aug 25, 2017 at 7:17 PM, Hin-Tak Leung
 wrote:
>> Date: Thu, 24 Aug 2017 10:34:24 -0700
>> From: "jo...@msli.com"
>> 
>> To: freetype-devel@nongnu.org
>> Subject: [ft-devel] windows: why the
>> .lib file isn?t generated
>
> 
>
>> I expect to see both
>
>> %SRC%\objs\vc2010\Win32\freetype*.lib
>
>> %SRC%\objs\vc2010\Win32\freetype*.dll
>
>> But I only see the .dll
>
>> I am trying to use this with occt (Open
>> Cascade), which fails to
>> configure if the .lib is not present.
>
>> How do I fix my build?
>
> This is rather something you should consult your visual studio documentation 
> for - I suspect it is a radio button option somewhere. The *.lib is called an 
> "import library" - i.e. find that option in your visual studio menus.. 
> Perhaps you can follow the mingw link below to fix it after the build too.
>
> When I am cross-compiling freetype for windows from linux (with the mingw 
> cross gcc), the *.lib import libraries are created by an additional step with:
> dlltool :
> http://www.mingw.org/wiki/createimportlibraries

or maybe the file *.dll.a is created (import lib created by libtool
has usually the prefix .dll.a)

>
>
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType and WinAPI (Re: Freetype-devel Digest, Vol 145, Issue 1)

[Vincent Torri]

On Thu, Feb 2, 2017 at 12:05 AM, Hin-Tak Leung
<ht...@users.sourceforge.net> wrote:
> I
>  tried cross-compiling it with both the 32-bit and 64-bit mingw
> toolchains, and running the results under 32-bit and 64 bit wine.
>
>  - with the 64-bit toolchain (and only with the 64-bit toolchain), there
>  is an error:
>
> FTWinDemo.cpp: In function 'bool AssignWindow(AppInfo*)':
> FTWinDemo.cpp:471:57: error: cast from 'AppInfo* {aka _AppInfo*}' to
> 'LONG {aka long int}' loses precision [-fpermissive]
>  SetWindowLongPtr( app->window, GWLP_USERDATA, (LONG)app );
>   ^~~

contrary to UNIX, on Windows, a LONG is 32 bits size long, so you
should use instead ULONG_PTR or (uintptr_t to be cross platform)

Vincent Torri

> When running under either 32-bit or 64-bit wine, there are a couple of
> issues:
>
> - Verdana.ttf is not shipped with wine, nor you should assume
> "c:/windows/fonts/Verdana.ttf" exist. It might be best to just bundle
> one of the smaller free fonts for demonstration, like liberation?
>
> - I got a pop-up error message box saying "Not set LCD filter: 7 " . 7
> means "unimplemented feature", I looked it up. Maybe you can actually
> use a more user-friendly error strings from fterrdef.h  than the numeral
>  7 ? That was against freetype 2.6.5 as shipped by fedora. I think LCD
> filter is a recent feature and depending on build options, etc? I see
> you are not using any special options, so it is maybe fedora shipping
> freetype which hasn't got it enabled. Best not to depend on it.
>
> - the same with 'cannot open resource" for error 1, for not finding
> Verdana . "Font not load: 1" isn't helpful.
>
> - after dismissing the pop-up box, the main window remain blank, until I
>  minimize/maximize it. You may be missing a paint-on-? event somewhere?
> Or perhaps choosing background/forground color?
>
> Anyway, well-done!
>
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ft] Another problem with X11 PCF fonts and 2.7.1, now with bisect

[Vincent Torri]

Hello

you can have a math formula to link the tarball version and the
libtool one, following what Johnny mentioned :

tarball version micro++ : bug fixes
tarball version minor++ : addition of API and micro set to 0
tarball version major++ : API and ABI break and micro and minor set to 0

then, here is what we use in our configure.ac's :


m4_define([v_maj], [1])
m4_define([v_min], [18])
m4_define([v_mic], [7])
m4_define([v_ver], [v_maj.v_min.v_mic])

m4_define([lt_cur], [m4_eval(v_maj + v_min)])
m4_define([lt_rev], [v_mic])
m4_define([lt_age], [v_min])

AC_INIT([project], [v_ver], [mail])



version_info="lt_cur:lt_rev:lt_age"
AC_SUBST([version_info])

and in our Makefile.am's :

project_la_LDFLAGS =  -version-info @version_info@

regards

Vincent Torri



On Fri, Jan 13, 2017 at 11:00 PM, Werner LEMBERG <w...@gnu.org> wrote:
>
> Jonny,
>
>
>> Intentionally releasing new features (turning them ON by default) in
>> a patch release is unacceptable behaviour from any serious project.
>
> I underestimated the effect of the PCF change; the next version will
> have this feature off – I have already written that to the mailing
> list.  Maybe you've missed this.
>
>> Major number increase: New features that might break backwards
>>compatibility
>> Minor number increase: New features that DOESN'T break backwards
>>compatibility (thus new feature but turned
>>OFF default)
>> Micro/path number increase: Only bug fixes
>
> For me, `backwards compatibility' is something related to the ABI.  I
> have the feeling that you are mixing up software release numbers with
> DLL versions.  Have a look into `docs/VERSIONS.TXT'.
>
>> Even your news page states something in the line of "finally we have
>> a new 'minor' number increase so we can change default ..." (!)  No
>> really you can NOT do that in a minor version number bump, you do
>> that in a major number bump!
>
> Definitely not.  FreeType 3 would be a major redesign of the library
> coming with a new API.  In other words, new features are handled with
> the `minor' number in the source tarball.  Again: the versioning
> scheme of the tarball is *completely irrelevant* to the backwards
> compatibility of the ABI.
>
>> Your current ignorance to the versioning standard is not only
>> frustrating but directly causing major problems for distributions
>> and its users.
>
> Pfft.  You are greatly exaggerating.  You are the *first* one who
> brings up this complaint!
>
>> Please take some responsibility and comply with the standard or
>> ignore the versioning system and go with systemd-like versioning.
>
> It's not clear to me why the tone of your e-mail is so hostile.  Who
> are you in the software world to complain about `frustration' and
> `major problems for distributions and its users'?  Can you give some
> evidence for your claims?  And yes, I have read `semver.org' – since
> FreeType uses libtool, it relates to DLL versions and *not* to the
> tarball versions.
>
>
> Werner
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] freetype and harfbuzz

[Vincent Torri]

On Mon, Nov 14, 2016 at 8:00 PM, Werner LEMBERG <w...@gnu.org> wrote:
>>> You are aware there exists mxe that uses, AFAIK, exactly this build
>>> environment?
>>>
>>>   http://mxe.cc/
>>
>> yes, and there are plenty of others.
>>
>>> Why reinventing the wheel?
>>
>> Why is there Gnome and KDE and Xfce and etc... ?
>>
>> The current solutions are not satisfying in our POV
>
> You have too much time... :-)

i'm just running the compilation so not a big deal

And i'm also using freetype in a project :p

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] freetype and harfbuzz

[Vincent Torri]

Hello

On Mon, Nov 14, 2016 at 7:41 PM, Werner LEMBERG <w...@gnu.org> wrote:
>>> Oh, the target is Windows! I cannot help much. I don't know how
>>> Windows developer builds harfbuzz (except of the cases with cygwin
>>> & mingw).
>>
>> cross compilation on Linux using mingw-w64, targetting 32 and 64
>> bits
>
> You are aware there exists mxe that uses, AFAIK, exactly this build
> environment?
>
>   http://mxe.cc/

yes, and there are plenty of others.

> Why reinventing the wheel?

Why is there Gnome and KDE and Xfce and etc... ?

The current solutions are not satisfying in our POV

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] freetype and harfbuzz

[Vincent Torri]

Hello

On Mon, Nov 14, 2016 at 11:25 AM, suzuki toshiya
<mpsuz...@hiroshima-u.ac.jp> wrote:
> Dear Vincent,
>
> I sympathize with your feeling about the circular dependency,
> however, the people saying and doing something about it seem
> to be minority (I'm saying about it but doing nothing, sorry).
>
> If FreeType2 building system supports a case that a developer
> extracts the harfbuzz source to some directory and build at
> same time (I think such style is popular for the people making
> cross build toolchain at once: binutils + gcc), it would be
> acceptable improvement?

Actually, it is exactly the case a friend has, and I am asking this
question for him because he is a bit busy. He is working on an
installer for Windows. But it seems that the design of his installer
makes difficult to resolve the circular dep with the 3 steps mentioned
above.

so if Freetype2 supports the extraction of harfbuzz source code and
build it, it would indeed solve his problem

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] freetype and harfbuzz

[Vincent Torri]

hello

On Mon, Nov 14, 2016 at 8:38 AM, Werner LEMBERG <w...@gnu.org> wrote:
>
>> I would like to know the status freetype wrt harfbuzz. Actually, if
>> I'm not mistaken, one has to :
>>
>> 1) compile freetype without harfbuzz
>> 2) compile harfbuzz (freetype is hard dep iirc)
>> 3) compile freetype with harfbuzz
>
> Yes.  However, FreeType looks for its dependencies, so you only have
> to do
>
>   cd freetype; make && make install; cd
>   cd harfbuzz; make && make install; cd
>   cd freetype; make && make install; cd
>
> which is not rocket science.
>
>> Is there some improvements of that situation? (It has been a long
>> time since i followed freetype development)
>
> No.  It seems that people can live with the current situation.  A
> `solution' would either mean splitting harfbuzz into two separate
> libraries or duplicating a lot of harfbuzz code in FreeType.

or adding public functions in freetype which "copy/paste" the
functions in harfbuzz, and modify harfbuzz so that it uses these
functions. This will remove the circular dependency.

harfbuzz is released under the MIT license so i think it is possible
to borrow code from harfbuzz and use it in freetype, if I'm not
mistaken

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] freetype and harfbuzz

[Vincent Torri]

Hello

I would like to know the status freetype wrt harfbuzz. Actually, if
I'm not mistaken, one has to :

1) compile freetype without harfbuzz
2) compile harfbuzz (freetype is hard dep iirc)
3) compile freetype with harfbuzz

Is there some improvements of that situation ? (It has been a long
time since i followed freetype development)

thank you

Vincent Torri

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel