[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] To Add support for the 'SVG' OpenType table to render col

From: Werner LEMBERG
Subject: Re: [ft-devel] To Add support for the 'SVG' OpenType table to render color fonts.
Date: Fri, 25 Jan 2019 19:35:48 +0100 (CET)

[In the future, please *always* write to address@hidden',
 not to me privately.]

Hello Alekh!

Thanks for your interest in FreeType's GSoC project.  Note, however,
that you are far too early – while FreeType is going to apply for
GSoC, it isn't sure yet that it will also be selected...

> I am a Computer Science Engineering Student.  I want to work on the
> project of Freetype open source software titled "Add support for the
> '*SVG*' OpenType table to render color fonts".  As "Scalar Vector
> Graphics" is an image file format which is gaining popularity due to
> its better resolution than other file format like *JPEG*, *PNG*,
> *GIF*.  Most of the major browsers like Chrome, Mozilla, Opera and
> Microsoft Edge have '*SVG*' rendering support.  So it is now a need
> of time to make Freetype able to support '*SVG*' OpenType font for
> color font rendering, which allows multiple colors or gradients in a
> single glyph.

Be careful to make a distinction between SVG support in a browser and
in an OpenType font.  These things are *not* related!  In particular,
FreeType is a font *rendering* library, this is, it produces bitmaps
and/or pixmaps.  It doesn't produce outlines.

> The most suitable free library that I have investigated can be
> '*librsvg*' by *GNOME* to make Freetype render color fonts.

OK.  However, such an investigation would be part of GSoC proper.

> Creating a new module is a better option as it will keep the earlier
> source undisturbed.  But if complete integration into current main
> API stuff is needed keeping in mind the long term sustainability of
> Freetype font renderer.  Then adding functions to test the font for
> 'svg', for extracting data from 'svg' OpenType table for new
> library, transferring bitmap output to the Freetype finally will be
> required.

Again, this should be evaluated while doing the GSoC project.

> The best thing is that external library '*librsvg*' is also written
> mostly in C and exists since 'svg' was standardised.

Hmm.  As far as I can see, librsvg is moving to Rust as the primary
source code language...  Fortunately, this is not relevant as long as
a C API is available that FreeType can use.

> FreeType is used in most linux distributions and making it support
> '*SVG*' OpenType font will make it truly updated.  I have mailed
> earlier also to work on this project.  I will like to continue this
> as my *GSOC* project.

It's too early to talk about that.  However, in case FreeType gets
selected as a GSoC mentoring project, you are welcomed to submit a

> But irrespective of this fact I will love to contribute to make
> FreeType up-to-date.

This would be great!

> Can you please suggest which approach should be tried to integrate
> the external library?  As modular will leave rest of code of
> Freetype undisturbed while the other one will eliminate need to
> define functions to extract the data for external library and then
> again transfer the bitmap output to Freetype.

Reading my responses above I think you can already guess my answer: I
can't suggest an approach – it's something to be evaluated as part of
the GSoC project :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]