Graphics Library and Text - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:13:16Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

Steven Solie: /* About Amiga Fonts */

2016-10-18T23:09:25Z

About Amiga Fonts

← Older revision		Revision as of 23:09, 18 October 2016
Line 10:		Line 10:
	Fonts are broken up into different font families. For example, the Amiga's Topaz is a font family. Each font family shares a basic look but can have a variety of styles and point sizes.		Fonts are broken up into different font families. For example, the Amiga's Topaz is a font family. Each font family shares a basic look but can have a variety of styles and point sizes.

	The style of a font refers to a minor alteration in the way the plain version of the font's characters are rendered. Currently, the Amiga supports three font styles: '''bold''', ''italics'' and underline (the font's style may also be considered plain when it does not have any of these styles). Although these styles can be inherent to a font, they are normally added algorithmically as text is rendered.		The style of a font refers to a minor alteration in the way the plain version of the font's characters are rendered. Currently, the Amiga supports three font styles: '''bold''', ''italics'' and <u>underline</u> (the font's style may also be considered plain when it does not have any of these styles). Although these styles can be inherent to a font, they are normally added algorithmically as text is rendered.

	On the Amiga, the point size of a font normally refers to the height of the font in pixels. For example, Topaz-8 is 8 pixels high. Because the size of Amiga pixels varies between display modes, the appearance of a font will also vary between display modes. Future versions of the Amiga OS may measure font size in other units. For example, the standard point in the PostScript page description language normally refers to a point as being a square dot that is 1/72 of an inch on a side. Using a standard measuring unit such as the PostScript point makes it possible to create a WYSIWYG (What You See Is What You Get) display that exactly matches printer or other device output.		On the Amiga, the point size of a font normally refers to the height of the font in pixels. For example, Topaz-8 is 8 pixels high. Because the size of Amiga pixels varies between display modes, the appearance of a font will also vary between display modes. Future versions of the Amiga OS may measure font size in other units. For example, the standard point in the PostScript page description language normally refers to a point as being a square dot that is 1/72 of an inch on a side. Using a standard measuring unit such as the PostScript point makes it possible to create a WYSIWYG (What You See Is What You Get) display that exactly matches printer or other device output.

Steven Solie: /* What Fonts Are Available? */

2015-11-06T20:53:21Z

What Fonts Are Available?

← Older revision		Revision as of 20:53, 6 November 2015
Line 1,317:		Line 1,317:
	/* the window. This prevents the application from unnecessarily */		/* the window. This prevents the application from unnecessarily */
	/* rendering beyond the bounds of the inner part of the window. For */		/* rendering beyond the bounds of the inner part of the window. For */
	/* more information on clipping, see the Layers ~~chapter of this manual~~. */		/* more information on clipping, see the Layers article. */

	if ((new_region = IGraphics->NewRegion())) /* More layers stuff */		if ((new_region = IGraphics->NewRegion())) /* More layers stuff */

Steven Solie: /* Font Aspect Ratio Example */

2015-11-06T20:52:59Z

Font Aspect Ratio Example

← Older revision		Revision as of 20:52, 6 November 2015
Line 882:		Line 882:
	myrectangle.MaxY = mywin->Height - /* using text. For more information */		myrectangle.MaxY = mywin->Height - /* using text. For more information */
	(mywin->BorderBottom + 1); /* on clipping regions and layers, see */		(mywin->BorderBottom + 1); /* on clipping regions and layers, see */
	/* the Layers ~~chapter of this manual~~. */		/* the Layers article. */

	if (new_region = IGraphics->NewRegion()) /* more layers stuff */		if (new_region = IGraphics->NewRegion()) /* more layers stuff */

Steven Solie: /* Font Scaling and Aspect Ratio */

2015-11-06T20:52:19Z

Font Scaling and Aspect Ratio

← Older revision		Revision as of 20:52, 6 November 2015
Line 649:		Line 649:
	The Amiga has a place to store a font's ''X'' and ''Y'' DPI values once the font is loaded into memory, but where do these X and Y values come from? A font's ''X'' and ''Y'' DPI values can come from several sources. The ''X'' and ''Y'' DPI can come from a font's disk-based representation, or it can be set by the programmer.		The Amiga has a place to store a font's ''X'' and ''Y'' DPI values once the font is loaded into memory, but where do these X and Y values come from? A font's ''X'' and ''Y'' DPI values can come from several sources. The ''X'' and ''Y'' DPI can come from a font's disk-based representation, or it can be set by the programmer.

	For the traditional Amiga bitmap fonts, in order to store the X and Y DPI values in a bitmap font's ".font" file, the structures that make up the ".font" file had to be expanded slightly. See the discussion of the FontContentsHeader structure in ~~the "~~Composition of a Bitmap Font on Disk" ~~section~~ ~~later~~ in ~~this~~ ~~chapter~~ for more information. Currently, out of all the system standard bitmap fonts (those loaded from bitmaps on disk or ROM, not scaled from a bitmap or outline), only one has a built in aspect ratio: Topaz-9.		For the traditional Amiga bitmap fonts, in order to store the X and Y DPI values in a bitmap font's ".font" file, the structures that make up the ".font" file had to be expanded slightly. See the discussion of the FontContentsHeader structure in [[#Composition of a Bitmap Font on Disk\|Composition of a Bitmap Font on Disk]] for more information. Currently, out of all the system standard bitmap fonts (those loaded from bitmaps on disk or ROM, not scaled from a bitmap or outline), only one has a built in aspect ratio: Topaz-9.

	For the Compugraphic outline fonts, the ''X'' and ''Y'' DPI values are built into the font outline. Because the format of the Compugraphic outline fonts is proprietary, information about their layout is available only from AGFA Compugraphic. For most people, the format of the outline fonts is not important, as the diskfont.library handles converting the fonts to an Amiga-usable form.		For the Compugraphic outline fonts, the ''X'' and ''Y'' DPI values are built into the font outline. Because the format of the Compugraphic outline fonts is proprietary, information about their layout is available only from AGFA Compugraphic. For most people, the format of the outline fonts is not important, as the diskfont.library handles converting the fonts to an Amiga-usable form.

Steven Solie: /* The Composition of a Bitmap Font on Disk */

2015-11-06T20:51:33Z

The Composition of a Bitmap Font on Disk

← Older revision		Revision as of 20:51, 6 November 2015
Line 1,677:		Line 1,677:
	The ctf_CharData[] fields is an array of pointers to each of the bitplanes of the color font data.		The ctf_CharData[] fields is an array of pointers to each of the bitplanes of the color font data.

	== ~~The~~ Composition of a Bitmap Font on Disk ==		== Composition of a Bitmap Font on Disk ==

	For each Amiga bitmap font stored on disk (normally in the FONTS: assign directory), there is a corresponding ".font" file, a directory, and within that directory, a series of files bearing numeric names. For example, for the font Sapphire, within FONTS:, there is a file called sapphire.font, a directory called Sapphire, and within the directory Sapphire are the files 14 and 19.		For each Amiga bitmap font stored on disk (normally in the FONTS: assign directory), there is a corresponding ".font" file, a directory, and within that directory, a series of files bearing numeric names. For example, for the font Sapphire, within FONTS:, there is a file called sapphire.font, a directory called Sapphire, and within the directory Sapphire are the files 14 and 19.

Steven Solie: /* Does the Text Fit? */

2015-11-06T20:50:17Z

Does the Text Fit?

← Older revision		Revision as of 20:50, 6 November 2015
Line 292:		Line 292:
	The TextLength() function is intended to mimic the Text() function without rendering the text. Using the exact same parameters as the Text() function, TextLength() returns the change in my_rp's current ''X'' position (my_rp.cp_x) that would result if the text had been rendered using the Text() function. As in Text(), the mycount parameter tells how many characters of mystring to measure.		The TextLength() function is intended to mimic the Text() function without rendering the text. Using the exact same parameters as the Text() function, TextLength() returns the change in my_rp's current ''X'' position (my_rp.cp_x) that would result if the text had been rendered using the Text() function. As in Text(), the mycount parameter tells how many characters of mystring to measure.

	Some fonts have characters that intrinsically render outside of the normal rectangular bounds. This can result for example, from the Amiga's version of kerning (which is discussed later in this ~~chapter~~) or from algorithmic italicizing. In such cases, TextLength() is insufficient for determining whether a text string can fit within a given rectangular bounds.		Some fonts have characters that intrinsically render outside of the normal rectangular bounds. This can result for example, from the Amiga's version of kerning (which is discussed later in this article) or from algorithmic italicizing. In such cases, TextLength() is insufficient for determining whether a text string can fit within a given rectangular bounds.

	The TextExtent() function offers a more complete measurement of a string than the TextLength() function. TextExtent() fills in the TextExtent structure passed to it based on the current rendering settings in my_rp.		The TextExtent() function offers a more complete measurement of a string than the TextLength() function. TextExtent() fills in the TextExtent structure passed to it based on the current rendering settings in my_rp.

Steven Solie: /* But What About Color Fonts? */

2015-11-06T20:49:51Z

But What About Color Fonts?

← Older revision		Revision as of 20:49, 6 November 2015
Line 1,661:		Line 1,661:
	The fields ctf_Low and ctf_High contain the lowest and highest color values in the ColorTextFont. For example, a four bitplane color font can have sixteen colors, but the font may use only nine of those colors, thus ctf_Low=0 and ctf_High=8. The most important use of these colors is for defining the boundaries of a gray scale font. If the font uses less than the total number of colors around but needs white as the lowest and black as the highest level of gray, the boundaries would have to be defined in order for the font to be rendered correctly. Defaults for these values should be the lowest and the highest values for the given number of bitplanes.		The fields ctf_Low and ctf_High contain the lowest and highest color values in the ColorTextFont. For example, a four bitplane color font can have sixteen colors, but the font may use only nine of those colors, thus ctf_Low=0 and ctf_High=8. The most important use of these colors is for defining the boundaries of a gray scale font. If the font uses less than the total number of colors around but needs white as the lowest and black as the highest level of gray, the boundaries would have to be defined in order for the font to be rendered correctly. Defaults for these values should be the lowest and the highest values for the given number of bitplanes.

	The ctf_PlanePick and ctf_PlaneOnOff contain information for saving space in memory for some types of ColorTextFont structures. The ctf_PlanePick field contains information about where each plane of data will be rendered in a given bitmap. The ctf_PlaneOnOff field contains information about planes that are not used to render a plane of font data. If ctf_PlaneOnOff contains a zero bit for a given plane, that bitplane is cleared. If ctf_PlaneOnOff contains a set bit for a given plane, that bitplane is filled. For more information on how the ctf_PlaneOnOff and ctf_PlanePick fields work see ~~the "~~Specifying the Colors of a Bob~~" section of the "Graphics Sprites, Bobs and Animation" chapter of this book~~.		The ctf_PlanePick and ctf_PlaneOnOff contain information for saving space in memory for some types of ColorTextFont structures. The ctf_PlanePick field contains information about where each plane of data will be rendered in a given bitmap. The ctf_PlaneOnOff field contains information about planes that are not used to render a plane of font data. If ctf_PlaneOnOff contains a zero bit for a given plane, that bitplane is cleared. If ctf_PlaneOnOff contains a set bit for a given plane, that bitplane is filled. For more information on how the ctf_PlaneOnOff and ctf_PlanePick fields work see [[Blitter_Objects#Specifying_the_Colors_of_a_Bob\|Specifying the Colors of a Bob]].

	The ctf_ColorFontColors field contains a pointer to a ColorFontColors structure:		The ctf_ColorFontColors field contains a pointer to a ColorFontColors structure:

Steven Solie: /* The Text Function */

2015-11-06T20:47:36Z

The Text Function

← Older revision		Revision as of 20:47, 6 November 2015
Line 30:		Line 30:
	</syntaxhighlight>		</syntaxhighlight>

	where myrp is a pointer to the target rastport, mystring is the string to render, and count is the number of characters of mystring to render. Text() renders at the current rastport position and it takes care of moving the rastport's current X position as it renders each letter. Text() only renders text horizontally, so repositioning the rastport's ''Y'' position (for example, for a new line) is the responsibility of the application. This is covered in more detail later in this ~~chapter~~.		where myrp is a pointer to the target rastport, mystring is the string to render, and count is the number of characters of mystring to render. Text() renders at the current rastport position and it takes care of moving the rastport's current X position as it renders each letter. Text() only renders text horizontally, so repositioning the rastport's ''Y'' position (for example, for a new line) is the responsibility of the application. This is covered in more detail later in this article.

	Like the other rastport based graphics primitives, most of the text rendering attributes are specified within the RastPort structure itself. The current position, the color of the text, and even the font itself are all specified in the RastPort structure.		Like the other rastport based graphics primitives, most of the text rendering attributes are specified within the RastPort structure itself. The current position, the color of the text, and even the font itself are all specified in the RastPort structure.
Line 42:		Line 42:
	</syntaxhighlight>		</syntaxhighlight>

	The parameter mytf is a pointer to an open, valid TextFont structure. The system uses the TextFont structure to keep track of fonts (The TextFont structure is discussed in detail later in this ~~chapter~~). The OpenFont() (from graphics.library) and OpenDiskFont() (from diskfont.library) functions both return a pointer to a valid TextFont structure. The OpenFont() function will only open fonts that have already been loaded and are currently in the system list. Normally applications use the OpenDiskFont() call instead of OpenFont() because OpenDiskFont() can load and open fonts from disk as well as open those that are already in the system list.		The parameter mytf is a pointer to an open, valid TextFont structure. The system uses the TextFont structure to keep track of fonts (The TextFont structure is discussed in detail later in this article). The OpenFont() (from graphics.library) and OpenDiskFont() (from diskfont.library) functions both return a pointer to a valid TextFont structure. The OpenFont() function will only open fonts that have already been loaded and are currently in the system list. Normally applications use the OpenDiskFont() call instead of OpenFont() because OpenDiskFont() can load and open fonts from disk as well as open those that are already in the system list.

	Here are prototypes for these functions:		Here are prototypes for these functions:
Line 167:		Line 167:
	If the drawing mode is set to JAM2, Text() will place the FgPen color as in the JAM1 mode, but it will also set the bits in the rastport to the RastPort.BgPen color wherever there is a corresponding cleared bit in the character's bitmap image. Basically, this prints the character themselves in the FgPen color and fills in the surrounding parts of the character image with the BgPen color. You set the BgPen color with the SetBPen() function by passing it a pointer to the rastport and a color number.		If the drawing mode is set to JAM2, Text() will place the FgPen color as in the JAM1 mode, but it will also set the bits in the rastport to the RastPort.BgPen color wherever there is a corresponding cleared bit in the character's bitmap image. Basically, this prints the character themselves in the FgPen color and fills in the surrounding parts of the character image with the BgPen color. You set the BgPen color with the SetBPen() function by passing it a pointer to the rastport and a color number.

	If the drawing mode is COMPLEMENT, for every bit set in the character's bitmap image, the corresponding bits in the rastport (in all of the rastport's bitplanes) will have their state reversed. cleared bits in the character's bitmap image have no effect on the destination rastport. As with the other drawing modes, the write mask can be used to protect certain bitplanes from being modified (see ~~the~~ ~~graphics primitives chapter~~ for more details).		If the drawing mode is COMPLEMENT, for every bit set in the character's bitmap image, the corresponding bits in the rastport (in all of the rastport's bitplanes) will have their state reversed. cleared bits in the character's bitmap image have no effect on the destination rastport. As with the other drawing modes, the write mask can be used to protect certain bitplanes from being modified (see [[Graphics Primitives]] for more details).

	The JAM1, JAM2, and COMPLEMENT drawing modes are mutually exclusive of each other but each can be modified by the INVERSVID drawing mode. If you combine any of the drawing modes with INVERSVID, the Amiga will reverse the state of all the bits in the source drawing area before writing anything into the rastport.		The JAM1, JAM2, and COMPLEMENT drawing modes are mutually exclusive of each other but each can be modified by the INVERSVID drawing mode. If you combine any of the drawing modes with INVERSVID, the Amiga will reverse the state of all the bits in the source drawing area before writing anything into the rastport.

Steven Solie: /* How is an Amiga Font Structured in Memory? */

2015-11-06T20:46:10Z

How is an Amiga Font Structured in Memory?

← Older revision		Revision as of 20:46, 6 November 2015
Line 1,528:		Line 1,528:
	== How is an Amiga Font Structured in Memory? ==		== How is an Amiga Font Structured in Memory? ==

	So far, this ~~chapter~~ has concentrated on using library functions to render text, letting the system worry about the layout of the underlying font data. As far as the OS representation of a loaded font is concerned, outline fonts and normal bitmap fonts are structured identically. Color fonts have some extras information associated with them and are discussed a little later. Every loaded font, including color fonts, has a TextFont structure associated with them:		So far, this article has concentrated on using library functions to render text, letting the system worry about the layout of the underlying font data. As far as the OS representation of a loaded font is concerned, outline fonts and normal bitmap fonts are structured identically. Color fonts have some extras information associated with them and are discussed a little later. Every loaded font, including color fonts, has a TextFont structure associated with them:

	<syntaxhighlight>		<syntaxhighlight>
Line 1,559:		Line 1,559:

	; tf_Style		; tf_Style
	: The style bits for this particular font, which are defined in <graphics/text.h>. These include the same style bits that were mentioned in the discussion of the TextAttr structure in the "Choosing the Font~~" section of this chapter~~. In addition to those bits, there is also the FSF_COLORFONT bit, which identifies this as a special kind of TextFont structure called a ColorTextFont structure. This is discussed later in this ~~chapter~~.		: The style bits for this particular font, which are defined in <graphics/text.h>. These include the same style bits that were mentioned in the discussion of the TextAttr structure in [[#Choosing the Font\|Choosing the Font]]. In addition to those bits, there is also the FSF_COLORFONT bit, which identifies this as a special kind of TextFont structure called a ColorTextFont structure. This is discussed later in this article.

	; tf_Flags		; tf_Flags
Line 1,583:		Line 1,583:

	; tf_CharData		; tf_CharData
	: This is the address of the bitmap from which the OS extracts the font's glyphs. The individual glyphs are bit-packed together. The individual bitmaps of the glyphs are placed in ASCII order side by side, left to right. The last glyph is the default glyph. The following is what the bitmap of the suits-8 font example looks like (suits-8 is the complete, disk-based bitmap font example used later in this ~~chapter~~):		: This is the address of the bitmap from which the OS extracts the font's glyphs. The individual glyphs are bit-packed together. The individual bitmaps of the glyphs are placed in ASCII order side by side, left to right. The last glyph is the default glyph. The following is what the bitmap of the suits-8 font example looks like (suits-8 is the complete, disk-based bitmap font example used later in this article):

	<pre>		<pre>