From 7df0a3ce73ad8c6d0bf60bf2dbff1c50e8aa6242 Mon Sep 17 00:00:00 2001 From: Behdad Esfahbod Date: Tue, 21 Feb 2006 11:58:09 +0000 Subject: =?UTF-8?q?Bug=20328206=20=E2=80=93=20Update/remove=20some=20old?= =?UTF-8?q?=20files?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 2006-02-21 Behdad Esfahbod 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. --- ChangeLog | 11 +++++ HACKING | 113 +++++++++++++++++++++++++++++++++++++++++++++ Makefile.am | 5 +- docs/TEXT/coding-style | 117 ----------------------------------------------- docs/TEXT/ligatures | 33 ------------- docs/TEXT/modules | 42 ----------------- docs/TEXT/questions | 19 -------- docs/TEXT/western-design | 34 -------------- 8 files changed, 127 insertions(+), 247 deletions(-) create mode 100644 HACKING delete mode 100644 docs/TEXT/coding-style delete mode 100644 docs/TEXT/ligatures delete mode 100644 docs/TEXT/modules delete mode 100644 docs/TEXT/questions delete mode 100644 docs/TEXT/western-design diff --git a/ChangeLog b/ChangeLog index 5cfc27fb..d1aa4b65 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2006-02-21 Behdad Esfahbod + + 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. + 2006-02-21 Behdad Esfahbod Bug 314239 – pangocairo crashes when font cannot be read diff --git a/HACKING b/HACKING new file mode 100644 index 00000000..dc02f5ee --- /dev/null +++ b/HACKING @@ -0,0 +1,113 @@ +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 (or @layout.) + * + * 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) +[...] + + +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/Makefile.am b/Makefile.am index f797e66b..46058273 100644 --- a/Makefile.am +++ b/Makefile.am @@ -22,8 +22,9 @@ EXTRA_DIST = \ ChangeLog.pre-1-6 \ ChangeLog.pre-1-8 \ MAINTAINERS \ - README.win32 \ - pango-zip.sh \ + HACKING \ + README.win32 \ + pango-zip.sh \ sanitize-la.sh pkgconfigdir = $(libdir)/pkgconfig 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 , 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? - - - -- cgit v1.2.1