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
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
|
Bitmap and Pixmap generation with FreeType
------------------------------------------
Table of Contents
Introduction
I. The rasterizer component
II. Bitmap & pixmap descriptors
III. Rendering an outline
IV. Anti-aliasing palette and other concerns
Conclusion
Introduction
------------
This document describes the steps that are needed to render a
glyph outline into a bitmap or a pixmap with the FreeType library.
It contains several important details needed to generate bitmaps
correctly in all situations, including if an outline has been
transformed or translated.
--------------------------------------------------------------------
I. The rasterizer component
---------------------------
In FreeType, the component in charge of performing bitmap and
pixmap rendering is called the `rasterizer'. Generation is
performed through a traditional process called `scan-line
conversion', but exhibits certain properties:
- The rasterizer doesn't allocate bitmaps:
In fact, it is only able to render an outline into an existing
bitmap or pixmap, which is passed to one of its rendering
functions. This means that the target bitmap/pixmap must be set
up correctly by the caller to achieve desired results. Setting
up bitmap and pixmap descriptors is explained in section II.
- It is able to render anti-aliased pixmaps directly:
This is unlike other graphics packages, which render to a
`large' bitmap which is then filtered down. Putting the
anti-aliasing logic within the rasterizer improves performance
and reduces memory usage, as well as lets us use better
algorithms which couldn't work in a `two-phase' process.
The rasterizer is located in the files `ttraster.h' and
`ttraster.c'.
The format of outlines isn't important for most developers and
won't be discussed here. However, a few conventions must be
explained regarding the vector outlines:
1. Units
All point coordinates within an outline are stored in 32-bit
fractional pixel values, using the 26.6 fixed float format
(which uses 26 bits for the integer part, and 6 bits for the
fractional part). The following table gives some examples of
real versus 26.6 coordinates:
-----------------------------------------
real real coord 26.6 coord
coord. * 2^6
-----------------------------------------
0 0*64 = 0.0 0
2.4 2.4*64 = 153.6 154
3 3*64 = 192.0 192
-1.7 -1.7*64 = -108.8 -109
As you can see, conversion is relatively simple -- basically a
multiplication by 64.
In order to differentiate coordinates expressed in real or 26.6
systems, we'll use in the following lines brackets (`[' and `]')
for real coordinates, and simple parentheses (`(' and `)') for
fractional coordinates so that
[1.0,2.5] equals (64,160)
[0,0] equals (0,0)
[-2,3] equals (-128,192)
2. Orientation
The rasterizer uses the traditional convention of an X axis
oriented from left to right, and of a Y axis oriented from
bottom to top.
^ Y
|
|
|
-*-----> X
|
You've probably already used it at school when doing math :-)
Though the orientation of bitmap lines has the opposite
direction on nearly all graphics systems, the former convention
is the _right_ one when it comes to vector graphics. The reason
is simply that for managing angles and vector cross-products
resp. orientations in complex algorithms, a single convention,
used in math as well as computing alike solves many headaches.
And due to education, most people expect a 45 degrees angle to
be in the top right quadrant, at coordinate (1,1).
3. Pixels and the grid
In a vector outline, a point is immaterial and has no size or
width, just like in usual geometry. A `pixel' is an element of
a computer image called a `map' (like a bitmap or a pixmap).
The FreeType rasterizer follows the convention defined by the
TrueType specification regarding pixel placement:
- The map can be seen as a `grid' placed in the vector plane.
The grid lines are set on integer real coordinates (i.e., on
multiples of 64 in 26.6 fractional notation).
Each pixel is one `cell' of the grid, and can be `lit' with
any color. Hence, each pixel has a width and a height of
[1.0] units, (i.e., 64 fixed float units).
^ Y
|
| The pixel grid with two
| points (not pixels!)
+-----+-----+-----+-----+-----+ at coordinates [0,0]
| | | | | | and [2,2].
| | | | | |
| | | | |[2,2]|
+-----+-----+-----+-----@-----+ The pixels are the
| | |11111|22222| | grid's cells, and this
| | |11111|22222| | example show the four
| | |11111|22222| | pixels enclosed within
+-----+-----+-----+-----+-----+ the rectangle delimited
| | |33333|44444| | by these two points.
| | |33333|44444| |
| | |33333|44444| |
--+-----+-----@-----+-----+-----+----> X
| | |[0,0]| | |
| | | | | | Note that the numbering
| | | | | | of pixels isn't
+-----+-----+-----+-----+-----+ meaningful here, it's
| | | | | | only used to distinguish
| | | | | | them.
| | | | | |
+-----+-----+-----+-----+-----+
|
|
- The `center' of each pixel is always located on a
`half-integer' coordinate, i.e., at -1.5, -0.5, 0.5, 1.5, etc.
- When drawing a shape, the rasterizer only `lits' a pixel when
its center is placed _within_ the shape. This is important
because an outline point may not be necessarily be on a grid
line.
- When a pixel center falls on the shape, the pixel is lit too.
For example, the following graphics show the `lit' pixels
corresponding to the rectangle enclosed by the points:
[-0.2, 0] and [2.4, 2.7]
^ Y As one can see, the
| newest pixels `1'
| and `2' are now lit,
| because its centers
+-----+-----+-----+-----+--[2.4,2.7] are located at
| | |11111|22222| @ | coordinates
| . | . |11.11|22.22| . | [0.5,2.5] and
| | |11111|22222| | [1.5,2.5],
+-----+-----+-----+-----+-----+ respectively.
| | |33333|44444| |
| . | . |33.33|44.44| . | Note that pixel
| | |33333|44444| | centers are
+-----+-----+-----+-----+-----+ represented with a
| | |55555|66666| | dot in the graphics.
| . | . |55.55|66.66| . |
| | |55555|66666| |
--+-----+----@+-----+-----+-----+----> X
| | [-0.2,0] | | |
| . | . | . | . | . |
| | | | | | Note also that pixel
+-----+-----+-----+-----+-----+ numbering is still
| | | | | | meaningless there.
| . | . | . | . | . |
| | | | | |
+-----+-----+-----+-----+-----+
|
|
4. Drop-out control
Sometimes, a stroke is too thin to even contain a single pixel
center. This results in `lost continuity' in the resulting
bitmap, i.e., some unpleasant `holes' or `breaks' in the
rendered shape, which are called a `drop-out'.
Because a glyph representation uses curves (Bezier arcs), this
case is not easily controllable during the `hinting' of glyph
outlines by the font driver, which means that the rasterizer
must be able to correct these `artefacts'.
This processing is called `drop-out control', and can be
performed in several modes, defined by the TrueType
specification, and which details do not belong to this document.
However, the important idea is that, in _some_ cases, a pixel
may be lit even if its center isn't part of the shape.
This case is relatively rare, but is mentioned because it has
consequences of the rendering of maps. More precisely, in the
way an outline's extent is computed (see below).
--------------------------------------------------------------------
II. Bitmap and pixmap descriptors
---------------------------------
The Freetype rasterizer only supports bitmaps and 8-bit pixmaps.
In order to render an outline, a map descriptor must be sent to
its rendering functions, along with a vectorial outline.
1. Bitmap properties
This section explains how to set up a bitmap descriptor, and how
vector coordinates in the outline plane relate to pixel
positions within the bitmap buffer.
A bitmap's `raw data' is made of a simple bit buffer where each
bit corresponds to a monochrome pixel. For the sake of
simplicity, the FreeType rasterizer uses the following
conventions to store bitmaps in a buffer:
- The value 0 is used for `unlit' pixels, usually the
`background' when rendering text. Hence 1 is used for `lit'.
- Lines are padded to 8 bits, i.e. bytes. A bitmap row thus
takes an integral number of bytes in its buffer. No further
alignment is required.
(Some systems compress bitmaps by _not_ padding bit rows to
byte boundaries. It is not possible to render into such a
bitmap buffer with FreeType.)
- In a bitmap buffer byte, the left-most pixel is represented by
the most significant bit (i.e., 0x80).
The opposite convention is not supported by the FreeType
rasterizer, though it may possibly be implemented too if this
ever comes useful (ask the developers -- for now, nobody did).
- Increasing offsets within a row correspond to right-most
positions in the bitmap (i.e., byte 1 contains the
8 bits/pixels that are located on the right of the
8 bits/pixels of byte 0).
- A bitmap can be oriented in two ways:
o If increasing row addresses within the buffer correspond to
lower vertical lines, the bitmap is said to go `down'. This
is, for example, the case of nearly all video RAMs.
o If increasing row addresses within the buffer correspond to
higher vertical lines, the bitmap is said to go `up'. This
is the case, for example, for OS/2 bitmaps.
The `direction' of a bitmap is called `flow' to avoid any
confusion. In both cases, the rasterizer ALWAYS matches the
vector coordinate (0,0) with the lower-left corner of the
*lower-left* pixel in the bitmap.
The following graphics illustrate these ideas:
Y ^
| A `down-flow' bitmap.
+--+--+--+--+--+--+--+--+ On the left is each
| | | | | | | | | row's number and its
0: 0 | | | | | | | | | offset in the bitmap
+--+--+--+--+--+--+--+--+ buffer (where `w' is
| | | | | | | | | the width, in bytes,
1: w | | | | | | | | | of a single bitmap
+--+--+--+--+--+--+--+--+ row). Note that the
| | | | | | | | | origin is located at
2: 2*w | | | | | | | | | the lower left, i.e.,
+--+--+--+--+--+--+--+--+ near the leftmost bit
| | | | | | | | | of the last bitmap
3: 3*w | | | | | | | | | row.
-@--+--+--+--+--+--+--+-----> X
|[0,0]
Y ^
| An `up-flow' bitmap.
+--+--+--+--+--+--+--+--+ On the left is each
| | | | | | | | | row's number and its
3: 3*w | | | | | | | | | offset in the bitmap
+--+--+--+--+--+--+--+--+ buffer (where `w' is
| | | | | | | | | the width, in bytes,
2: 2*w | | | | | | | | | of a single bitmap
+--+--+--+--+--+--+--+--+ row). Note that the
| | | | | | | | | origin is located at
1: w | | | | | | | | | the lower left, i.e.,
+--+--+--+--+--+--+--+--+ near the first bit in
| | | | | | | | | the buffer.
0: 0 | | | | | | | | | The first buffer bit
-@--+--+--+--+--+--+--+-----> X corresponds to the
|[0,0] rectangle [0,0]-[1,1]
in the vector plane.
2. Bitmap descriptors
Now that you understand all these details, a bitmap can be
described to the rasterizer engine through a map, which
structure must be set up by client application:
struct TT_Raster_Map_
{
int rows; /* number of rows */
int cols; /* number of columns (bytes) per row */
int width; /* number of pixels per line */
int flow; /* bitmap orientation */
void* bitmap; /* bit/pixmap buffer */
long size; /* bit/pixmap size in bytes */
};
typedef struct TT_Raster_Map_ TT_Raster_Map;
where the fields stand for:
rows:
The number of rows within the bitmap buffer.
cols:
The number of columns, i.e. bytes per row within the
buffer. It corresponds to the `w' value used in the above
graphics.
width:
The number of pixels (i.e. bits) per row in the buffer. The
rasterizer always clips its rendering to the bit width
specified in this field, even if the `cols' fields
corresponds to a larger width.
flow:
The bitmap flow. Use the constants TT_Flow_Up and
TT_Flow_Down exclusively for this field.
bitmap:
A typeless pointer to the bit buffer.
size:
The total size of the bit buffer in bytes. This is not used
directly by the rasterizer, so applications can use it.
Note that the `cols' field should always be bigger than the
value of `width' multiplied by 8. The rasterizer clips the
generated bitmap to the `width' first bits in a row.
Note also that it is of course allowed to create, for example, a
Windows or X11 bitmap through a normal system-specific API call,
using a TT_Raster_Map that describes it to the rasterizer. It
is thus possible to draw directly into such OS specific
structures.
IMPORTANT: *****************************************************
When rendering a bitmap, the rasterizer always OR-es the shape
on the target bitmap. It is thus possible to draw several
shapes into a single surface which successive calls to the
render functions.
****************************************************************
3. Pixmap properties
The rasterizer only supports 8-bit pixmaps, where one pixel is
represented by a single byte. They must conform to the
following rules:
- A 5-entries palette is used to generate an outline's pixmap in
the buffer. They correspond to:
palette[0] -> background
palette[1] -> `light'
palette[2] -> `medium'
palette[3] -> `dark'
palette[4] -> foreground
where the terms `light', `medium', and `dark' correspond to
intermediate values between the first (background) and last
(foreground) entry.
The upcoming FreeType 2.0 will feature an additional
anti-aliasing logic with a 17-entries palette.
- Lines are padded to 32 bits, i.e. 4 bytes. A pixmap row thus
takes a multiple of 4 bytes in its buffer.
- Increasing offsets within a row correspond to right-most
positions in the bitmap (i.e., byte/pixel 1 is to the right of
byte/pixel 0).
- A pixmap can be oriented in two ways, following the same rules
as a bitmap regarding its flow.
IMPORTANT: *****************************************************
In order to improve performance when rendering large outlines
with anti-aliasing, the rasterizer draws pixels in runs of
4-bytes ONLY when at least one of their `colour' isn't 0
(background).
This means that you should ALWAYS CLEAR the pixmap buffer before
calling the rendering function, you may otherwise experience
ugly artefacts, which are possibly left from a previous
rendering!
In general, it is not possible to do colour compositing with the
FreeType rasterizer (compositing is if you want to superpose a
transparent coloured layer on top of an image). This is mainly
due to the fact that:
- There are too many pixel formats to support.
- There is not a single portable way to do it anyway.
- It really is a graphics processing question, not one that
should be solved by a text rendering engine.
****************************************************************
4. Pixmap descriptors
Pixmaps use the same descriptor structure as bitmaps, with a few
differences in interpretation:
- The `cols' field is used to indicate the number of _bytes_ in
a pixmap row. It must thus be a multiple of 4!
- The rasterizer clips the outline to the first `width'
pixels/width within each buffer row.
As usual, it should be possible to use a system-specific pixmap
and render directly into it, as long as you set up a descriptor
for it.
-------------------------------------------------------------------------
III. Rendering an outline
-------------------------
Now that you understand how the rasterizer sees the target bitmaps
and pixmaps it renders to, this section will explain how the
rendering eventually happen.
1. Outline coordinates and extents
Let's first consider the case where we're rendering text
directly into a huge single bitmap. To do that, we simply
translate each glyph outline before calling the rasterizer.
Here the roadmap:
- Vectorial coordinates [0,0] are mapped to the lower left
`corner' (in the grid) of the lower left pixel in the bitmap
(whatever its flow is).
- When the glyph loader returns an outline, the latter is placed
so that the coordinate [0,0] corresponds to the current cursor
position.
This means that:
- If we use our own cursor (cx,cy) within the bitmap during text
rendering, we must translate the outline to its position
before rendering it, e.g. with
TT_Translate_Outline( outline, cx, cy )
(and the cursor position must be incremented after rendering
each glyph).
- Before translation (i.e., when it is returned by the glyph
loader), the glyph outline doesn't necessarily lie on any of
the coordinate axes, nor is it limited to the first quadrant
(i.e., x>0 and y>0 is not true in general).
Its extent can be computed with the function
TT_Get_Outline_BBox(), which returns the minimum and maximum
values of its X and Y point coordinates (in 26.6 format, of
course).
2. Computing an outline's dimensions in pixels
In many cases, however, it is much better to render individual
glyph bitmaps, then cache them with appropriate metrics in order
to render text much more quickly at a given point size.
To be able to render the smallest possible bitmap, the exact
outline's extent dimensions in pixel are required. Again a
roadmap:
- Get the outline's bounding box in vector coordinates:
Simply call the TT_Get_Outline_BBox() function which will
return the values of xMin, yMin, xMax, and yMax in vector
(i.e. fractional) coordinates.
- Grid-fit the bounding box:
Because of the way pixels are lit in the bitmaps relative to
the position of their `centers' within the shape (see
section I), it is necessary to align the values of xMin, xMax,
yMin, and yMax to the pixel grid in order to compute the width
and height of the resulting bitmap. This can be done with:
xMin = FLOOR ( xMin ); with FLOOR(x) == (x & -64)
xMax = CEILING( xMax ); CEILING(x) == ((x+63) & -64)
yMin = FLOOR ( yMin );
yMax = CEILING( yMax );
The extents in pixels can then be simply computed as:
pixel_width = (xMax - xMin) / 64;
pixel_height = (yMax - yMin) / 64;
Note that because of drop-out control, and because the
bounding box computed currently includes all Bezier control
points from the outline, the bitmap may be slightly larger
than necessary in some cases.
Some improvements are planned for FreeType 2.0; for now, you
should consider that finding the `exact' bitmap bounding box
requires to scan all `borders' to detect null columns or rows.
However, the values are right in most cases.
NOTE: It seems that in some *rare* cases, which relate to
weird drop-out control situations, the above dimensions
are not enough to store all bits from the outline (there
are one or more bits `cut' on the edge).
This being hard to study (it only appears in very poorly
hinted fonts), we leave this problem to FreeType 2.0.
- Create/setup a bitmap with the computed dimensions. DON'T
FORGET TO CLEAR ITS BUFFER TOO!
- Translate the outline to stick within the bitmap space. This
is done easily by translating it by (-xMin,-yMin), where you
should ALWAYS USE THE GRID-FITTED VALUES computed above for
xMin and yMin:
TT_Translate_Outline( outline, -xMin, -yMin );
IMPORTANT: ***************************************************
For technical reasons, you should never translate a HINTED
outline by a non-integer vector (i.e., a vector which
coordinates aren't multiples of 64)! This would CERTAINLY
completely RUIN the delicate HINTING of the glyph, and will
result probably in pure GARBAGE at small point sizes.
Of course, if you're not interested in hinting, like when
displaying rotated text, you can ignore this rule and
translate to any position freely.
**************************************************************
- Render the bitmap (or pixmap).
DON'T FORGET TO STORE THE GRID-FITTED xMin and yMin WITH THE
BITMAP! This will allow you later to place it correctly
relative to your cursor position.
Here's some example pseudo code:
{
... load the glyph ...
TT_Outline outline;
TT_BBox bbox;
TT_Raster_Map bitmap;
/* get the outline */
TT_Get_Glyph_Outline( glyph, &outline );
/* compute its extent */
TT_Get_Outline_BBox( &outline, &bbox );
/* Grid-fit it */
bbox.xMin &= -64;
bbox.xMax = ( bbox.xMax + 63 ) & -64;
bbox.yMin &= -64;
bbox.yMax = ( bbox.yMax + 63 ) & -64;
/* compute pixel dimensions */
width = (bbox.xMax - bbox.xMin) / 64;
height = (bbox.yMax - bbox.yMin) / 64;
/* set up bitmap */
bitmap.rows = height;
bitmap.width = width;
bitmap.cols = (width + 7) / 8;
bitmap.size = bitmap.rows * bitmap.cols;
bitmap.bitmap = malloc( bitmap.size );
if ( !bitmap.bitmap )
return error_memory...
/* clear the bitmap buffer! */
memset( bitmap.bitmap, 0, bitmap.size );
/* translate outline */
TT_Translate_Outline( &outline, -bbox.xMin, -bbox.yMin );
/* render it within the bitmap */
TT_Get_Outline_Bitmap( engine, &outline, &bitmap );
/* We're done; don't forget to save bbox.xMin and */
/* bbox.yMin to adjust the bitmap position when */
/* rendering text with it */
...
}
3. The case of transformed/rotated glyphs:
You may want to apply a transformation other than a translation
to your glyph outlines before rendering them. For example, a
simple slant to synthesize italics, or a slight rotation.
In all cases, it is possible to render individual glyph bitmaps.
Just make sure to follow the same process AFTER you have
transformed you outline!
DON'T FORGET THAT YOU NEED TO RE-COMPUTE THE BBOX TO GET THE
CORRECT PIXEL DIMENSIONS AFTER A TRANSFORMATION.
--------------------------------------------------------------------
IV. Anti-aliasing palette and other concerns
When rendering pixmaps, using the TT_Get_Outline_Pixmap() or
TT_Get_Glyph_Pixmap() functions, the rasterizer uses a 5-entries
palette of 8-bit deep `colors'.
By default, this palette is set to ( 0, 1, 2, 3, 4 ), but one can
change it to suit your needs with TT_Set_Raster_Palette().
While in bitmap mode, it simply OR-es the pixel values to the
target bitmap that has been passed to TT_Get_Outline_Bitmap().
For pixmaps it simply writes directly the palette entries
corresponding to the `color' of the `lit' pixels it has computed.
This means that it is NOT POSSIBLE to render text in a single
pixmap with multiple calls to TT_Get_Outline_Pixmaps() within the
same target!
The reason is that `gray' pixels of two distinct outlines are not
`added' when they overlap (the operation called 'compositing'), as
it could be expected by applications.
The following graphic shows this effect when rendering two
overlapping anti-aliased shapes:
*** ***
.** .**
** **. **. **
.*. .*.. .*..*.
.*. + .*. = ---> ..*.
.*. ** | .*. **
** | **
**. | **.
*** | ***
|
missing black pixel after second
rendering...
There is no simple way to perform a composition within the
rasterizer. This would not be portable; moreover, it would be
extremely slow if it is too general. This operation is thus left
to client applications which can use their own system-specific API
for transparently blitting the glyph pixmaps into a surface to
form text.
NOTE:
If your system doesn't support transparent/alpha blits, you can
still have a look at the source file `freetype/test/display.c'.
It uses a large pixmap, with a special palette trick to render all
text quickly, then convert everything to `real' colors for
display.
--------------------------------------------------------------------
Conclusion
----------
We've seen how the FreeType rasterizer sees bitmaps through
descriptors, as well as the mapping which exists between the
vector coordinate space and the pixel position space.
You should now be able to render outlines into bitmaps and pixmaps
while applying transformations like translation, slanting, or
rotation. Don't forget a few rules, however:
- Always clear the bitmap/pixmap buffer before rendering (unless
you want to render several glyphs in a single _bitmap_; it won't
work on a pixmap).
- A pixmap `cols' field, i.e. the size in bytes of each rows, must
be a multiple of 4.
- Never translate a hinted outline by a non-integer vector if you
want to preserve the hints (i.e., the vector's coordinates must
be multiples of 64).
- Finally, don't expect the rasterizer to composite transparent
`grays' for you in a single target pixmap through multiple
calls.
--- end of bitmaps.txt ---
|