freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Amalgamation details


From: Vinnie
Subject: Re: [ft-devel] Amalgamation details
Date: Sat, 14 Apr 2012 09:19:01 -0700 (PDT)

> From: Alan Coopersmith <address@hidden>


> Do you know where most of the FreeType security issues in the past few years
> has been found?   By people trying to hack smartphones via downloads of
> malicious PDF's or opening webpages with bad webfonts.

That's
 only a vulnerability of the application in question allows loading of 
arbitrary fonts. For the case where an application simply wants hinted 
output of its own font used in a user interface, with the entire font 
file embedded in the application as static data or a resource (100% of 
my users) there is no issue!

> Of course, those smartphone OS'es are providing system font rendering using
> FreeType so you don't have to shove in another copy there.

I
 agree and its on my to-do list to refine the amalgamation so that it 
detects and uses the system provided library on environments where it 
exists. This behavior will be overridable with a configuration macro, for those 
people who have built a rich GUI on top of a hinted 
font and did all their testing with a specific version of FreeType, and 
don't want to be exposed to a bug in a shared FreeType library making 
their application look bad (for example, a defect discovered in the auto
 hinter).

The end-game is to build rich open source 
GUI components on top of the FreeType amalgamation which will seamlessly 
provide FreeType either through the amalgamated sources or the system provided 
libraries (at the programmer's option), 
with the ability to distribute these GUI components without external 
dependencies (by including the amalgamation in the source distribution). All 
this, with no Makefiles or platform specific configuration required. In other 
words, for dummies.

Of
 course it is worth repeating once again this use-case is contemplated 
ONLY FOR FONTS EMBEDDED IN THE APPLICATION and not for fonts which come 
from external files!

I know this is a difficult concept for a lot of people who have no experience 
writing shrink-wrapped applications (which seem to be going the way of the 
Dodo) so here is an example (again):

http://m.artician.com/pu/3G665GVDE5WXL3A7SOS6MP4RCOI6MJHB.preview.jpeg

This is GUI for an audio plugin. These plugins typically have compact 
interfaces with small text, which is a great candidate for hinting. A plugin 
author can choose a good hinted font, embed it in their application (using a 
command tool that converts a binary file into a giant C-style static array), 
and then use FreeType to draw the font and get nice output at the small sizes. 
The benefit of using a statically linked FreeType is that you can design your 
interface, test it against the specific FreeType version, and then be assured 
that no matter what the user has on their system in terms of FreeType 
libraries, the application or plugin appearance will not change.

Most audio plugins are built on JUCE (http://rawmaterialsoftware/juce.php) 
which is specifically tuned for making it easy to write cross platform user 
interfaces and audio plugins in particular. For this reason, I have built a 
class that works with the JUCE font rendererer to provide hinted output for 
embedded fonts:

http://vinniefalco.github.com/VFLib/class_free_type_faces.html

I hope this rant has helped to provide a broadened view of the variety of ways 
in which FreeType may be used.



reply via email to

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