From c9908d97e3ab4e4d0cd87435c52aea88a5a4abc0 Mon Sep 17 00:00:00 2001 From: Matthias Melcher Date: Tue, 18 Apr 2006 13:07:42 +0000 Subject: 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 | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'documentation') diff --git a/documentation/drawing.html b/documentation/drawing.html index a867dc7bc..d7d36def6 100644 --- a/documentation/drawing.html +++ b/documentation/drawing.html @@ -598,6 +598,34 @@ the display. fl_font(a,b). This can be used to save/restore the font. +

Character Encoding

+ +

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. + +

FLTK provides the functions fl_latin1_to_local, +fl_local_to_latin1, fl_mac_roman_to_local, and +fl_local_to_mac_roman 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. + +

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 +Fahrvergn¸gen with a deformed umlaut u. +

+  btn = new Fl_Button(10, 10, 300, 25);
+  btn->copy_label(fl_latin1_to_local("Fahrvergnügen"));
+
+ +

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. +

Drawing Overlays

These functions allow you to draw interactive selection rectangles -- cgit v1.2.3