Index: src/ttf/long
===================================================================
--- src/ttf/long	(nonexistent)
+++ src/ttf/long	(revision 2068)
@@ -0,0 +1,37 @@
+Write with true type font, on silk, on copper. To handle all corner cases, this
+needs some infrastructure:
+<ul>
+	<li> possibility for more than one font set to be embedded in the .pcb - this enables the user to use the original font or multiple ttf fonts
+	<li> old-style fonts are static, ttf fonts are <i>dynamic</i> (see below)
+	<li> writing new text would use a global "current font" setting; this selects which one of the multiple font sets should be used
+	<li> an action to allocate a new set and bind it to a ttf
+	<li> sparse embedding: embed only the symbols that are actually in use (don't grow the .pcb file to megabytes with 15 Unicode snowmen glyphs)
+	<li> if the font is <i>dynamic</i> new glyphs are allocated as needed, e.g. the first time the user writes letter 'Q', it needs to appear in the sparse embedded version of the font; this means the ttf glyph for 'Q' is vector-rendered to letter 'Q' of the embedded font assigned to the ttf
+	<li> the current font rendering code doesn't change except dealing with multiple fonts
+	<li> font info would be stored as an attribute to the text object, so mainline pcb would preserve it (but would kill the embedded font set!)
+	<li> to minimize such compatibility issues with mainline, ttf glyph would be rendered into the same font size as the default font, so replacing any ttf text with the default font would cause only small differences in copper
+</ul>
+<p>
+Having all glyphs in use embedded in the design means the design
+can be saved and loaded on another system without risking any
+"copper change" due to:
+<ul>
+	<li> missing ttf file
+	<li> different version of the ttf file
+	<li> different ttf file with the same name
+	<li> some clever ttf lib mechanism finding a substitution ttf for a missing ttf
+	<li> different ttf lib version, host architecture, etc. causing slight differences in ttf rendering
+</ul>
+<p>
+The risky part starts when one edits text and starts using glyphs not embedded;
+in this case the ttf is used again to import the new glyphs. This can be
+overcome by an action that lets the user embed the basic alphabet or whatever
+glyphs, even if they are not currently in use.
+<p>
+<i>Compatibility:</i> mainline pcb wouldn't understand multiple fonts and
+would render everything with the default font. While font type attributes
+would be preserved with text objects, mainline pcb would probably remove
+the embedded glyphs of dynamic fonts - forcing pcb-rnd to re-embed them
+on the next load (reducing "copper-stability" vs. ttf file versions).
+
+
Index: src/ttf/short
===================================================================
--- src/ttf/short	(nonexistent)
+++ src/ttf/short	(revision 2068)
@@ -0,0 +1 @@
+native support for true type font
\ No newline at end of file