fltk/src/fl_encoding_latin1.cxx

164 lines
5.1 KiB
C++
Raw Normal View History

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
2006-04-18 13:07:42 +00:00
//
// Convert Windows-1252 (Latin-1) encoded text to the local encoding.
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
2006-04-18 13:07:42 +00:00
//
// Copyright 1998-2016 by Bill Spitzak and others.
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
2006-04-18 13:07:42 +00:00
//
// This library is free software. Distribution and use rights are outlined in
// the file "COPYING" which should have been included with this file. If this
// file is missing or damaged, see the license at:
//
// https://www.fltk.org/COPYING.php
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
2006-04-18 13:07:42 +00:00
//
// Please see the following page on how to report bugs and issues:
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
2006-04-18 13:07:42 +00:00
//
// https://www.fltk.org/bugs.php
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
2006-04-18 13:07:42 +00:00
//
#include "config_lib.h"
#include <FL/fl_draw.H>
#include <FL/Fl.H>
#include "Fl_System_Driver.H"
#include <FL/Enumerations.H>
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
2006-04-18 13:07:42 +00:00
#include <stdlib.h>
#include "flstring.h"
#ifdef FL_CFG_WIN_COCOA
#include "drivers/Darwin/Fl_Darwin_System_Driver.H"
// These function assume a western code page. If you need to support
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
2006-04-18 13:07:42 +00:00
// scripts that are not part of this code page, you might want to
// take a look at FLTK2, which uses utf8 for text encoding.
//
// By keeping these conversion tables in their own module, they will not
// be statically linked (by a smart linker) unless actually used.
//
// On MS-Windows, nothing need to be converted. We simply return the
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
2006-04-18 13:07:42 +00:00
// original pointer.
//
// Most X11 implementations seem to default to Latin-1 as a code since it
// is a superset of ISO 8859-1, the original wetsern codepage on X11.
//
// Apple's OS X however renders text in MacRoman for western settings. The
// lookup tables below will convert all common character codes and replace
// unknown characters with an upsidedown question mark.
// This table converts Windows-1252/Latin 1 into MacRoman encoding
static uchar latin2roman[128] = {
0xdb, 0xc0, 0xe2, 0xc4, 0xe3, 0xc9, 0xa0, 0xe0, 0xf6, 0xe4, 0xc0, 0xdc, 0xce, 0xc0, 0xc0, 0xc0,
0xc0, 0xd4, 0xd5, 0xd2, 0xd3, 0xa5, 0xd0, 0xd1, 0xf7, 0xaa, 0xc0, 0xdd, 0xcf, 0xc0, 0xc0, 0xd9,
0xca, 0xc1, 0xa2, 0xa3, 0xc0, 0xb4, 0xc0, 0xa4, 0xac, 0xa9, 0xbb, 0xc7, 0xc2, 0xc0, 0xa8, 0xf8,
0xa1, 0xb1, 0xc0, 0xc0, 0xab, 0xb5, 0xa6, 0xe1, 0xfc, 0xc0, 0xbc, 0xc8, 0xc0, 0xc0, 0xc0, 0xc0,
0xcb, 0xe7, 0xe5, 0xcc, 0x80, 0x81, 0xae, 0x82, 0xe9, 0x83, 0xe6, 0xe8, 0xed, 0xea, 0xeb, 0xec,
0xc0, 0x84, 0xf1, 0xee, 0xef, 0xcd, 0x85, 0xc0, 0xaf, 0xf4, 0xf2, 0xf3, 0x86, 0xc0, 0xc0, 0xa7,
0x88, 0x87, 0x89, 0x8b, 0x8a, 0x8c, 0xbe, 0x8d, 0x8f, 0x8e, 0x90, 0x91, 0x93, 0x92, 0x94, 0x95,
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
2006-04-18 13:07:42 +00:00
0xc0, 0x96, 0x98, 0x97, 0x99, 0x9b, 0x9a, 0xd6, 0xbf, 0x9d, 0x9c, 0x9e, 0x9f, 0xc0, 0xc0, 0xd8
};
// This table converts MacRoman into Windows-1252/Latin 1
static uchar roman2latin[128] = {
0xc4, 0xc5, 0xc7, 0xc9, 0xd1, 0xd6, 0xdc, 0xe1, 0xe0, 0xe2, 0xe4, 0xe3, 0xe5, 0xe7, 0xe9, 0xe8,
0xea, 0xeb, 0xed, 0xec, 0xee, 0xef, 0xf1, 0xf3, 0xf2, 0xf4, 0xf6, 0xf5, 0xfa, 0xf9, 0xfb, 0xfc,
0x86, 0xb0, 0xa2, 0xa3, 0xa7, 0x95, 0xb6, 0xdf, 0xae, 0xa9, 0x99, 0xb4, 0xa8, 0xbf, 0xc6, 0xd8,
0xbf, 0xb1, 0xbf, 0xbf, 0xa5, 0xb5, 0xbf, 0xbf, 0xbf, 0xbf, 0xbf, 0xaa, 0xba, 0xbf, 0xe6, 0xf8,
0xbf, 0xa1, 0xac, 0xbf, 0x83, 0xbf, 0xbf, 0xab, 0xbb, 0x85, 0xa0, 0xc0, 0xc3, 0xd5, 0x8c, 0x9c,
0x96, 0x97, 0x93, 0x94, 0x91, 0x92, 0xf7, 0xbf, 0xff, 0x9f, 0xbf, 0x80, 0x8b, 0x9b, 0xbf, 0xbf,
0x87, 0xb7, 0x82, 0x84, 0x89, 0xc2, 0xca, 0xc1, 0xcb, 0xc8, 0xcd, 0xce, 0xcf, 0xcc, 0xd3, 0xd4,
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
2006-04-18 13:07:42 +00:00
0xbf, 0xd2, 0xda, 0xdb, 0xd9, 0xbf, 0x88, 0x98, 0xaf, 0xbf, 0xbf, 0xbf, 0xb8, 0xbf, 0xbf, 0xbf
};
static char *buf = 0;
static int n_buf = 0;
const char *Fl_Darwin_System_Driver::latin1_to_local(const char *t, int n)
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
2006-04-18 13:07:42 +00:00
{
if (n==-1) n = strlen(t);
if (n<=n_buf) {
n_buf = (n + 257) & 0x7fffff00;
if (buf) free(buf);
buf = (char*)malloc(n_buf);
}
const uchar *src = (const uchar*)t;
uchar *dst = (uchar*)buf;
for ( ; n>0; n--) {
uchar c = *src++;
if (c>127)
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
2006-04-18 13:07:42 +00:00
*dst = latin2roman[c-128];
else
*dst = c;
}
//*dst = 0; // this would be wrong!
return buf;
}
const char *Fl_Darwin_System_Driver::local_to_latin1(const char *t, int n)
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
2006-04-18 13:07:42 +00:00
{
if (n==-1) n = strlen(t);
if (n<=n_buf) {
n_buf = (n + 257) & 0x7fffff00;
if (buf) free(buf);
buf = (char*)malloc(n_buf);
}
const uchar *src = (const uchar*)t;
uchar *dst = (uchar*)buf;
for ( ; n>0; n--) {
uchar c = *src++;
if (c>127)
*dst++ = roman2latin[c-128];
else
*dst++ = c;
}
//*dst = 0; // this would be wrong
return buf;
}
#endif
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
2006-04-18 13:07:42 +00:00
/**
\cond DriverDev
\addtogroup DriverDeveloper
\{
*/
/**
Default implementation of latin-to-local text conversion.
The default implementation returns the original text. This method should
be reimplemented by drivers for platforms that commonly use latin
text encoding.
\see fl_latin1_to_local(const char *, int)
*/
const char *Fl_System_Driver::latin1_to_local(const char *t, int)
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
2006-04-18 13:07:42 +00:00
{
return t;
}
/**
Default implementation of local-to-latin text conversion.
The default implementation returns the original text. This method should
be reimplemented by drivers for platforms that commonly use latin
text encoding.
\see fl_local_to_latin1(const char *, int)
*/
const char *Fl_System_Driver::local_to_latin1(const char *t, int)
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
2006-04-18 13:07:42 +00:00
{
return t;
}
/**
\}
\endcond
*/
const char *fl_latin1_to_local(const char *t, int n)
{
return Fl::system_driver()->latin1_to_local(t, n);
}
const char *fl_local_to_latin1(const char *t, int n)
{
return Fl::system_driver()->local_to_latin1(t, n);
}