Linux ip-148-66-134-25.ip.secureserver.net 3.10.0-1160.119.1.el7.tuxcare.els10.x86_64 #1 SMP Fri Oct 11 21:40:41 UTC 2024 x86_64
Apache
: 148.66.134.25 | : 3.141.12.30
66 Domain
8.0.30
amvm
www.github.com/MadExploits
Terminal
AUTO ROOT
Adminer
Backdoor Destroyer
Linux Exploit
Lock Shell
Lock File
Create User
CREATE RDP
PHP Mailer
BACKCONNECT
UNLOCK SHELL
HASH IDENTIFIER
CPANEL RESET
BLACK DEFEND!
README
+ Create Folder
+ Create File
/
usr /
share /
doc /
freetype-devel-2.8 /
glyphs /
[ HOME SHELL ]
Name
Size
Permission
Action
bbox1.png
1.43
KB
-rw-r--r--
bbox2.png
1.22
KB
-rw-r--r--
body_comparison.png
1.24
KB
-rw-r--r--
bravo_kerned.png
470
B
-rw-r--r--
bravo_unkerned.png
479
B
-rw-r--r--
clipping.png
1.45
KB
-rw-r--r--
down_flow.png
846
B
-rw-r--r--
glyphs-1.html
9.73
KB
-rw-r--r--
glyphs-2.html
18.15
KB
-rw-r--r--
glyphs-3.html
15.87
KB
-rw-r--r--
glyphs-4.html
8.55
KB
-rw-r--r--
glyphs-5.html
13.49
KB
-rw-r--r--
glyphs-6.html
19.04
KB
-rw-r--r--
glyphs-7.html
12.76
KB
-rw-r--r--
grid_1.png
1.61
KB
-rw-r--r--
index.html
8.15
KB
-rw-r--r--
layout.png
2.16
KB
-rw-r--r--
layout2.png
672
B
-rw-r--r--
metrics.png
2.16
KB
-rw-r--r--
metrics2.png
1.81
KB
-rw-r--r--
points_conic.png
704
B
-rw-r--r--
points_conic2.png
1.01
KB
-rw-r--r--
points_cubic.png
790
B
-rw-r--r--
points_segment.png
520
B
-rw-r--r--
twlewis1.png
668
B
-rw-r--r--
twlewis2.png
453
B
-rw-r--r--
up_flow.png
796
B
-rw-r--r--
Delete
Unzip
Zip
${this.title}
Close
Code Editor : glyphs-2.html
<!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="FreeType Documentation"> <meta name="Author" content="David Turner"> <link rel="icon" href="../image/favicon_-90.ico"> <link rel="shortcut icon" href="../image/favicon_-90.ico"> <link rel="stylesheet" type="text/css" href="../css/freetype2_-90.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>FreeType Glyph Conventions / II</title> </head> <body> <div id="top" class="bar"> <h1><a href="http://freetype.org/index.html">FreeType</a> Glyph Conventions / II</h1> </div> <div id="wrapper"> <div class="colmask leftmenu"> <div class="colright"> <div class="col1wrap"> <div class="col1"> <!-- ************************************************** --> <div id="glyph-outlines"> <h2>II. Glyph Outlines</h2> <p>This section describes the way scalable representations of glyph images, called outlines, are used by FreeType as well as client applications.</p> <h3 id="section-1">1. Pixels, points, and device resolutions</h3> <p>Though it is a very common assumption when dealing with computer graphics programs, the physical dimensions of a given pixel (be it for screens or printers) are not squared. Often, the output device exhibits varying resolutions in both horizontal and vertical directions, and this must be taken care of when rendering text.</p> <p>It is thus common to define a device's characteristics through two numbers expressed in <em>dpi</em> (dots per inch). For example, a printer with a resolution of 300×600 dpi has 300 pixels per inch in the horizontal direction, and 600 in the vertical one. The resolution of a typical computer monitor varies with its size (10″ and 25″ monitors don't have the same pixel sizes at 1024×768), and of course the graphics mode resolution.</p> <p>As a consequence, the size of text is usually given in <em>points</em>, rather than device-specific pixels. Points are a <em>physical</em> unit, where 1 point equals 1/72th of an inch in digital typography. As an example, most books using the Latin script are printed with a body text size somewhere between 10 and 14 points.</p> <p>It is thus possible to compute the size of text in pixels from the size in points with the following formula:</p> <center> <code>pixel_size = point_size * resolution / 72</code> </center> <p>The resolution is expressed in <em>dpi</em>. Since horizontal and vertical resolutions may differ, a single point size usually defines a different text width and height in pixels.</p> <p><em>Unlike what is often thought, the ‘size of text in pixels’ is not directly related to the real dimensions of characters when they are displayed or printed. The relationship between these two concepts is a bit more complex and depends on some design choices made by the font designer. This is described in more detail in the next sub-section (see the explanations on the EM square).</em></p> <h3 id="section-2">2. Vectorial representation</h3> <p>The source format of outlines is a collection of closed paths called <em>contours</em>. Each contour delimits an outer or inner <em>region</em> of the glyph, and can be made of either <em>line segments</em> or <em>Bézier arcs</em>.</p> <p>The arcs are defined through <em>control points</em>, and can be either second-order (these are <em>conic</em> Béziers) or third-order (<em>cubic</em> Béziers) polynomials, depending on the font format. Note that conic Béziers are usually called <em>quadratic</em> Béziers in the literature. Hence, FreeType associates each point of the outline with flags to indicate its type (normal or control point). As a consequence, scaling the points will scale the whole outline.</p> <p>Each glyph's original outline points are located on a grid of indivisible units. The points are usually stored in a font file as 16-bit integer grid coordinates, with the grid's origin being at (0,0); they thus range from -32768 to 32767. (Even though point coordinates can be floats in other formats such as Type 1, we will restrict our analysis to integer values for simplicity).</p> <p><em>The grid is always oriented like the traditional mathematical two-dimensional plane, i.e., the <i>X</i> axis goes from the left to the right, and the <i>Y</i> axis from bottom to top.</em></p> <p>In creating the glyph outlines, a type designer uses an imaginary square called the <em>EM square</em>. Typically, the EM square can be thought of as a tablet on which the characters are drawn. The square's size, i.e., the number of grid units on its sides, is very important for two reasons:</p> <ul> <li> <p>It is the reference size used to scale the outlines to a given text dimension. For example, a size of 12pt at 300×300 dpi corresponds to 12*300/72 = 50 pixels. This is the size the EM square would appear on the output device if it was rendered directly. In other words, scaling from grid units to pixels uses the formula:</p> <p align="center"> <code>pixel_size = point_size * resolution / 72</code><br> <code>pixel_coord = grid_coord * pixel_size / EM_size</code> </p> <p>Another acronym used for the pixel size is <em>ppem</em> (pixel per EM); this value can be fractional also. Note that fractional ppem values are not supported everywhere.</p> </li> <li> <p>The greater the EM size is, the larger resolution the designer can use when digitizing outlines. For example, in the extreme example of an EM size of 4 units, there are only 25 point positions available within the EM square which is clearly not enough. Typical TrueType fonts use an EM size of 2048 units; Type 1 or CFF PostScript fonts traditionally use an EM size of 1000 grid units (but point coordinates can be expressed as floating values).</p> </li> </ul> <p>Note that glyphs can freely extend beyond the EM square if the font designer wants so. The EM square is thus just a convention in traditional typography.</p> <p>Grid units are very often called <em>font units</em> or <em>EM units</em>.</p> <p><em>As said before, <code>pixel_size</code> computed in the above formula does not directly relate to the size of characters on the screen. It simply is the size of the EM square if it was to be displayed. Each font designer is free to place its glyphs as it pleases him within the square. This explains why the letters of the following text have not the same height, even though they are displayed at the same point size with distinct fonts:</em></p> <p align="center"> <img src="body_comparison.png" height="40" width="580" alt="Comparison of font heights"> </p> <p>As one can see, the glyphs of the Courier family are smaller than those of Times New Roman, which themselves are slightly smaller than those of Arial, even though everything is displayed or printed at a size of 16 points. This only reflects design choices.</p> <h3 id="section-3">3. Hinting and Bitmap rendering</h3> <p>The outline as stored in a font file is called the ‘master’ outline, as its point coordinates are expressed in font units. Before it can be converted into a bitmap, it must be scaled to a given size and resolution. This is done with a very simple transformation, but especially at small sizes undesirable artifacts can appear, in particular stems of different width or height in letters like ‘E’ or ‘H’ can occur.</p> <p>As a consequence, proper glyph rendering needs the scaled points to be aligned along the target device pixel grid, through an operation called <em>grid-fitting</em> (often called <em>hinting</em>). One of its main purposes is to ensure that important widths and heights are respected throughout the whole font (for example, it is very often desirable that the ‘I’ and the ‘T’ glyphs have their central vertical line of the same pixel width), as well as to manage features like stems and overshoots, which can cause problems at small pixel sizes.</p> <p>There are several ways to perform grid-fitting properly; most scalable formats associate some control data or programs with each glyph outline. Here is an overview:</p> <ul> <li class="emph"> <p>explicit grid-fitting</p> <p>The TrueType format defines a stack-based virtual machine, for which programs (also called <em>bytecode</em>) can be written with the help of more than 200 operators, most of them related to geometrical operations. Each glyph is thus made of both an outline and a control program to perform the actual grid-fitting in the way defined by the font designer.</p> </li> <li class="emph"> <p>implicit grid-fitting (also called hinting)</p> <p>The Type 1, CFF, and CFF2 formats take a much simpler approach: Each glyph is made of an outline as well as several pieces called <em>hints</em> which are used to describe some important features of the glyph, like the presence of stems, some width regularities, and the like. There aren't a lot of hint types, and it is up to the final renderer to interpret the hints in order to produce a fitted outline.</p> </li> <li class="emph"> <p>automatic grid-fitting</p> <p>Some formats include no control information with each glyph outline, apart from font metrics like the advance width and height. It is then up to the renderer to ‘guess’ the more interesting features of the outline in order to perform some decent grid-fitting.</p> </li> </ul> <p>The following table summarizes the pros and cons of each scheme.</p> <table> <thead> <tr> <th align="center"> <b>grid-fitting scheme</b> </th> <th align="center"> <b>advantages</b> </th> <th align="center"> <b>disadvantages</b> </th> </tr> </thead> <tbody> <tr> <td valign="top" align="center"> <p><b>explicit</b></p> </td> <td valign="top"> <p><b>Quality.</b> Excellent results at small sizes are possible. This is very important for screen display.</p> <p><b>Consistency.</b> All renderers produce the same glyph bitmaps (at least in theory).</p> </td> <td valign="top"> <p><b>Speed.</b> Interpreting bytecode can be slow if the glyph programs are complex.</p> <p><b>Size.</b> Glyph programs can be long.</p> <p><b>Technical difficulty.</b> It is extremely difficult to write good hinting programs. Very few tools available.</p> </td> </tr> <tr> <td valign="top" align="center"> <p><b>implicit</b></p> </td> <td valign="top"> <p><b>Size.</b> Hints are usually much smaller than explicit glyph programs.</p> <p><b>Speed.</b> Grid-fitting is usually a fast process.</p> </td> <td valign="top"> <p><b>Quality.</b> Often questionable at small sizes. Better with anti-aliasing though.</p> <p><b>Inconsistency.</b> Results can vary between different renderers, or even distinct versions of the same engine.</p> </td> </tr> <tr> <td valign="top" align="center"> <p><b>automatic</b></p> </td> <td valign="top"> <p><b>Size.</b> No need for control information, resulting in smaller font files.</p> <p><b>Speed.</b> Depends on the grid-fitting algorithm. Usually faster than explicit grid-fitting.</p> </td> <td valign="top"> <p><b>Quality.</b> Often questionable at small sizes. Better with anti-aliasing though.</p> <p><b>Speed.</b> Depends on the grid-fitting algorithm.</p> <p><b>Inconsistency.</b> Results can vary between different renderers, or even distinct versions of the same engine.</p> </td> </tr> </tbody> </table> </div> <!-- ************************************************** --> <div class="updated"> <p>Last update: 02-May-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="http://freetype.org/index.html">Home</a> </li> <li class="primary"> <a href="http://freetype.org/index.html#news">News</a> </li> <li class="primary"> <a href="../index.html">Overview</a> </li> <li class="primary"> <a href="../documentation.html">Documentation</a> </li> <li class="primary"> <a href="http://freetype.org/developer.html">Development</a> </li> <li class="primary"> <a href="http://freetype.org/contact.html" class="emphasis">Contact</a> </li> <li> <!-- separate primary from secondary entries --> </li> <li class="secondary"> <a href="index.html">FreeType Glyph Conventions</a> </li> <li class="tertiary"> <a href="glyphs-1.html">Basic Typographic Concepts</a> </li> <li class="tertiary"> <a href="glyphs-2.html" class="current">Glyph Outlines</a> </li> <li class="tertiary"> <a href="glyphs-3.html">Glyph Metrics</a> </li> <li class="tertiary"> <a href="glyphs-4.html">Kerning</a> </li> <li class="tertiary"> <a href="glyphs-5.html">Text Processing</a> </li> <li class="tertiary"> <a href="glyphs-6.html">FreeType Outlines</a> </li> <li class="tertiary"> <a href="glyphs-7.html">FreeType Bitmaps</a> </li> </ul> </div> </div> <!-- id="wrapper" --> <div id="TOC-bottom"> </div> </body> </html>
Close