minhngoc25a
/
freetype2
mirror of git://git.savannah.gnu.org/freetype/freetype2.git
2
1
Fork 2
Code Issues 4 Releases Wiki Activity

Renamed "glyph_conventions.html" to "index.html" 

Updated all image references to the new PNGs

Note that this document is slightly out-of-date though..
(FT_Raster_Map was changed for FT_Bitmap, and the anti-alias renderer
 now supports 128 levels by default).
This commit is contained in:
David Turner 2000-01-11 02:20:22 +00:00
parent ee71c6b715
commit 41a8fa57b1
1 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
docs/glyph_conventions/glyph_conventions.html → docs/glyph_conventions/index.html
View File

@ -242,7 +242,7 @@ This explains why the letters of the following text have not the same height,
even though they're displayed at the same point size with distinct fonts
:</i>
<center>
<p><img SRC="body_comparison.gif" height=40 width=580></center>
<p><img SRC="body_comparison.png" height=40 width=580></center>
<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
@ -443,14 +443,14 @@ even for right-to-left oriented alphabets, like Arabic. This introduces
some differences in the way text is rendered.
<p>IMPORTANT NOTE:&nbsp; The pen position is always placed on the baseline.</ul>
<center><img SRC="Image1.gif" height=179 width=458></center>
<center><img SRC="Image1.png" height=179 width=458></center>
<ul>
<li>
with a vertical layout, glyphs are centered around the baseline:</li>
</ul>
<center><img SRC="Image2.gif" height=275 width=162></center>
<center><img SRC="Image2.png" height=275 width=162></center>
<p><br>
<h3>
@ -545,11 +545,11 @@ number.</ul>
<p>Here is a picture giving all the details for horizontal metrics :
<center>
<p><img SRC="Image3.gif" height=253 width=388></center>
<p><img SRC="Image3.png" height=253 width=388></center>
<p>And here is another one for the vertical metrics :
<center>
<p><img SRC="Image4.gif" height=278 width=294></center>
<p><img SRC="Image4.png" height=278 width=294></center>
</ul>
<h3>
@ -674,12 +674,12 @@ glyphs sometimes seem a bit too close or too distant. For example, the
space between the 'A' and the 'V' in the following word seems a little
wider than needed.
<center>
<p><img SRC="bravo_unkerned.gif" height=37 width=116></center>
<p><img SRC="bravo_unkerned.png" height=37 width=116></center>
<p>Compare this to the same word, when the distance between these two letters
has been slightly reduced :
<center>
<p><img SRC="bravo_kerned.gif" height=37 width=107></center>
<p><img SRC="bravo_kerned.png" height=37 width=107></center>
<p>As you can see, this adjustment can make a great difference. Some font
faces thus include a table containing kerning distances for a set of given
@ -721,14 +721,14 @@ a kerning distance between capital letters like "T" or "F" and a following
dot ("."), in order to slide the latter glyph just right to their main
leg. I.e.
<center>
<p><img SRC="twlewis1.gif" height=38 width=314></center>
<p><img SRC="twlewis1.png" height=38 width=314></center>
<p>However, this sometimes requires additional adjustments between the
dot and the letter following it, depending on the shapes of the enclosing
letters. When applying "standard" kerning adjustments, the previous sentence
would become :
<center>
<p><img SRC="twlewis2.gif" height=36 width=115></center>
<p><img SRC="twlewis2.png" height=36 width=115></center>
<p>Which clearly is too contracted. The solution here, as exhibited in
the first example is to only slide the dots when possible. Of course, this
@ -1093,21 +1093,21 @@ contour, even though no current font driver produces such outlines.
<center><table>
<tr>
<td>
<blockquote><img SRC="points_segment.gif" height=166 width=221></blockquote>
<blockquote><img SRC="points_segment.png" height=166 width=221></blockquote>
</td>
<td>
<blockquote><img SRC="points_conic.gif" height=183 width=236></blockquote>
<blockquote><img SRC="points_conic.png" height=183 width=236></blockquote>
</td>
</tr>
<tr>
<td>
<blockquote><img SRC="points_cubic.gif" height=162 width=214></blockquote>
<blockquote><img SRC="points_cubic.png" height=162 width=214></blockquote>
</td>
<td>
<blockquote><img SRC="points_conic2.gif" height=204 width=225></blockquote>
<blockquote><img SRC="points_conic2.png" height=204 width=225></blockquote>
</td>
</tr>
</table></center>
@ -1189,9 +1189,9 @@ it in most cases.
<br>&nbsp;
<center><table>
<tr>
<td><img SRC="bbox1.gif" height=264 width=228></td>
<td><img SRC="bbox1.png" height=264 width=228></td>
<td><img SRC="bbox2.gif" height=229 width=217></td>
<td><img SRC="bbox2.png" height=229 width=217></td>
</tr>
</table></center>
@ -1343,9 +1343,9 @@ X11 bitmap buffer, one should always use a down flow in the bitmap descriptor.
<br>&nbsp;
<center><table>
<tr>
<td><img SRC="up_flow.gif" height=298 width=291></td>
<td><img SRC="up_flow.png" height=298 width=291></td>
<td><img SRC="down_flow.gif" height=298 width=313></td>
<td><img SRC="down_flow.png" height=298 width=313></td>
</tr>
<tr>
@ -1377,7 +1377,7 @@ its center being at location (0.5,0.5).
the "<i>length</i>" in pixels of the line [0,0]-[10,0] is 11. However,
the vectorial distance between (0,0)-(10,0) covers exactly 10 pixel centers,
hence its length if 10.
<center><img SRC="grid_1.gif" height=390 width=402></center>
<center><img SRC="grid_1.png" height=390 width=402></center>
</blockquote>
<h3>
@ -1432,7 +1432,7 @@ the last image shows what will really be rendered in the bitmap.</li>
</ul>
</ul>
<center><img SRC="clipping.gif" height=151 width=539></center>
<center><img SRC="clipping.png" height=151 width=539></center>
<p><br>
<br>