THIS FIX CONTAINS TWO MORE FILES THAT MUST BE COMPILED. I would

like to ask the maintainers of the build environments to please
add these files to the setup:

  src/fl_encoding_latin1.cxx
  src/fl_encoding_mac_roman.cxx

I ADDED SOME DOCUMENTATION THAT NEEDS TO BE FIXED. Beeing not a
native English speaker, I have a hard time writing documentation.
Would someone please update my babbeling in 
documentation/drawing.html? Thanks.

This commit fixes some very basic problems with OS X's code page in
preparation for the compose-character keyboard fix. It also fixes
issues with MS Windows and X11 not rendering the characters
in the Western (Latin-1) set between 0x80 and 0x9F. In the original
ISO font, they were unused, but are now assigned to international
characters like the Euro currency sign.

This patch also tries to fix one basic flaw with FLTK 1 and
font encoding. I will not put much more work into this because
FLTK 1.2 and FLTK 2 fix the problem entirely by using UTF-8
instead of 8-bit "C"-style strings.

All these changes are only meaningful for foreign language
users or users of special characters like the Euro, the Degree
or the Permille symbol. A short explanation follows.

Max OS X uses a different code page than X11 and Win32. This means
that all characters above 0x7f have an entirely different meaning.
If your source code contains international characters, your 
text will appear different if you change to another OS. This patch
provides two functions that convert text with international
characters from the character set of the source code into the
local character set. Two more functions are provided to convert
them back. The functions are fl_latin1_to_local (source is in Win32 
or X11), fl_mac_roman_to_local (source was written on OS X) and the 
corresponding fl_local_to_latin1 and fl_local_to_mac_roman, which
are very useful if yoou want to store strings with intl. characters
that will be moved between systems.

All this is assuming a "Western" code page as it is common in
the Americas and most of Europe. User of other languages will have 
to use FLTK 2.



git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@4975 ea41ed52-d2ee-0310-a9c1-e6b18d33e121

documentation/drawing.html

@@ -598,6 +598,34 @@ the display.
 <TT>fl_font(a,b)</TT>. This can be used to save/restore the
 font.
 
+<H3>Character Encoding</H3>
+
+<P>FLTK 1 supports western character sets using the eight bit encoding
+of the user-selected global code page. For MS Windows and X11, the code
+page is assumed to be Windows-1252/Latin1, a superset to ISO 8859-1. 
+On Mac OS X, we assume MacRoman.
+
+<P>FLTK provides the functions <tt>fl_latin1_to_local</tt>, 
+<tt>fl_local_to_latin1</tt>, <tt>fl_mac_roman_to_local</tt>, and
+<tt>fl_local_to_mac_roman</tt> to convert strings between both
+encodings. These functions are only required if your source
+code contains "C"-strings with international characters and 
+if this source will be compiled on multiple platforms.
+
+<P>Assuming that the following source code was written on MS Windows, 
+this example will output the correct label on OS X and X11 as well.
+Without the conversion call, the label on OS X would read 
+<tt>Fahrvergn&cedil;gen</tt> with a deformed umlaut u.
+<PRE>
+  btn = new Fl_Button(10, 10, 300, 25);
+  btn->copy_label(fl_latin1_to_local("Fahrvergn&uuml;gen"));
+</PRE>
+
+<P>If your application uses characters that are not part of both
+encodings, or it will be used in areas that commonly use different
+code pages, yoou might consider upgrading to FLTK 2 which supports
+UTF-8 encoding. 
+
 <H3><A name="overlay">Drawing Overlays</A></H3>
 
 <P>These functions allow you to draw interactive selection rectangles