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

[armin]

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