[css-fonts-4] Port Appendix A from L3

Author: svgeesus

css-fonts-4/Overview.bs

@@ -2123,7 +2123,7 @@ same set of codepoints.
 The associated font might not contain glyphs for the entire set of
 codepoints defined by the 'unicode-range' descriptor. When the font
 is used, the <dfn>effective character map</dfn> is the intersection of the
-codepoints defined by 'unicode-range' with the font's <em>character map</em>.
+codepoints defined by 'unicode-range' with the font's <a>character map</a>.
 This allows authors to define supported ranges in terms of broad
 ranges without worrying about the precise codepoint ranges supported
 by the underlying font.
@@ -4735,7 +4735,126 @@ The <code>fontFamily</code> and <code>basePalette</code> interfaces are parsed a
 <h2 id="platform-props-to-css" class="no-num">
 Appendix A: Mapping platform font properties to CSS properties</h2>
 
-Issue: Import from level 3
+
+	<em>This appendix is included as background for some of the problems and
+	situations that are described in other sections.  It should be viewed as
+	informative only.</em>
+
+	Font properties in CSS are designed to be
+	independent of the underlying font formats used;
+	they can be used to specify bitmap fonts,
+	Type1 fonts,
+	SVG fonts
+	in addition to the common TrueType and OpenType fonts.
+	But there are facets of the TrueType and OpenType formats
+	that often cause confusion for authors
+	and present challenges to implementers
+	on different platforms.
+
+	Originally developed at Apple,
+	TrueType [[TRUETYPE]] was designed as an outline font format
+	for both screen and print.
+	Microsoft joined Apple
+	in developing the TrueType format
+	and both platforms have supported
+	TrueType fonts since then.
+	Font data in the TrueType format consists of
+	a set of tables distinguished with common four-letter tag names,
+	each containing a specific type of data.
+	For example,
+	naming information,
+	including copyright and license information,
+	is stored in the 'name' table.
+	The <a>character map</a> ('cmap') table
+	contains a mapping
+	of character encodings to glyphs.
+	Apple later added additional tables
+	for supporting enhanced typographic functionality;
+	these are now called Apple Advanced Typography, or AAT, fonts.
+	Microsoft and Adobe developed
+	a separate set of tables for advanced typography
+	and called their format OpenType [[OPENTYPE]].
+	The OpenType specification is standardized at ISO as the
+	Open Font Format [[OPEN-FONT-FORMAT]].
+
+	In many cases the font data used under Microsoft Windows
+	or Linux
+	is slightly different from the data used under Apple's Mac OS X
+	because the TrueType format allowed for
+	explicit variation across platforms.
+	This includes font metrics,
+	names and
+	<a>character map</a> data.
+
+	Specifically,
+	font family name data is handled differently
+	across platforms.
+	For TrueType and OpenType fonts
+	these names are contained in the 'name' table,
+	in name records with name ID 1.
+	Multiple names can be stored for different locales,
+	but Microsoft recommends fonts
+	always include at least a US English version of the name.
+	On Windows,
+	Microsoft made the decision for backwards compatibility
+	to limit this family name to a maximum of four faces;
+	for larger groupings the
+	"preferred family" (name ID 16) or
+	"WWS family" (name ID 21)
+	can be used.
+	Other platforms such as OSX don't have this limitation,
+	so the family name is used to define all possible groupings.
+
+	Other name table data provides names used
+	to uniquely identify a specific face within a family.
+	The full font name (name ID 4) and
+	the Postscript name (name ID 6)
+	describe a single face uniquely.
+	For example,
+	the bold face of the Gill Sans family
+	has a fullname of "Gill Sans Bold" and
+	a Postscript name of "GillSans-Bold".
+	There can be multiple localized versions of the fullname for a given face,
+	but the Postscript name is always a unique name
+	made from a limited set of ASCII characters.
+
+	On various platforms,
+	different names are used to search for a font.
+	For example,
+	with the Windows GDI CreateIndirectFont API,
+	either a family or fullname can be used to lookup a face,
+	while on Mac OS X the CTFontCreateWithName API call is used
+	to lookup a given face
+	using the fullname and Postscript name.
+	Under Linux,
+	the fontconfig API allows
+	fonts to be searched using any of these names.
+	In situations where platform API's
+	automatically substitute other font choices,
+	it may be necessary to
+	verify a returned font matches a given name.
+
+	The weight of a given face can be determined
+	via the usWeightClass field of the OS/2 table
+	or inferred from the style name (name ID 2).
+	Likewise, the width can be determined
+	via the usWidthClass of the OS/2 table
+	or inferred from the style name.
+	For historical reasons
+	related to synthetic bolding at weights 200 or lower with the Windows GDI API,
+	font designers have sometimes skewed values in the OS/2 table
+	to avoid these weights.
+
+	Rendering complex scripts that use contextual shaping
+	such as Thai,
+	Arabic
+	and Devanagari
+	requires features present only in OpenType or AAT fonts.
+	Currently,
+	complex script rendering is supported
+	on Windows and Linux using OpenType font features
+	while both OpenType and AAT font features are used
+	under Mac OS X.
 
 <h2 id="priv-sec">
 Security and Privacy Considerations