gnue/common/doc/technotes 00002.txt

[Arturas Kriukovas]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Arturas Kriukovas <address@hidden>      02/09/19 10:02:58

Modified files:
        common/doc/technotes: 00002.txt 

Log message:
        Updated documentation.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/common/doc/technotes/00002.txt.diff?tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: gnue/common/doc/technotes/00002.txt
diff -c gnue/common/doc/technotes/00002.txt:1.2 
gnue/common/doc/technotes/00002.txt:1.3
*** gnue/common/doc/technotes/00002.txt:1.2     Wed Jul 31 10:28:43 2002
--- gnue/common/doc/technotes/00002.txt Thu Sep 19 10:02:58 2002
***************
*** 63,77 ****
      different languages himself, some automated translation may be added 
later.
  
  
!     This is already finished.
  
  
!  2. User data - everything that user stores/works with will be stored in 
!     unicode (encoded in UTF-8).
  
      For data that's entered as 8bit encoded data. This was checked with 
!     postgresql database, with adapter psycopg and for iso8859-13 encoding and 
it
!     worked fine.
      Settings in gnue.conf were:
  
        # hack for db encoding
--- 63,98 ----
      different languages himself, some automated translation may be added 
later.
  
  
!     Using wx UI driver, it's possible to work with 8bit (one-byte; 
non-unicode)
!     fonts - gettext takes care of labels, status bar messages, user can input
!     text, save it to database, read from there and see it nicely. It is not
!     possible to enter/edit/save/view unicode text, unless xterm (from what 
!     forms client is started) is unicode, then it is possible only to view 
!     unicode text.
  
+     Using gtk2 UI driver, it's possible to work with unicode fonts - user can
+     input text (in unicode, not in some one-byte font), save it to database,
+     read from there and see it nicely. However, gettext translations for 
labels
+     and etc. breaks it (sometimes they are not displayed, sometimes it's only
+     half of them). If client is started from non-unicode xterm, it's only 
+     possible to read unicode characters.
  
!     Note that 'Hack for dn encoding' parameter in gnue.conf has also influence
!     on data - with iso8859-13 xterm, wx user interface and utf-8 db encoding,
!     it was not possible to write some chars correctly, as well as chars 
written
!     previously with iso8859-13 db encoding were not displayed correctly.
!     Also, with iso8859-13 db encoding (iso8859-13 xterm, wx user interface)
!     chars previously written with utf-8 db encoding were not displayed
!     correctly.
! 
! 
!  2. User data - everything that user stores/works with final decision should
!     depend on user, but both one-byte encodings (like iso8859-13) and unicode
!     (encoded as utf-8) should be available.
  
      For data that's entered as 8bit encoded data. This was checked with 
!     postgresql database, with adapter psycopg, with iso8859-13 encoding, wx
!     user interface driver and it worked fine.
      Settings in gnue.conf were:
  
        # hack for db encoding
***************
*** 79,84 ****
--- 100,109 ----
  
        # Font encoding to be used in forms
        formFontEncoding = iso8859-13
+ 
+     For data that's entered as unicode data. This was checked with postgresql
+     database, with adapter psycopg, with gtk2 uiser interface driver and it 
+     worked fine.
  
  
   3. Regional settings - this is time\date, money and etc. format and other