User Manual for
GlyphGate 5.1

Copyright 2001-2005 Em2 Solutions AB. All rights reserved.

Introduction

---

GlyphGate is a font savvy web server that makes it possible to show text, fonts and languages reliably in browsers on most platforms. The server is installed as an extension to Microsoft IIS, Apache Web Server, and NSAPI based web servers (e.g. iPlanet) and is available on quite a few platforms.

This documentation explains what you need to know to create web pages with fine typographical formatting and language content, using the powerful features of the GlyphGate web server.

Some of the features described in this manual are not available in all editions.

There is not much you need to know to create web pages on a GlyphGate web server, beyond basic knowledge about HTML, CSS and your web server. There are a few special purpose HTML tags or CSS properties that you may use to fully take advantage of the capabilities of GlyphGate. However, these extensions are optional and you do by no means need to know about them. There are a few aspects of HTML that you should be aware of though.

Compatibility modes

---

It is important to note that the most common reason why some web pages look different in different web browsers is that these pages are broken. Browsers typically show broken pages in different ways, because the HTML standard does not define how a browser should behave in such a case.

Broken pages are actually quite common, because there may be no feedback to the author of a web page that he or she made a mistake when creating the page (you don't get any error message from a web browser about such mistakes). Some of these errors may be that quoted strings in HTML and CSS code are not terminated correctly, that the wrong characters are used in CSS code (e.g. <SPAN CLASS=my_class> is invalid code) or that HTML tags are not opened or closed correctly in a page, that CSS and HTML code is mixed incorrectly (e.g. <FONT SIZE="24pt"> is invalid code). When designing a web page, and an author is able to verify that his or her page look correct in web browsers that they care about, there is very little incentive to go over the HTML code with a fine tooth comb to look for errors.

GlyphGate operates by refining web content. This means that GlyphGate needs to understand the content of web pages. If the content is ambigous or even erroneous, GlyphGate may not be able refine such a page correctly. This is of course not an issue for valid web pages. The HTML and CSS standard is strict so there is no risk that GlyphGate would misinterpret the content of a valid page.

GlyphGate refines web pages without any risk of distorting the content even for broken pages. However, it may not be possible to preserve the intended look of a broken page without reproducing the erroneous HTML code in the refined page that web browsers get. This in turn means that some of the features that GlyphGate provides may not be available for broken web pages.

GlyphGate deals with broken web pages by processing web pages in four different compatibility modes. These modes are:

1. Optimized mode: Optimized web pages are pages that include all the features that GlyphGate offers. GlyphGate version 3.1 and below supported no other mode.
2. Legacy mode: Pages processed in legacy mode are pages that contain various minor problems that will prevent GlyphGate from creating optimal html, css and font data. The page will include all of the features of an optimized web page, but it will probably be larger (and thus slower).
3. Legacy+ mode: Pages with serious errors are processed in this mode. Invalid CSS or HTML code are typical causes.
4. Legacy++ mode: This mode is a more drastic variant of the legacy mode. It is not entered automatically by GlyphGate, but may be entered explicitly through the use of a META tag (see below).
5. Skip mode: Web pages are not refined at all in this mode. Again, this is a mode that is not entered automatically, but may be entered explicitly through the use of a META tag.

The following restrictions apply to these compatibility modes as well:

1. The text encoding (e.g. Big5, ShiftJIS, iso-8859-1) is only refined in optimized pages. Browsers and platforms without support for the used encoding format are thus only supported for optimized pages.
2. Languages that require that characters are shaped and positioned (e.g. Arabic and Indic) are only available on natively unsupported platforms (e.g. OS's that do not know how to show Arabic on their own) for optimized pages.
3. Web pages containing client scripts that modify the content, that contain dynamic CSS code that affects text style, size or family, and pages which post data to CGI pages, are processed in legacy mode by default.
4. Web pages with translated text, using the GlyphGate <TRANBLK> tags, are only supported in optimized pages.

The author of web pages may control if a particular web page should be processed in a specific compatibility mode, regardless of if the page contains errors or not. This is done by using a special purpose META tag, as follows:

    <META name="glyphgate-process" content="{mode}">

An administrator may also throw a master switch to control which mode to use for all pages on all web sites of all web servers on a server. Please see the main administration file (glyphgate.cfg) for further details.

The intent with these modes is to ensure that broken web pages look no worse and no different than they did before using GlyphGate. However, this also means that these pages will not make full use of GlyphGate. To ensure best result, you may ensure that your pages are correct, by using the built-in page validator in GlyphGate.

Using fonts

---

GlyphGate supports the use of a wide array of different font formats in web pages. This is done by automatically creating so called Web Fonts, which are sent to the browser together with the web page. For browsers not supporting web fonts, bitmaps will be created to generate the same visual result.

Screen and printer fonts

A typical use of this feature may look like this:

<HTML>
<HEAD><STYLE>
	@media screen
	{
		p{font-family:MyFont}
	}
</STYLE></HEAD>
<BODY>
	<p>Cool text</p>
</BODY>
</HTML>

The size of the produced web font for such a page would be 400-700 bytes. Screen fonts are not used when a page is printed (you would specify an alternate font to be used when printed). Also, screen fonts can only be used when text does not need to be gray-scaled/smoothed. Screen fonts are thus typically used for the main body text in web pages.

Font formats

A good way to see which fonts are available for use by GlyphGate is to use the fonts folder which is found on the GlyphGate administration site. For more information see the Admin Site Manual or contact your web administrator.

Specifying which fonts to use

Once you have decided upon using certain fonts you need to specify this in your web page. You can do this in two different ways: use either old style html tags (e.g. <FONT>, <B>, <I>, etc) or css properties (e.g. font-family, font-weight, etc.). GlyphGate works like a web browser, and knows if you have used any fonts in your page or not. Any extra HTML code that is needed to declare Web fonts in the page will be injected by GlyphGate.

<p><font face="Verdana">This text is Verdana</font></p>

<p style="font-family:Verdana">This text is Verdana</p>

Note. It is important that you specify the font to use by its family name. It is illegal to write things like "font-family:Verdana Bold" and "face=Arial italic".

Specifying font subset

You set the subset of a font by declaring the font with a CSS @font-face at-rule and by including the CSS descriptor unicode-range. The src descriptor is not needed, as GlyphGate will create the font data itself. The syntax for this at-rule can be found at the W3C web site. GlyphGate supports two extensions to what is defined in this standard. When specifying which characters to include in the font, you may simply type a start and an end character to define a range. For example, "AZ" would define the range of all uppercase Latin characters.

The code below shows how to declare the font Trebuchet MS with a given subset. The declaration specifies that all upper and lower case Latin characters, digits, punctuations, control characters (e.g. nbsp) and the trademark character should be included.

@font-face
{
	font-family: Trebuchet MS; 
	font-style: normal; 
	font-weight: normal; 
	/* Include Latin + digits + punctuation + tm */
	unicode-range: az,AZ,U+7C,U+20-41,U+A?,U+2122,U+99 
}

The other extension is that you can use a special value for the unicode-range descriptor indicating that all or part of a character set should be included in the subset. It takes the form of "set(charset, level)" where charset is a character set name (like "shift_jis" or "iso-8859-7") and level is an optional integer (1 to 6) specifying how much of the character set that will be included. A value of 1 means "only include the most common characters", while 6 means "include ALL characters". Thus, to get a font suitable to show japanese you would write:

@font-face{font-family:MS PGothic; unicode-range:set(shift_jis, 6)}

@font-face{font-family:Verdana; unicode-range:set(iso-8859-7, 2)}

If you specify a subset using the above notation, then the font will NOT be shared across all pages on the site. It will only be used from pages containing a similar declaration. since the font subset will not be added to and the font will not grow.

Optimizing font quality and performance

Font smoothing Fonts at small sizes are typically shown black and white for optimal contrast and legibility, and with gray-scale at larger sizes. Showing text at larger sizes in black and white would produce very jaggy text and showing small text with gray-scale produces very fuzzy and illegible text, neither of which look good. There is thus an optimal size at which text should be shown with gray-scale.

GlyphGate will use information in the fonts themselves to determine what this threshold size should be. (The size at which text should stop being black and starting being gray as well). You may over-ride these threshold sizes on an per font basis. Doing so will affect all web pages that uses that font. Your system administrator can help you tweak these sizes.

It is also possible to control whether a given text should be smoothed or not. To do this you use the proprietary CSS property x-smooth-control. As a value you supply a size (in either pixels or points) above which the text should be smooth. You use the x-smooth-control like this:

<style>
	P
	{
		font-family: Tahoma;
		x-smooth-control:9pt ct;
	}
</style>

<p style="font-size:8pt">This is black and white text</p>
<p style="font-size:10pt">This is smooth text</p>

The word 'ct' after the size value indicates the prefered font smoothing method, which is currently supported on Windows Xp/2003/Vista. The method may be set to ct (for ClearType), std (for standard) or usr (for user's preference). The latter (usr) method results in the users setting in the Display control applet on Windows is used (which is no-smoothing by default). Cleartype is used if available if no method is specified.

Finally, to set the smoothing threshold for a font on one page only, you can use the proprietary CSS descriptor x-smooth-control when declaring the font (Note: CSS descriptors and CSS properties are different things in CSS). It is used like this:

<style>
	@font-face
	{
		font-family:Arial;
		x-smooth-control: 15pt;
	}
</style>

Font hinting With the proprietary CSS property x-hint-control you can override whether the font of any given block of text should be hinted or not. Hints are instructions present in a font to make it look good when rendered at small sizes (like on a computer screen). You can set x-hint-control to "do-hints" (the default) to use hinting information from the font or to "no-hints" to turn hints off.

<p style="font-size:14pt;font-family:Arial">
<span style="x-hint-control:do-hints">Hinted text</span><br> 
<span style="x-hint-control:no-hints">Unhinted text</span><br> 
</p>

Font caching GlyphGate stores font data in a cache. The font data is normally shared across all pages on the site, resulting in faster font loads and better overall performance. However, sometimes you may want to use a font for a given page only, perhaps because you want to only include a minimal subset in the font. This feat can be accomplished by using the proprietary CSS font descriptor x-cache-control. You can set this to "do-cache" for normal caching behaviour or to "no-cache" to make the font available to the current page only. Use it like:

<style>
	@font-face
	{
		font-family: Tahoma;
		x-cache-control:no-cache;
	}
</style>

Aliases You may at times want to use aliases for font names, such as 'serif' instead of 'Times New Roman'. These aliases will also be used in cases where a font will not be embedded for a browser, and provide a good way for the browser to pick a suitable substitute in case the preferred font is not available. You may thus ask your system administrator to provide alternate names for used fonts. These aliases will be used in all pages on your web server.

Core fonts Some fonts, such as Arial and Times New Roman, are available on many platforms. These are fonts that you may not want to embed in web pages, since most users will have them anyway. There are other cases where you want to prevent certain fonts from being embedded as well. The fonts "Arial", "Times New Roman" and "Courier New" are listed as Core fonts by defualt. You may extend this list with additional fonts by asking you administrator to do so.

Fallback fonts GlyphGate knows if a particular font can be used to render text of some specific language. If GlyphGate detects that a used font is not suitable for some text in a page (or if a font is not specified at all), then it will go through the list of fallback fonts and use the first font in this list that supports the particular language.

For example, if Devanagari (Indic) characters are used in a page without any specification of which font to use, then GlyphGate would embed the font Mangal with that page (assuming that Mangal is included in the fallback list). Ask you administrator if you need to change this list.

ScreenType Quality of fonts varies greatly, depending on platform, font format and how much time the author of a font has spent on refining the font for screen usage. Common problems with fonts that are used on web pages include uneven weight (some characters look distinctly darker than others), unwanted asymmetrical features (round features that have "bumps", or diagonal strikes with "warts") and uneven character spacing. An example of this can be seen in the picture below (magnified by a factor of two), taken from the font 'em2Sans' rendered by a Unix GlyphGate server.

These unwanted artifacts are typically found at small sizes on screen-only, and not when printed on paper. GlyphGate contains a technology known as ScreenType that addresses these problems. The same sample shown above can be seen below with this technology in use.

ScreenType can be turned on for fonts and for parts of web pages. Enabling ScreenType for a font would affect all pages using that font, and needs to be configured by your system administrator. To enable ScreenType for a web page, you would use the CSS property 'screen-type' and set it to the value 'on' or 'off'. For example:

	<p style="screen-type:on; font-family:Geneva">Cool text</p>

The font families em2Mono, em2Serif and em2Sans are already configured to be rendered with ScreenType turned on.

Using languages

---

When creating a web page with text content, you enter characters in what is known as an "encoding scheme". An encoding scheme is what defines how a HTML literal (e.g. &#0064;) or a sequence of bytes (e.g. a byte with the value 64) should be displayed. There are several such encoding schemes in use today, typically specific to certain languages. For example, the 197:th character in the iso-8859-1 standard is the A with a ring character (i.e. Å), while the 197:th character in the iso-8859-2 standard is L with an acute mark (i.e. Ĺ). The same web page would thus look different if you would change the used encoding.

GlyphGate prefers a particular encoding, known as Unicode/ISO 10646. This format is particularly useful because it can be used to show characters of different languages in the same page. Unicode text may be entered into a web page as UTF16 (called Unicode or Unicode big endian), UTF7, or UTF8. The most convenient format today is UTF8. Chances are that your web authoring tool supports one of these formats, typically as an option when you save your page.

In order for GlyphGate to correctly identify your text as Unicode, you may need to include the HTML tag META and include the appropriate attribute that states which encoding you have used. This is not needed though if you are using a Unicode savvy text editor that knows how to mark files as being Unicode encoded (such as Notepad on Windows Xp). A typical use of the META tag can be seen below.

<META HTTP-EQUIV=CONTENT-TYPE CONTENT="text/html; charset=utf-8">

The example above would mark a file as being a HTML file with UTF8 encoded Unicode text. The value used after charset= may be replaced by a number of different encoding formats, such as "iscii", "ascii", "iso-8859-1" (and related iso encodings), "unicode", "utf-7", "utf-8", etc.

Similarly, you use the CSS @charset rule to specify the used encoding in CSS files (see below for an explanation on CSS), as follows:

@charset "utf-8";

You may also use the HTML lang attribute to indicate which language a piece of text is written in. This will ensure that your text is shown correctly in cases where the used encoding can be used to show several different languages. For example:

<HTML lang=ar-sa>
... some html code here...
<HTML>

The value of the lang attribute consist of a country code, optionally followed by a hyphen and a language code. Both codes as defined by ISO standards. In the example above, all text in the body would be shown as Saudiarabian Arabic.

If you do not have a Unicode savvy authoring tool, or you would like to use a more convenient format (e.g. Shift-Jis for Japanese web pages), then that is fine too as long as you set the charset value of the META tag to the used encoding.

Since a font will be used to show your text in a page, that font will need to support the used encoding. GlyphGate will convert your text content into Unicode when processing your page, so you may need Unicode fonts even if you specified a regional 8-bit encoding, like ISCII in India. To prevent GlyphGate from converting the content into Unicode, use the encoding scheme 'x-user-defined' or 'ascii'. If you do, then you need to ensure that you have specified a suitable font in your web pages as GlyphGate would no longer be able to select fallback fonts for you.

To summarize, if you use Unicode fonts then specify the appropriate encoding scheme in a META tag, e.g. iscii. If you use regional 8-bit encoded fonts (sometimes known as hack encoded fonts) then specify the encoding scheme x-user-defined. Please note also that some hack encoded fonts are not supported on all platforms, because they rely on 8-bit character codes that don't exist on all platforms. Unicode is to be preferred for truly cross platform language support.

Multilingual text input

When filling out web forms or other web text input fields it is sometimes important to be able to input text in a language not supported by the keyboard currently being used. For example, a Japanese businessman might want to input Japanese characters into his email sent from an English computer at the airport in London. For this support, GlyphGate uses something called SWIME (Simple Web Input Method Editor). It works much like a normal IME works: by assigning key stroke patterns to output characters. Using the Japanese input method supplied with GlyphGate it is thus possible to type "ichi" in a text input field the get the Unicode code point 0x4e00. When designing a page you decide which input methods that are "active" on the page. When a user later fills out a web form on the page he can easily switch between the different input methods provided.

To add this support to a web page, you need to do the following:

1. Create a META tag with the name 'GlyphGate-IME' that indicates which input language(s) you wish to support in the input field. The value should be a comma separated list of one or more of the following supported language codes:

	jp    - Japanese (Hiragana/Katakana)
	han   - Cangji Han
	JPon  - Japanese On Kanji.
	JPkun - Japanese Kun Kanji
	ZHman - Mandarin Hanzi
	ZHcan - Cantonese Hanzi
	kr    - Korean Hanja
	el    - Greek
	ru    - Cyrillic
	hi    - Devanagari

<meta name='GlyphGate-IME' content='jp,el'>

2. Make sure that the page has an embedded font that includes the characters that can be inputted through the IME. If you want to support japanese text input you can e.g. insert a font declaration like:

/* Japanese SWIME font */
@font-face{font-family:MS PGothic; unicode-range:set(shift_jis)}

3. Anyone surfing to your page using a modern browser like IE 5 or Netscape 7 will now have a little blue square attached to any input field which has the keyboard focus. The text inside the blue square indicates which language is currently used for the text input. To cycle through all the supported languages, simply click on the blue box.

Transliteration

GlyphGate uses a process known as "transliteration" to be able to represent e.g. japanese text on an english text-based web browser (like lynx).

Using CSS formatting

---

It is very easy to create good looking pages on a GlyphGate server. GlyphGate supports page formatting using CSS2 (Cascading Style Sheets), which combines powerful page layout capabilities with ease of use. The GlyphGate web server has a built in sophisticated CSS processor, which will allow you to format pages using CSS2 quickly and effectively. For browsers that can't handle CSS2, GlyphGate will automatically convert the stylistic formatting into equivalent CSS1 and HTML formatting code.

A short example

<html>
<head>
	<style>
	h1 {font-family:Verdana; font-size:20px; color:green}
	</style>
</head>
<body>
	<h1>This text is green 20px Verdana</h1>
</body>
</html>

The above example shows a very simple HTML page with some embedded CSS code in the STYLE-element. The CSS formatting rule stipulates that all h1 headings should be displayed using the font Verdana, that the text should be green and that the font height should be 20 pixels. Now you can write your document inside the body of the page, knowing how each h1 element will look on the user's browser. If you later decide to give the document a new look, it is a simple matter of changing the CSS declarations in the head of the page. For more information on how to use CSS, please refer to the CSS specification.

Corporate Style Sheet

GlyphGate supports the notion of a Corporate Style Sheet. This is a style sheet file that will be linked into all pages on the GlyphGate server. Such a corporate style sheet file may or may not be available, depending on how the GlyphGate server is set up.

If you want a corporate style sheet to be applied to some but not all pages, then simply link that CSS file explicitly to those pages with the <LINK> tag.

Unsupported constructs

There are some CSS formatting constructs that GlyphGate currently does not support. In many cases this is because some constructs rely on information from the browser to process the CSS formatting correctly; information that GlyphGate cannot have since the processing is done on the server side. The most notable things are:

• Pseudo elements (see CSS Spec). GlyphGate does not know the size of the browser window etc, so there is no way to handle e.g. the first-line-property, since GlyphGate does not know what is going to make up the first line of the text (i.e. where the row break will be inserted).
• Generated content (see CSS Spec). Generated content is not supported at this time.
• Dynamic pseudo classes :hover, :active and :focus (see CSS Spec). These things can't be handled on the server side.
• System colors (see CSS Spec). Not supported at this time (dependent on client side user settings).
• Alternate style sheets. (see HTML Spec). Not supported at this time (dependent on user settings).

That these constructs are unsupported by GlyphGate does not mean that you cannot use them in your pages if you know what you're doing. GlyphGate will not remove them from the page. That they are unsupported simply means that GlyphGate will not try to mimic their behavior in older browsers. Also, you should be aware that if you are using this kind of constructs and they affect the text content of the page in any way (as is the case e.g. for generated content), then if may be that the text will not be shown as intended on the user's browser. This is because the web font used may be missing glyphs needed to display the text correctly.

Using HTML formatting

---

GlyphGate has support for "old-style" HTML formatting elements like <font>, <b> and <i>. However, it is often more convenient to use CSS formatting instead (see above).

You should avoid using proprietary tags like <embed> and <layer> etc. that will only work in some browsers.

Using client side scripts

---

GlyphGate works straight off with your existing HTML pages, but some constructs in existing pages may cause unexpected behavior when the pages are processed by GlyphGate. This is especially true when using client side scripts (e.g. JavaScript and Visual Basic scripts) to change the content of the document.

Linking to an external CSS file

It is fairly common to use small snippets of JavaScript code to sniff out what kind of browser the user is using and generating a link to different CSS files depending on the browser:

<SCRIPT language="JavaScript">
if (browser="Mozilla")
	document.write('<link href="mozilla.css">');
else
	document.write('<link href="other.css">');
</SCRIPT>

Linking to different CSS files in this way is normally done to overcome differences in layout and rendering in different browsers. There is no need to do this when using GlyphGate. GlyphGate already knows about the differences between browsers, and automatically compensates for them when processing pages, to generate cross browsers consistency. In fact, using this kind of dynamic client-side script constructs makes it impossible for GlyphGate to know what stylistic formatting to apply to the document, since GlyphGate will not run the client side script code to find out which CSS file to use. You should remove this kind of constructs from your pages and let GlyphGate handle the differences in browsers, or consider using server side scripts instead.

Inserting CSS or HTML formatting

• The text or HTML code you insert via the script is not processed by GlyphGate in any way.
• You should not, in any event, use constructs like:

  ...
  <DIV>
  	<SCRIPT>
  		Document.Write('data in the DIV...</DIV>');
  	</SCRIPT>
  ...
  

  This will cause the HTML parser to generate an error that the DIV-element is not closed, since no </DIV> is found in the page. GlyphGate will also automatically try to fix this problem by inserting a </DIV>-tag, resulting in unexpected behavior when the script is run on the client side. To remedy this problem, you should move the </DIV>-tag out of the script, or alternatively move the <DIV>-tag into the script instead.

<SCRIPT>
	var allSpans = document.getElementsByTagName("SPAN");
	allSpans[4].style.color="red";
</SCRIPT>

The reason why this script may produce unexpected results is the use of an index to access the desired SPAN-element. In order to support fonts and languages GlyphGate may have inserted new SPAN-elements into the page, and the fourth element may thus be one of the SPAN-elements inserted by GlyphGate. It is a better idea to use id attributes to access elements instead, like so:

<SCRIPT>
	var allSpans = document.getElementsByTagName("SPAN");
	allSpans["alfa"].style.color="red";
</SCRIPT>

Not only will this ensure that the script will work correctly after being processed by GlyphGate, it also has great advantages if you later decide to update the document with more SPAN-elements, since you don't need to update the script in this case.

Page validator

---

GlyphGate contains a built-in HTML and CSS validator that will assist you in creating web pages that are syntactically correct. The validator will find things like missing end tags and illegal constructs in the pages processed. GlyphGate can be configured to enable the validator for all pages on the site, or only certain directories etc. Optionally, and as a great help during page development, GlyphGate can be configured to visually indicate if a page contains syntax errors. Please refer to the Admin site manual for more information on the validator.

HTML and CSS extensions

---

Although GlyphGate expects standard HTML/CSS documents, there are a few proprietary extensions that helps you optimize and control the content in web pages that are not otherwise possible with standard HTML/CSS. These extensions are described below.

OpenType Layout

OpenType Layout is a language used to encode advanced typographical formatting features. Such features range from basic kerning pairs to language specific character shaping and positioning rules. Features are accessed by four letter feature tags, such as 'kern' for kerning pairs and 'liga' for standard ligatures. Each feature belongs to a script and language pair. You may as such have a font that defines kerning pairs for one language, and a different set of kerning pairs for another language. More information about OpenType Layout can be found at http://www.microsoft.com/typography/

OTL feature tags are used in web pages by using the text-otl CSS property. It's value should be the predefined value none or a comma separated list of OTL feature tags. To show a date with old style numerals (also known as lower case numerals), you would use the following HTML code:

<SPAN LANG=en STYLE='text-otl:onum'>Date 2001-10-24</SPAN>

The lang HTML attribute in conjunction with the text-otl CSS property is used in the example above to access the onum feature of the font that is used for the paragraph. Please note that this would only produce old style numerals if that font does indeed contain such an OTL feature for the language in question.

The result is illustrated below (if you have the font 'Palatino Linotype'):
With OTL: Date 2001-10-24 and without OTL: Date 2001-10-24

Text Effects

Using GlyphGate you can easily create cool text effects like shading, rotated characters or even checkerboard text.

Size adjustments Different fonts have a tendency to look different in size even if rendered at the same point size. This has to do with the aspect ratio of the font (width versus height of characters). So will e.g. 12 pt Verdana look much bigger than 12 pt Times New Roman. To compensate for this, you can use the proprietary CSS property x-adjust-size.

Without x-adjust-size the text set in Times appears much smaller:

<span style="font-size:14pt">
<span style="font-family:Verdana">this is 14pt Verdana </span>
<span style="font-family:Times New Roman">this is 14pt Times</span>
</span>

Now, using x-adjust-size, they look about the same:

<span style="font-size:14pt">
<span style="font-family:Verdana">this is 14pt Verdana </span>
<span style="font-family:Times New Roman;x-adjust-size:1.26">this is 14pt Times</span>
</span>

Transforms Using the proprietary CSS property x-transform you can scale or rotate characters in a piece of text. The value of the x-transform property should be a space separated list of six floating point values: a, b, tx, c, d and ty corresponding to a transformation matrix in the following way:

	[a  b  0]
	[c  d  0]
	[tx ty 1]

Extended/condensed text. To create extended or condensed text use the x-transform property with a value like "x 0 0 0 1 0", where "x" is a floating point value indicating how much the text should be extended. Values larger than 1.0 result in extended text and values smaller than 1.0 in condensed text. Example:

<span style='x-transform: 1.4 0 0 0 1 0'>This is transformed em2Sans<br>
<span style='x-transform: 1 0 0 0 1 0'>This is transformed em2Sans</span><br>
<span style='x-transform: 0.8 0 0 0 1 0'>This is transformed em2Sans</span>

Rotated text. To create rotated characters use the x-transform property with a value like "x -y 0 y x 0", where "x" is cos(angle) and "y" is sin(angle). Say we want to rotate the characters by 20 degrees. cos(20) is about 0.94 and sin(20) is about 0.34. Thus, we would set x-transform to "0.94 -0.34 0 0.34 0.94 0", like so:

<p style='x-transform: 0.94 -0.34 0 0.34 0.94 0'>This is transformed em2Sans</p>

Mirror effect. A mirror effect can be accompished by flipping the text vertically. <span style='x-transform: 1 0 0 0 1 -25'>This is transformed em2Sans<br> <span style='color:gray; x-transform: 1 0 0 0 -1 120'>This is transformed em2Sans</span>

Effects With the x-effects property you can create color effects like shading and checkerboard patterned text. Currently x-effects supports the following values.

checker(c1,c2,d)	Checkerboard effect. c1 and c2 are hexidecimal color values of the form "#rrggbb" and d is the size of the checkerboard squares in pixels.
shade(c,dx,dy)	Creates a drop shadow effect. c is the color of the shadow, while dx and dy are its position.
glow(c,dx,dy)	Creates a kind of backglow effect. c is a color value, dx and dy determine the size of the glow.
edges(d)	Gives the text a 3D look. d is the "depth" of the text.

example

<p style="font-family:Berliner; x-effects:shade(#a0a0a0,2,2)">This is the shade effect<br>
<p style="font-family:Berliner; x-effects:checker(#D0D000,#0000ff,5)">This is the checker effect<br>
<p style="font-family:Berliner; x-effects:glow(#a00000,2,2)">This is the glow effect<br>
<p style="font-family:Berliner; x-effects:edges(2)">This is edges effect<br>

Browser Redirect

GlyphGate can redirect browsers to specific pages through the use of a special purpose META tag. The syntax of this META tag is as follows:

<META NAME=GG-REDIRECT CONTENT="agent:URI">

The value AGENT can be a comma separated list of user agents, found in the GlyphGate user agent database, and the URI should be a valid absolute or relative URI, or the special word 'raw'. The 'raw' keyword is used to prevent GlyphGate from processing a page for a particular browser. Also, you may set the CONTENT attribute to 'raw' without specifying a user agent, in which case the page would be ignored by GlyphGate. Such a META tag would thus read:

<META NAME=GG-REDIRECT CONTENT=raw>

There may be cases when you want to prevent GlyphGate from refining or enhancing specific portions of a HTML document. You may do this by using the special purpose glyphgate CSS property. You may set this property to the values process, skip or nofonts.

The default value process indicates that the HTML block element where the property is set should be fully processed by GlyphGate.

The value skip indicates that the block element should not be processed at all. CSS formatting, language content and font usage would thus not be enhanced and would not display correctly for some browsers.

The value nofonts works like skip, except it disables the font usage support only. CSS to HTML and language encoding specific features are still done, but no web fonts are created for the block where the property is set.

Note that this property is inherited, through the normal CSS cascading rules. Setting the property for a HTML block would thus affect child blocks where this property is not set. For example:

<HTML>
<BODY STYLE='glyphgate:skip'>
<P>This paragraph is not processed by GlyphGate, 
	<span style='glyphgate:process'>except for this text,</span>
	<span>but not this part.</span>
</P>
</BODY>
</HTML>

E-Commerce

---

If you are using the E-Commerce edition of GlyphGate, then you are able to use fonts and languages in your CGI and server script pages.

It is important to note that GlyphGate does not actually run your CGI page, nor does it interpret your server script pages (e.g. PHP, PL, JSP or PHP pages). The script pages are executed by the intended interpreter before GlyphGate kicks in. GlyphGate will instead take the output that is produced by running your server script and will refine that result for the particular browser in question. There is as such no risk that GlyphGate will cause any problems with your server script code. This also means that you can use virtually any type of server script language with GlyphGate, as long as your web application produces HTML/CSS code.

There are things that differs between static and dynamic web pages though. All fonts are treated as site fonts when they are accessed from dynamic pages (see Using Fonts section for further details on site fonts). There is as such no need to declare them as site fonts.

Information about fonts

GlyphGate provides certain extensions to server scripts, such as a list of available fonts. This is done through a number of pre-defined cookies. The names of these GlyphGate cookies are:

• fryFontCount: The total number of available fonts on your web server.
• fryFontStart: The index of the first font in the fryFonts array (see below).
• fryFontRange: The number of fonts in the fryFonts array (see below).
• fryFonts: An array of records, containing information about each available font. Each record consists of: {family}:{sfnt}:{otl}:{bmp}:{ebmp}:{style}:{charset}
  • {family} The name of the font family, e.g. "Trebuchet MS".
  • {sfnt} 1 if the font is an TrueType/OpenType font.
  • {otl} 1 if the font is an OpenType Layout font.
  • {bmp} 1 if the font is a bitmap font.
  • {ebmp} 1 if the font contains embedded bitmaps.
  • {style} a bitfield consisting of 1 for regular, 2 for bold, 4 for italic and 8 for bolditalic fonts. A font that supports all of these styles would thus have a value of 1+2+4+8 = 15.
  • {charset} the equivalent of the codeRange fields found in an OpenType font, separated by a hyphen.

A typical font information record would thus look something like "Trebuchet MS:1:0:0:0:15:255----". Since you may have quite a large number of fonts on your server, GlyphGate will only include information about the 100 first fonts by default. To access information about more fonts, you may use the query string "ggFontStart" and "ggFontRange" to specify a range of font which you would like to get information about.

For more information about how to access this font information, have a look at the implementation of the GlyphGate fonts folder.

Stacking diacritical marks

---

Some languages make extensive use of Latin characters with multiple diacritical marks. This is the case in for example Vietnamese and Yukon languages (Tagish, Kaska, etc). Showing such characters on computer screens presents problems to some operating systems. Multiple marks that are positioned above a character need to be stacked on top of each other. Some operating systems fail to do so and will let these marks overlap each other, or space them out next to each other, instead. An example of these phenomena can be seen below in figure 1.

Figure 1. Stacking of diacritical marks in Notepad on Windows 2000.

GlyphGate has been developed to address these problems on many different levels. These levels include support for entering diacritical marks on platforms without suitable keyboards, rendering text with fonts, and positioning diacritical marks appropriately. These aspects of GlyphGate are described below.

Entering text with diacritical marks

GlyphGate has been extended to recognize the following HTML literals:

Extension	Unicode	Mark	a+mark		Extension	Unicode	Mark	a+mark
&_grave	&#x300	&_grave	a&_grave;		&_acute	&#x301	&_acute	a&_acute
&_circ	&#x302	&_circ	a&_circ		&_tilde	&#x303	&_tilde	a&_tilde
&_macron	&#x304	&_macron	a&_macron		&_breve	&#x306	&_breve	a&_breve
&_dotabv	&#x307	&_dotabv	a&_dotabv		&_uml	&#x308	&_uml	a&_uml
&_ring	&#x30a	&_ring	a&_ring		&_caron	&#x30c	&_caron	a&_caron
&_dblact	&#x30b	&_dblact	a&_dblact		&_dotblw	&#x323	&_dotblw	a&_dotblw
&_cedila	&#x327	&_cedila	a&_cedila		&_ogonek	&#x328	&_ogonek	a&_ogonek

Figure 2. HTML literals for diacritical marks in GlyphGate.

For example, the Southern Tutchone word sha&_uml;&_grave;w would be entered sha&_uml;&_grave;w. The same word would be entered sha&#x308;&#x300;w when using the equivalent Unicode literals.

Character composition and decomposition

When rendering a character sequence like "u {dieresis} {grave}" (three characters), GlyphGate would determine that there is an equivalent u-dieresis-grave character defined in Unicode. GlyphGate consequently forwards a single character to browsers requesting to show this text, thus ensuring that fonts that contain this character will be used to produce a good looking result.

For example, the ficticous word shu&_uml;&_grave;w entered as shu&_uml;&_grave;w would be composed as sh&uuml;&_grave;w (note that the u and the umlaut have been combined to form an u-umlaut). GlyphGate will go one step further and form a single character for u-umlaut-grave, giving the result sh&#x1D8;w. Conversely, if the author entered sh&#x1D8;w and a font is used that does not contain the u-umlaut-grave (U+1D8) character, then GlyphGate would decompose the character into u-umlaut and the combining grave mark.

Font support

Latin fonts may not be designed with characters that contain all the possible combinations of diacritical marks that are used in many languages. GlyphGate compensates for this by composing new characters as they are needed, by positioning marks in relation to each other and to the base character on which they are stacked. A sample of fonts can be seen below. None of these fonts were designed to show text with combined diacritical marks. However, they all contain the required marks. GlyphGate is thus able to compose characters by combining (and position) them to form the desired characters.

em2Serif - Gu.a&_grave;łshe&_acute; ha&_grave; s’a&_grave;ti&_acute; yagìyi&_acute; i jiyi&_acute;s wu&_grave;k’e&_circ

em2Sans - Gu.a&_grave;łshe&_acute; ha&_grave; s’a&_grave;ti&_acute; yagìyi&_acute; i jiyi&_acute;s wu&_grave;k’e&_circ

em2Mono - Gu.a&_grave;łshe&_acute; ha&_grave; s’a&_grave;ti&_acute; yagìyi&_acute; i jiyi&_acute;s wu&_grave;k’e&_circ

Book Antiqua - Gu.a&_grave;łshe&_acute; ha&_grave; s’a&_grave;ti&_acute; yagìyi&_acute; i jiyi&_acute;s wu&_grave;k’e&_circ