Bug 328206 – Update/remove some old files

2006-02-21  Behdad Esfahbod  <behdad@gnome.org>

        Bug 328206 – Update/remove some old files

        * docs/TEXT/{coding-style,modules,questions,ligatures,western-design}:
        Removed.

        * HACKING: Added.  Renamed from docs/TEXT/coding-style.

        * Makefile.am: Add HACKING.

5 files changed, 0 insertions, 245 deletions

diff --git a/docs/TEXT/coding-style b/docs/TEXT/coding-style
deleted file mode 100644
index f58b0d2b..00000000
--- a/docs/TEXT/coding-style
+++ /dev/null
@@ -1,117 +0,0 @@
-Formatting
-==========
-
-All parts of Pango other than modules should use the following formatting
-style; for modules, it is up to the discretion of the module 
-author / maintainer, though they are encouraged to follow the following.
-
-The Pango formatting style is basically the GNU style of formatting
-(see http://www.gnu.org/prep/standards.html), with a few additions.
-In brief overview:
-
- - Two character indents are used; braces go on a separate line, and 
-   get a separate indentation level, so the total indent for an
-   enclosed block is 4 characters.
-
-    if (x < foo (y, z))
-      haha = bar[4] + 5;
-    else
-      {
-	while (z)
-	  {
-	    haha += foo (z, z);
-	    z--;
-	  }
-	return abc (haha);
-      }
-
- - Spaces should be present between function name and argument block,
-   and after commas.
-
-     foo (z, z)
-
- - In pointer types, the '*' is grouped with the variable name,
-   not with the base type. 
-
-    int *a;
-
-   NOT: 'int* a'.
-
-   In cases where there is no variable name, for instance, return
-   values, there should be a single space between the base type 
-   and the '*'.
-
- - function and variable names are lower_case_with_underscores
-   type names are StudlyCaps, macro names are UPPER_CASE_WITH_UNDERSCORES
-
-
-Documentation comments
-======================
-
-All public API functions should have inline documentation headers
-in the gtk-doc / gnome-doc style. For instance:
-
-/**
- * pango_layout_get_line:
- * @layout: a #PangoLayout
- * @line: the index of a line, which must be between 0 and
- *        pango_layout_get_line_count(layout) - 1, inclusive.
- * 
- * Retrieves a particular line from a #PangoLayout
- * 
- * Return value: the requested #PangoLayoutLine, or %NULL if the
- *               index is out of range. This layout line can
- *               be ref'ed and retained, but will become invalid
- *               if changes are made to the #PangoLayout.
- *
- * Since: 1.6
- **/
-PangoLayoutLine *
-pango_layout_get_line (PangoLayout *layout,
-		       int          line)
-[...]
-
-An Emacs lisp file is distributed with gnome-libs which automates
-inserting these comments
-
-Choosing Function Names
-=======================
-
-- Don't abbreviate in unexpected ways:
-
-    pango_layout_get_line_count ()
-
-  Not:
-
-    pango_layout_ln_cnt ()
-
-- function that retrieve a value in a side-effect free fashion, should
-  include "get" in the name.
-
-    int pango_layout_get_line_count (PangoLayout *layout)
-
-  not 
-
-    pango_layout_line_count ()
-
-
-- functions that set a single parameter in a side-effect free fashion
-  should include "set" in the name, for instance:
-
-  void pango_layout_set_width (PangoLayout    *layout,
-			       int             width);
-
-Other comments
-==============
-
-- Avoid unsigned values for all but flags fields. This is because
-  the way C handles unsigned values generates bugs like crazy:
-
-  If width is unsigned and 10, then:
-
-   int new_width = MAX (width - 15, 1);
-
-  produces 4294967291, not 1.
-
-
-
diff --git a/docs/TEXT/ligatures b/docs/TEXT/ligatures
deleted file mode 100644
index 6bc7e45f..00000000
--- a/docs/TEXT/ligatures
+++ /dev/null
@@ -1,33 +0,0 @@
-PANGO_LIGATURE_HACK is defined as follows
-
-It comprises a space-seperated list of elements. An 
-element can either be of the form :xx:zzzz, in which 
-case the first part is a language code and the second 
-is a name of another property to look in if the
-language is matched.
-   
-or as follows
-
-  $AAAA=0000+007F-0915,0944
-
-  This defines a set, this will be visible to the entire font.
-    
-or of the form
-  
-  xxxx[+xxxx[+xxxx...]]=yyyy[+yyyy]
-
-  xxxx can either be a hex glyph code which is matches directly, 
-  or %AAAA, where it will match anything in the set.
-
-  yyyy is either a hex glyph code, or %n, in which case it refers
-  to the nth thing to have matched - e.g.
-
-  %FOO+2=2+%1,   would swap instances of $FOO and 2.
-
-
-
-(The language-specific stuff isn't implemented yet, but is parsed OK
- and duly ignored here. This will be implemented soon)
-
-
-Robert Brady <rwb197@zepler.org>, 2000-11-08
diff --git a/docs/TEXT/modules b/docs/TEXT/modules
deleted file mode 100644
index 5e250bc8..00000000
--- a/docs/TEXT/modules
+++ /dev/null
@@ -1,42 +0,0 @@
-General points
-==============
-
-One global entry point for each module:
-
-g_i18n_list_functions()
-
- function : language : vtable
-
-
-Tool:
-
- gi18n-updatedb
-
-Input Method Module
-===================
-
- Functions:
-
- Callbacks:
-
-   Set the status area contents
-   Set the preedit string contents
-   Position the caret
-   Begin preediting
-   End preediting
-
-Shaping Module
-=============
-
- Segment input text
- Turn characters into glyphs
- Provide line-break information 
- 
-
-Output Modules
-==============
-
- Position/justify glyphs
-
-
-
diff --git a/docs/TEXT/questions b/docs/TEXT/questions
deleted file mode 100644
index a74b8649..00000000
--- a/docs/TEXT/questions
+++ /dev/null
@@ -1,19 +0,0 @@
-- Is it worth splitting off display-font independent stuff
-  from display dependent stuff. How do we do that?
-
-- Can we abandon XIM? Can we support XIM in backwards-compatibility
-  mode? Just in RootWindow mode?
-
-- Are input methods windowing system independent? What do
-  we gain/lose?
-
-- Do we need to worry about glyph changes at line breaks?
-
-- Do we ever need to break clusters on line breaks?
-
-- Do input methods need attributed strings for displaying
-  feedback? If so, do we build such support into GDK?
-  Into GTK+?
-
-- How do we index positions in a string 
-  (By character? By byte?)
diff --git a/docs/TEXT/western-design b/docs/TEXT/western-design
deleted file mode 100644
index 57c81dba..00000000
--- a/docs/TEXT/western-design
+++ /dev/null
@@ -1,34 +0,0 @@
-Issues that this engine needs to handle:
-
- - Picking the right character based on language/character
- - Composition of combining diacriticals - should use precomposed
-   diacriticals when possible
- - Finding word/line/breaks
-
-For each sequence of character + combining marks
-
- - Find combined representations from most combined to least combined.
- - If there are particular characters for this combination, use
-   them, otherwise 
-
-==========
-
-Ligature table per font.
-Pick fonts in order of preference according to LANG
-
-Characterstics of western/basic:
-
- Consistent LTR
- No reordering
- Many characters => one glyph
- Character/Word/Line breaking dependent only on character properties
-
-Issues
- 
- Accent placement for Greek, Vietnamese
- How do we handle a case where lang == en_US, we have a glyph
-   combination with a combined form in iso-8859-2 but not
-   in iso-8859-1?
-
-
-