[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Supporting OT-SVG out of the box
From: |
armin |
Subject: |
Re: [ft-devel] Supporting OT-SVG out of the box |
Date: |
Sun, 12 May 2019 18:13:22 +0100 |
Hi Moazin,
I think Werner took the day off today so let me quickly jump in with a few
thoughts that might help you until Werner is back :)
> 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.
Hell yeah, you don't want to mess with building those yourself, usually ;)
> 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'?
I assume yes, very much so. FreeType has never used (git) submodules of sorts
(afaik) and quite frankly, even though it got a lot better, submoduling is
still pretty painful, even with modern git. (Beware: this is my _personal_
opinion)
In contrast, using (`linking') external libraries on Linux (FreeType's main
target system) is and has always been easy and super-efficient. You don't have
to care about _any_ updates (changes to other build systems, e.g.) of those
libraries and you can link them in all sorts of funny ways (dynamically [pretty
much standard for many things], statically, or even at runtime within your
application). Also, you don't have to care about target specific weirdness of
those other libraries.
> 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?
Like said above, I'd be surprised if Werner rooted for including other code in
FreeType's repository.
> 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.
Don't worry; there's really not much going on with linking :) I'll add a few
thoughts here, skip it if you feel like I'm telling you stuff you already know;
sorry upfront, if that's the case!
>From a library user's perspective, all you (usually) do (on Linux) is include
>some header files that are provided by the library that you want to use. When
>using FreeType (as a library), you are tasked with adding `public' header
>files from the `include/' folder, for example. Side note: many libraries
>provide their public header files in an `include' folder in their root folder,
>however, this is not mandatory. Also, when you're using specific
>`devel'/`dev' versions of libraries, they usually add their public header
>files to the system-global include folder which automates the process of
>looking for those headers for you. Then, you can use the functions, structs,
>defs, etc in these public header files of a library exactly the same way as
>you usually use your own header files in your projects. The only difference
>is that you can't find the implementation of these functions in *.c, *.cpp,
>*.xyz files but ALL functions (!) are hidden in special `executables' (called
>`libraries'). More precisely, the `machine code' in these libraries is
>usually neatly precompiled and optimised so you don't have to mess with
>building anything and getting that right. Instead, you can use these
>libraries `out of the box' (if a precompiled version is available for your
>system). The only thing that _you_ (as a user) have to do is tell _your_
>compiler where to find these precompiled code blobs. The compiler/linker then
>takes care of stitching up your application with the precompiled code blob.
>If that fails (usually an issue with the library) you get linker errors that
>complain about missing functions etc.
There's then the difference between dynamic, static + runtime linking but for a
general understanding, it all works the same :)
Hope I could help at least a bit. If not, let me know, I'll be sitting in
front of my computer for a few more hours today.
Best
Armin
Re: [ft-devel] Supporting OT-SVG out of the box, Werner LEMBERG, 2019/05/12
Re: [ft-devel] Supporting OT-SVG out of the box, Vincent Torri, 2019/05/12