1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<meta http-equiv="Content-Style-Type"
content="text/css">
<meta http-equiv="Content-Script-Type"
content="text/javascript">
<meta name="description"
content="Ideas for GSoC">
<meta name="keywords"
content="GSoC Ideas">
<link rel="icon"
href="image/favicon_-60.ico">
<link rel="shortcut icon"
href="image/favicon_-60.ico">
<link rel="stylesheet"
type="text/css"
href="css/freetype2_-60.css">
<script type="text/javascript"
src="js/jquery-1.11.0.min.js">
</script>
<script type="text/javascript"
src="js/jquery.ba-resize.min.js">
</script>
<script type="text/javascript"
src="js/freetype2.js">
</script>
<title>Ideas for Google Summer of Code</title>
</head>
<body>
<div id="top"
class="bar">
<h1><a href="index.html">FreeType</a> & GSoC</h1>
</div>
<div id="wrapper">
<div class="colmask leftmenu">
<div class="colright">
<div class="col1wrap">
<div class="col1">
<!-- ************************************************** -->
<div>
<p>The FreeType project is part
of <a href="https://developers.google.com/open-source/gsoc/">Google
Summer of Code 2017</a>! Here is our ideas list – if
you have another one, please write to
our <a href="mailto:freetype-devel@nongnu.org">mailing
list</a> so that we can discuss your suggestions,
eventually adding them to the list.</p>
<p>If you are interested to participate as a student, please
also contact us via
the <a href="mailto:freetype-devel@nongnu.org">mailing
list</a>.</p>
<dl>
<dt>Improve fuzzing for FreeType</dt>
<dd>
<p>There are at least two fuzzers that constantly test
FreeType. One of them
is <a href="https://github.com/google/oss-fuzz">OSS-Fuzz</a>,
and the tasks for GSoC presented here are targeted to
increase the efficiency of this fuzzer bot.</p>
<dl>
<dt>Split the existing fuzz target into many</dt>
<dd>
<p>Right now we
have <code>src/tools/ftfuzzer/ftfuzzer.cc</code>
that contains</p>
<pre>
extern "C"
int LLVMFuzzerTestOneInput(const uint8_t* data,
size_t size_)
{
return ParseWhateverFontFileIGet(data,
size);
}</pre>
<p>Instead of this monolithic approach we should
split fuzzing into separate files (fuzz targets)
for every font format, for example</p>
<pre>
src/tools/ftfuzzer/cff_fuzz.cc
src/tools/ftfuzzer/cff2_fuzz.cc
src/tools/ftfuzzer/cid_fuzz.cc</pre>
<p>and every such file will have</p>
<pre>
extern "C"
int LLVMFuzzerTestOneInput(const uint8_t* data,
size_t size_)
{
return ParseOnlyMyFormatAndRejectAnythingElseQuickly(data,
size);
}</pre>
<p>Ideally, the build rule for <code>cff_fuzz</code>
will not <em>link</em> anything that CFF does not
need.</p>
<p>Such a split will make fuzzing more efficient for
many reasons.</p>
<ul>
<li>Genetic mutations will not spend time crossing
over files of different formats (e.g., trying to
add BDF genes to a Type 1 font).</li>
<li>Data-flow guided mutations will not try to
transform, say, a CID font file into a PCF font
file.</li>
<li>Some of the fuzzer's internal algorithms that
are linear by the code size will run faster.</li>
<li>Slow inputs that currently make fuzzing
inefficient will cause only some of the targets
suffer, not all of them.</li>
</ul>
<p>The changes will need to be reflected in the
<a href="https://github.com/google/oss-fuzz/tree/master/projects/freetype2">OSS-Fuzz
repository</a>.</p>
</dd>
</dl>
<dl>
<dt>Prepare a public corpus of inputs</dt>
<dd>
<p>The quality of the ‘seed corpus’ is
the key to fuzzing efficiency. We should set up a
repository (e.g., in github) that would hold</p>
<ul>
<li><em>small</em> but representative sample font
files for every relevant font format (only with
permissive licenses!), and</li>
<li>fuzzed mutations of the above (this part will
need to be periodically updated as fuzzing finds
more inputs).</li>
</ul>
<p>This corpus will be used in two ways, namely</p>
<ul>
<li>to seed the fuzzing process, and</li>
<li>as a regression suite (see below).</li>
</ul>
</dd>
</dl>
<dl>
<dt>Extend the FreeType testing process to use the
above corpus</dt>
<dd>
<p>The public corpus will allow us to use the fuzz
targets as a regression test suite. We'll need to
set up a continuous integration testing (not
fuzzing) to run the fuzz targets on the corpus.
One way to achieve it is to have a github mirror
of FreeType and set up Travis (or whatever other
CI integrated with github).</p>
</dd>
</dl>
<dl>
<dt>Analyze code coverage</dt>
<dd>
<p>Once the fuzz targets are split, the public
corpus is prepared, and the OSS-Fuzz integration
is updated, we'll need to analyze
the <a href="https://github.com/google/oss-fuzz/blob/master/docs/clusterfuzz.md#coverage-reports">code
coverage provided by OSS-Fuzz</a> to see what code
is left untested.</p>
<p>Then either the fuzz targets or the corpus (or
both) will need to be extended to cover that code.
The ideal end state is to have 100% line coverage
(currently, we have ~67% for the existing fuzz
target).</p>
</dd>
</dl>
<dl>
<dt>Prepare fuzzing dictionaries for the font formats
where relevant</dt>
<dd>
<p>In some cases a simple dictionary (list of tokens
used by the file format) may
have <a href="http://libfuzzer.info/#dictionaries">dramatic
effect on fuzzing</a>.</p>
</dd>
</dl>
<p><em>Difficulty: </em>medium. <em>Requirements:</em>
C, C++, Unix build tools, experience with
scripting. <em>Potential mentors:</em> Kostya
Serebryany (Google), Werner Lemberg (FreeType).</p>
</dd>
</dl>
<dl>
<dt>Develop a test framework for checking FreeType's
rendering output</dt>
<dd>
<p>Right now, FreeType's rendering results of the
current development version are not systematically
compared to a baseline version. This is problematic,
since rendering regressions can be very easily missed
due to subtle differences.</p>
<p>The idea is to select a representative set of
reference fonts from font corpora (which already exist
mainly for fuzzing). The fonts are used to produce
glyph images for various sizes and rendering modes
(anti-aliased, B/W, native hinting, auto-hinting,
etc.). FreeType can already produce MD5 checksums of
glyph images as part of its debugging output; these
values should be compared against a baseline version
of rendering results. If there are differences, HTML
pages should be generated that contain comparison
images of the baseline's and the current development
version's rendering result, ideally indicating how
large the differences between the images are by using
some yet to be defined measure.</p>
<p><em>Difficulty:</em> medium. <em>Requirements:</em>
C, Unix build tools. <em>Potential mentors:</em>
Werner Lemberg, Alexei Podtelezhnikov, Toshiya Suzuki
(FreeType).</p>
</dd>
</dl>
<dl>
<dt>Improve the ‘ftinspect’ demo program</dt>
<dd>
<p>Right now, FreeType comes with a suite of small
graphic tools to test the library, most notably
‘ftview’ and ‘ftgrid’. The
used graphics library, while working more or less, is
very archaic, not having any comfort that modern GUIs
are providing.</p>
<p>To improve this, a new demo program called
‘ftinspect’ was started, based on the Qt
GUI toolkit. However, the development is currently
stalled, mainly for lack of time.</p>
<p>The idea is to finish ftinspect,
handling <em>all</em> aspects of the other demo
programs. Currently, it only provides the
functionality of ‘ftgrid’.</p>
<p>If the student prefers, the Qt toolkit could be
replaced with GTK.<p>
<p><em>Difficulty:</em> medium. <em>Requirements:</em>
C, C++, Qt, Unix build tools. <em>Potential
mentor:</em> Werner Lemberg (FreeType).</p>
</dd>
</dl>
<dl>
<dt>Make FreeType use the new CFF driver for Type 1
fonts also</dt>
<dd>
<p>Since Adobe's contribution of a new CFF driver,
FreeType has excellent hinting support for this font
format.</p>
<p>On the other hand, FreeType's hinting of PostScript
Type 1 fonts is rather bad, mainly for historical
reasons and lack of maintainance.</p>
<p>Since both CFF and Type 1 are PostScript font
formats, the similarity (after decoding) is large.
The idea is now to make the CFF driver understand
Type 1 fonts; this would automatically yield
much better hinting.</p>
<p><em>Difficulty:</em> hard (because of getting
acquainted to FreeType internals, not the coding
itself). <em>Requirements:</em> C, Unix build
tools. <em>Potential mentor:</em> Werner Lemberg
(FreeType).</p>
</dd>
</dl>
<p>Do you have more ideas? Please write to
our <a href="mailto:freetype-devel@nongnu.org">mailing
list</a> so that we can discuss your suggestions,
eventually adding them to the list!</p>
</div>
<!-- ************************************************** -->
<div class="updated">
<p>Last update: 28-Feb-2017</p>
</div>
</div>
</div>
<!-- ************************************************** -->
<div class="col2">
</div>
</div>
</div>
<!-- ************************************************** -->
<div id="TOC">
<ul>
<li class="funding">
<p><a href="https://pledgie.com/campaigns/24434">
<img alt="Click here to lend your support to the FreeType project and make a donation at pledgie.com!"
src="https://pledgie.com/campaigns/24434.png?skin_name=chrome"
border="0"
align="middle">
</a></p>
<p><a href="https://flattr.com/submit/auto?fid=mq2xxp&url=https%3A%2F%2Fwww.freetype.org"
target="_blank">
<img class="with-border"
src="https://button.flattr.com/flattr-badge-large.png"
alt="Flattr this"
title="Flattr this"
border="0"
align="middle">
</a></p>
</li>
<li class="primary">
<a href="index.html">Home</a>
</li>
<li class="primary">
<a href="index.html#news">News</a>
</li>
<li class="primary">
<a href="freetype2/docs/index.html">Overview</a>
</li>
<li class="primary">
<a href="freetype2/docs/documentation.html">Documentation</a>
</li>
<li class="primary">
<a href="developer.html">Development</a>
</li>
<li class="primary">
<a href="contact.html"
class="emphasis">Contact</a>
</li>
<li>
<!-- separate primary from secondary entries -->
</li>
<li class="secondary">
<a href="gsoc.html" class="current">FreeType & GSoC</a>
</li>
</ul>
</div>
</div> <!-- id="wrapper" -->
<div id="TOC-bottom">
</div>
</body>
</html>
|
