Glyph Designer 2 1 – Bitmap Font Generator

1. Bitmap Font Generator Online
2. Free Bitmap Fonts
3. Glyph Designer 2 1 – Bitmap Font Generator Copy

The Glyph Bitmap Distribution Format (BDF) by Adobe is a file format for storing bitmap fonts. The content takes the form of a text file intended to be human- and computer-readable. BDF is typically used in UnixX Window environments. It has largely been replaced by the PCF font format which is somewhat more efficient, and by scalable fonts such as OpenType and TrueType fonts.

Overview[edit]

As of 2013 the current version of BDF is 2.2. No future revisions are anticipated. Earlier versions were referred to as the Character Bitmap Distribution Format.

We are 71Squared A UK based indie company making innovative Mac apps. Deep Dream Generator App for Mac. Bitmap font generator for Mac.

Glyph Designer is a powerful bitmap font designer. Create beautiful designs using highly configurable effects, definable backgrounds, custom images, editable glyph metrics and more. Make the most of your screen with smart zooming and full screen support. Up to three axes, any number of font masters, independent layers, glyph-based alternate and intermediate masters: You can do it all in Glyphs. Easily switch between masters, control outline compatibility and style linking, and generate a whole family in one go. A value of 1 means the pixel is within the glyph. One: All pixels in the channel will be set to 1. Zero: All pixels in the channel will be set to 0. Some of the more common choices are: 32bit white glyphs with black outline: alpha = outline, red = green = blue = glyph; 32bit white glyphs without outline: alpha = glyph, red = green = blue = one. On OSX there's Glyph Designer. Which cost money and the window version look crappy as hack! Can inkscape do bitmap font generator. Quote; Share this post.

In 1988, the X Consortium adopted BDF 2.1 as a standard for X Window screen fonts,^[1] but X Windows has largely moved to other font standards such as PCF, Opentype, and Truetype.

Version 2.2 added support for non-Western writing. For example, glyphs in a BDF 2.2 font definition can specify rendering from top-to-bottom rather than simply left-to-right.

A BDF font file contains three sections:

1. a global section that applies to all glyphs in a font;
2. a section with a separate entry for each glyph; and
3. the ENDFONT statement.

Example[edit]

This is an example font containing one glyph, for ASCII capital 'A'. This glyph is taken from the GNU Unifont.

In the above example, the global declarations begin with the 'STARTFONT' line and end with the 'CHARS' line.

'STARTFONT 2.1' defines the version of this BDF file as version 2.1.

'FONT -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1' defines the font family and face names as an X logical font description.

'SIZE 16 75 75' defines this to be a 16 point font, with an X-axis resolution of 75 dots per inch (dpi) and a Y-axis resolution of 75 dpi. This is the norm under X Window.

'FONTBOUNDINGBOX 16 16 0 -2' defines a bounding box for the font of 16 pixels wide by 16 pixels high, with the lower left-hand corner starting at x=0, y=-2. Note that although the bounding box is defined to be a 16 by 16 cell, this can be overridden for individual glyphs. The 'A' glyph, for example, is only 8 pixels wide.

'STARTPROPERTIES 2' declares that two special properties will follow. 'STARTPROPERTIES' is optional in the BDF specification. X Window allows the properties FONT_ASCENT and FONT_DESCENT to show the height above and below the baseline, respectively, for all glyphs. 'FONT_ASCENT 14' declares that 14 of the 16 pixels in height are above the baseline. 'FONT_DESCENT 2' declares that 2 of the 16 pixels in height are below the baseline. 'ENDPROPERTIES' appears at the end of the 'STARTPROPERTIES' section.

'CHARS 1' declares that one character will follow. Although Adobe now refers to this file format as the Glyph BDF, they have retained the keyword 'CHARS' in the final version of the specification.

Lines beginning with the word 'COMMENT' can be inserted within a BDF file. Anything following the 'COMMENT' keyword on a line is ignored.

Following the above global declarations, the following entries may repeat for each glyph.

'STARTCHAR U+0041' specifies the start of a character in version 2.1 and earlier, or of a glyph in version 2.2. The string name of this particular character is 'U+0041', expressing in the Unicode convention the code point hexadecimal 41 (decimal 65, the ASCII character 'A'). In version 2.1 and earlier, the character name string was limited to 14 characters. In version 2.2, the glyph name string can contain up to 65,535 characters.

'ENCODING 65' declares the decimal code point for this glyph in the font.

'SWIDTH 500 0' declares the Scalable Width of 500 on the X-axis and 0 (default) on the Y-axis. This will result in an X-axis offset to the next glyph, but no Y-axis offset to the next glyph (i.e., the glyphs appear straight across in a line). The scalable width is 1000 times the actual point size of the character—the same unit used in an Adobe Font Metric (AFM) file. The number of pixels calculated as

pixels = (scalable_width / 1000) * (resolution / 72),

where scalable_width is 500 in this example, and resolution is 75 dpi for this font. Because 75 is approximately equal to 72, the number of pixels is the full width of a glyph (defined globally as 16 pixels) times 500 / 1000, or in other words the width of this glyph is 8 pixels.

'DWIDTH 8 0' declares the Device Width of a glyph. In this case, after the glyph is rendered, the start of the next glyph is offset 8 pixels on the X-axis and 0 pixels on the Y-axis from the current glyph origin. Note that the Device Width is not necessarily equal to the width of the glyph. It is simply the offset on the X-axis to move the current point to the start of the next glyph.

The Scalable Width is used to calculate the width of a high-resolution glyph on a printer, whereas the Device Width is used to calculate the width of a glyph on a display device. Thus Scalable Width is specified to greater precision than Device Width. Mcafee endpoint protection 2 3 0.

'BBX 8 16 0 -2' declares a bounding box that is 8 pixels wide and 16 pixels tall. The lower left-hand corner of the character is offset by 0 pixels on the X-axis and -2 pixels on the Y-axis.

'BITMAP' begins the bitmap for the current glyph. This line must be followed by one line per pixel on the Y-axis. In this example the glyph is 16 pixels tall, so 16 lines follow. Each line contains the hexadecimal representation of pixels in a row. A '1' bit indicates a rendered pixel. Each line is rounded to an 8 bit (one byte) boundary, padded with zeroes on the right. In this example, the glyph is exactly 8 pixels wide, and so occupies exactly 8 bits (one byte) per line so that there is no padding. The most significant bit of a line of raster data represents the leftmost pixel.

'ENDCHAR' ends the current glyph.

The declarations 'STARTCHAR' through 'ENDCHAR' are repeated for each glyph in a font.

'ENDFONT' appears as the last line in the file, after all glyphs in the font have been enumerated.

Version 2.2 Extensions[edit]

Version 2.2 of the BDF specification adds support for non-Western fonts. These additions allow moving the origin by a positive or negative movement on the X and Y axes. This not only accommodates right-to-left writing direction, but even top-to-bottom (for example, for Chinese). The following values provide multinational-font support:

METRICSET: set to 0 for writing direction 0, 1 for writing direction 1, or 2 (in the initial global area) for both writing directions within the same font. Traditional Western left-to-right scripts use 'METRICSET 0'.

SWIDTH1, DWIDTH1: these have the same parameters as SWIDTH and DWIDTH, respectively. DWIDTH1 must be present for a METRICSET 1 glyph. Its offsets can be positive or negative.

VVECTOR defines an X-axis offset and a Y-axis offset to transition from a mode 0 glyph to a mode 1 glyph. An opposite offset is applied during a mode 1 to mode 0 glyph transition.

This scheme easily accommodates two writing directions. Historically, fonts had 128 or 256 code points. Today, Unicode allows for over one million code points. Fonts can conceivably contain thousands of glyphs, some of which should be written left-to-right, some right-to-left, and some top-to-bottom. Such multi-directional writing requires creative use of DWIDTH1 and SWIDTH1 for each glyph.

In addition to keywords added for international support, version 2.2 adds the 'CONTENTVERSION' declaration. This keyword is followed by an integer to indicate the version number of the font.

For more detailed information, consult the version 2.2 specification.

X Window Properties[edit]

X Window font utilities support several properties that can be specified in the STARTPROPERTIES section of a BDF file.^[2] A generic BDF file is in ASCII encoding. X Window properties are specified using ISO 8859-1 encoding, which is an extension of ASCII. These properties include:

• CAP_HEIGHT integer—the height above the baseline of a capital letter (See Cap height).
• COPYRIGHT string—a copyright statement.
• DEFAULT_CHAR positive—the default character (glyph) to display for an undefined glyph.
• FACE_NAME string—the name of the face for this font.
• FONT string—the X Window name of the font.
• FONT_ASCENT integer—the height above the baseline, for line spacing calculation.
• FONT_DESCENT integer—the descender below the baseline, for line spacing calculation.
• FONT_VERSION string—the version of the font.
• FOUNDRY string
• FAMILY_NAME string—the font family name.
• NOTICE string—a general comment.
• POINT_SIZE integer—See Point (typography). If it is not separately specified, EMspace = round(POINT_SIZE/10), ENspace = round(POINT_SIZE/20), and THINspace = round(POINT_SIZE/30).
• RESOLUTION_X positive
• RESOLUTION_Y positive
• SLANT string -- 'R' is Roman, 'I' is Italic, 'O' is Oblique, 'RI' is Reverse Italic, 'RO' is Reverse Oblique, 'OT' is Other and a number indicates polymorphic slant capability.
• WEIGHT_NAME string—the weight of this font ('Bold' and 'Normal' are typical, though there is no set enumeration).
• X_HEIGHT integer—the height above the baseline of a lower-case 'x' (See x-height).

..where 'integer' is a natural number, 'positive' is a positive number (of value 1 or higher), and 'string' is an ISO 8859-1 character string.

Notes[edit]

1. ^'X Window System, Version 11, Release 3'. X.Org Foundation. October 1988. Retrieved 19 January 2016.
2. ^Flowers, Jim (1994) [1988]. '3.2 Font Properties'. X Logical Font Description Conventions (Version 1.5 ed.). X Consortium, Inc. p. 13. Archived from the original on 2013-03-31. Retrieved 2009-01-08.Cite has empty unknown parameter: |month= (help)

References[edit]

• The Unicode Standard, Version 5.0. The Unicode Consortium (5th ed.). Addison-Wesley. October 2006. ISBN978-0-321-48091-0.CS1 maint: others (link)

External links[edit]

This table provides access to bitmap data in a standard graphics format, such as PNG, JPEG or TIFF.

The 'sbix' table has functionality somewhat similar to the EBDT table in that both provide bitmap data for glyph presentation. They are different in three important respects, however. First, whereas the EBDT table supports only black/white or grayscale bitmaps, the 'sbix' table supports color bitmaps. Secondly, whereas the EBDT table uses formats specific to the OpenType specification, the 'sbix' table uses standard bitmap graphics formats that are in common use. Thirdly, whereas the EBDT table must be used in conjunction with other tables (EBLC and EBSC) for processing the bitmap data, the 'sbix' table contains complete data required for processing bitmaps.

A font that includes an 'sbix' table may also include outline glyph data in a 'glyf' or 'CFF ' table. An 'sbix' table can provide bitmap data for all glyph IDs, or for only a subset of glyph IDs. A font can also include different bitmap data for different sizes ('strikes'), and the glyph coverage for one size can be different from that for another size.

Header

The 'sbix' table begins with a header:

'sbix' Header

For historical reasons, bit 0 of the flags field should always be set to 1.

If bit 1 of the flags field is clear, then the application is instructed to draw only the bitmaps for each glyph supported in the 'sbix' table. If bit 1 is set, then the application is instructed to draw the bitmap and the outline, in that order (that is, with the outline overlaid on top of the bitmap). If the 'sbix' table does not contain bitmap data for a glyph, then the outline is always drawn, regardless of the state of bit 1.

Note: Application support for bit 1 of the flags field is optional. Unite 3 0 12. To ensure the best compatibility, set this bit to 0.

Strikes

Each strike includes a header and the glyph bitmap data. The header has the following format:

The glyphDataOffset array includes offsets for every glyph ID, plus one extra. The number of glyphs is determined from the 'maxp' table. The length of the bitmap data for each glyph is variable, and can be determined from the difference between two consecutive offsets. Hence, the length of data for glyph N is glyphDataOffset[N+1] - glyphDataOffset[N]. If this is zero, there is no bitmap data for that glyph in this strike. There is one extra offset in the array in order to provide the length of data for the last glyph.

Note: The length of data for non-printing glyphs, such as space, should always be zero.

A strike does not need to include data for every glyph, and does not need to include data for the same set of glyphs as other strikes. If the application is using bitmap data to draw text and there is bitmap data for a glyph in any strike, then the glyph must be drawn using a bitmap from some strike. If the exact size is not available, implementations may choose a bitmap based on the closest available larger size, or the closest available integer-multiple larger size, or on some other basis. The only cases in which a glyph is not drawn using a bitmap are if the application has not requested that text be drawn using bitmap data or if there is no bitmap data for the glyph in any strike.

Each strike targets a specific PPEM size and device pixel density (PPI). Thus, a font can contain two strikes for the same PPEM but different pixel densities, or two strikes for the same pixel density but different PPEMs. Note that some platforms may not support targeting of strikes for particular pixel densities.

Glyph data

The data for each glyph includes a header and the actual, embedded graphic data, with the following format:

The originOffsetX and originOffsetY values give the placement of the bitmap graphic in relation to the standard coordinate system of the glyph design space. For example, if originOffsetX equals 20, the left edge of the bitmap is place 20 units to the right of the origin; if originOffsetY equals -30, then the bottom edge of the graphic is 30 FUnits below the origin.

When placing the graphic within the line of text, the placement depends upon whether there are contours in the 'glyf' table for the current glyph ID:

• If there is no glyph contour, the glyph design space origin for the graphic is placed at the starting drawing position for this glyph. The lsb value for the current glyph ID from the 'hmtx' table has no effect.

• If there is a glyph contour, the glyph design space origin for the graphic is placed at the lower left corner of the glyph bounding box (xMin, yMin).

The graphicType field indicates the format of the embedded graphic data. Three standard formats are supported: JPEG, PNG and TIFF; these are indicated using tag values 'jpg ', 'png ' and 'tiff', respectively.

The special graphicType of 'dupe' indicates that the data field contains a uint16, big-endian glyph ID. The bitmap data for the indicated glyph should be used for the current glyph.

Bitmap Font Generator Online

Note: Apple's specification for TrueType fonts allows for a graphicType tag value of 'pdf ' or 'mask'. These values are not supported in the OpenType specification, however.

Free Bitmap Fonts

Table dependencies

Glyph Designer 2 1 – Bitmap Font Generator Copy

The glyph count is derived from the 'maxp' table. Advance and side-bearing glyph metrics are stored in the 'hmtx' table for horizontal layout, and the 'vmtx' table for vertical layout.