This is latin-unity.info, produced by makeinfo version 4.6 from
latin-unity.texi.

START-INFO-DIR-ENTRY
* latin-unity::                Remap Latin characters from a single charset.
END-INFO-DIR-ENTRY

   This file is part of XEmacs.  It documents the latin-unity package,
which ensures that wherever possible representations of all Latin
characters are drawn from the same 8-bit character set.

   Copyright (C) 2002 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "Copying" and "GNU General Public License"
are included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the Free Software Foundation.


File: latin-unity.info,  Node: Top,  Next: Copying,  Prev: (dir),  Up: (dir)

Latin Unity for Emacsen
***********************

Mule suffers from a design defect that causes it to consider the ISO
Latin character sets to be disjoint.  This results in oddities such as
files containing both ISO 8859/1 and ISO 8859/15 codes, and using ISO
2022 control sequences to switch between them, as well as more plausible
but often unnecessary combinations like ISO 8859/1 with ISO 8859/2.
This can be very annoying when sending messages or even in simple
editing on a single host.  latin-unity works around the problem by
converting as many characters as possible to use a single Latin coded
character set before saving the buffer.

   This is version 1.0 of the latin-unity manual, last updated on
Thursday 2002 March 23.

* Menu:

* Copying::                     latin-unity copying conditions.
* Overview::                    latin-unity history and general information.

For general users:
* Usage::                       An overview of the operation of latin-unity.
* Installation::                Installing latin-unity with your (X)Emacs.
* Configuration::               Configuring latin-unity for use.
* Bug Reports::                 Reporting bugs and problems.
* Frequently Asked Questions::  Questions and answers from the mailing list.
* Theory of Operation::         How latin-unity works.
* What latin-unity Cannot Do for You::  Inherent problems of 8-bit charsets.

For programmers:
* Interfaces::                  Calling latin-unity from Lisp code.
* Charsets and Coding Systems:: Reference lists with annotations.

For maintainers:
* Internals::                   Utilities and implementation details.


File: latin-unity.info,  Node: Copying,  Next: Overview,  Prev: Top,  Up: Top

latin-unity Copying Conditions
******************************

Copyright (C) 2002 Free Software Foundation, Inc.

   latin-unity is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option) any
later version.

   latin-unity is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.

   You should have received a copy of the GNU General Public License
along with XEmacs; see the file COPYING. If not, write to the Free
Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.


File: latin-unity.info,  Node: Overview,  Next: Usage,  Prev: Copying,  Up: Top

An Overview of latin-unity
**************************

Mule suffers from a design defect that causes it to consider the ISO
Latin character sets to be disjoint.  This manifests itself when a user
enters characters using input methods associated with different coded
character sets into a single buffer.

   A very important example involves email.  Many sites, especially in
the U.S., default to use of the ISO 8859/1 coded character set (also
called "Latin 1," though these are somewhat different concepts).
However, ISO 8859/1 provides a generic CURRENCY SIGN character.  Now
that the Euro has become the official currency of most countries in
Europe, this is unsatisfactory (and in practice, useless).  So
Europeans generally use ISO 8859/15, which is nearly identical to ISO
8859/1 for most languages, except that it substitutes EURO SIGN for
CURRENCY SIGN.

   Suppose a European user yanks text from a post encoded in ISO 8859/1
into a message composition buffer, and enters some text including the
Euro sign.  Then Mule will consider the buffer to contain both ISO
8859/1 and ISO 8859/15 text, and MUAs such as Gnus will (if naively
programmed) send the message as a multipart mixed MIME body!

   This is clearly stupid.  What is not as obvious is that, just as any
European can include American English in their text because ASCII is a
subset of ISO 8859/15, most European languages which use Latin
characters (eg, German and Polish) can typically be mixed while using
only one Latin coded character set (in this case, ISO 8859/2).  However,
this often depends on exactly what text is to be encoded.

   latin-unity works around the problem by converting as many
characters as possible to use a single Latin coded character set before
saving the buffer.


File: latin-unity.info,  Node: Usage,  Next: Installation,  Prev: Overview,  Up: Top

Operation of latin-unity
************************

Normally, latin-unity works in the background by installing
`latin-unity-sanity-check' on `write-region-pre-hook'.  The user
activates this functionality by invoking `latin-unity-install', either
interactively or in her init file.  *Note Init File: (xemacs)Init File.
latin-unity can be deactivated by invoking `latin-unity-uninstall'.

   latin-unity also provides a few functions for remapping or recoding
the buffer by hand.  To "remap" a character means to change the buffer
representation of the character by using another coded character set.
Remapping never changes the identity of the character, but may involve
altering the code point of the character.  To "recode" a character
means to simply change the coded character set.  Recoding never alters
the code point of the character, but may change the identity of the
character.  *Note Theory of Operation::.

   There are a few variables which determine which coding systems are
always acceptable to latin-unity:  `latin-unity-ucs-list',
`latin-unity-preferred-coding-system-list', and
`latin-unity-preapproved-coding-system-list'.  The latter two default
to `()', and should probably be avoided because they short-circuit the
sanity check.  If you find you need to use them, consider reporting it
as a bug or request for enhancement.  Because they seem unsafe, the
recommended interface is likely to change.

* Menu:

* Basic Functionality::            User interface and customization.
* Interactive Usage::              Treating text by hand.
                                   Also documents the hook function(s).


File: latin-unity.info,  Node: Basic Functionality,  Next: Interactive Usage,  Up: Usage

Basic Functionality
===================

These functions and user options initialize and configure latin-unity.
In normal use, only a call to `latin-unity-install' is needed.

 - Function: latin-unity-install
     Set up hooks and initialize variables for latin-unity.

     There are no arguments.

     This function is idempotent.  It will reinitialize any hooks or
     variables that are not in initial state.

     Note: a quirk in XEmacs means that the `cl-macs' library cannot be
     required, it must be loaded explicitly.  This means that if you
     invoke `latin-unity-install' in your init file, XEmacs will print
          Loading cl-macs...
          Loading cl-macs...done
     on your console, as these messages have not yet been redirected to
     the ` *Message-Log*' buffer.

 - Function: latin-unity-uninstall
     There are no arguments.

     Clean up hooks and void variables used by latin-unity.

 - User Option: latin-unity-ucs-list
     List of coding systems considered to be universal.

     The default value is `'(utf-8 iso-2022-7 ctext escape-quoted)'.

     Order matters; coding systems earlier in the list will be
     preferred when recommending a coding system.  These coding systems
     will not be used without querying the user (unless they are also
     present in `latin-unity-preapproved-coding-system-list'), and
     follow the `latin-unity-preferred-coding-system-list' in the list
     of suggested coding systems.

     If none of the preferred coding systems are feasible, the first in
     this list will be the default.

     Notes on certain coding systems:  `escape-quoted' is a special
     coding system used for autosaves and compiled Lisp in Mule.  You
     should not delete this, although it is rare that a user would want
     to use it directly.  latin-unity does not try to be \"smart\"
     about other general ISO 2022 coding systems, such as ISO-2022-JP.
     (They are not recognized as equivalent to `iso-2022-7'.)  If your
     preferred coding system is one of these, you may consider adding
     it to `latin-unity-ucs-list'.  However, this will typically have
     the side effect that (eg) ISO 8859/1 files will be saved in 7-bit
     form with ISO 2022 escape sequences.

   Coding systems which are not Latin and not in `latin-unity-ucs-list'
are handled by short circuiting checks of coding system against the
next two variables.

 - User Option: latin-unity-preapproved-coding-system-list
     List of coding systems used without querying the user if feasible.

     The default value is `(buffer-default preferred)'.

     The first feasible coding system in this list is used.  The
     special values `preferred' and `buffer-default' may be present:

    `buffer-default'
          Use the coding system used by `write-region', if feasible.

    `preferred'
          Use the coding system specified by `prefer-coding-system' if
          feasible.

     "Feasible" means that all characters in the buffer can be
     represented by the coding system.  Coding systems in
     `latin-unity-ucs-list' are always considered feasible.  Other
     feasible coding systems are computed by
     `latin-unity-representations-feasible-region'.

     Note that the first universal coding system in this list shadows
     all other coding systems.  In particular, if your preferred coding
     system is a universal coding system, and `preferred' is a member
     of this list, latin-unity will blithely convert all your files to
     that coding system.  This is considered a feature, but it may
     surprise most users.  Users who don't like this behavior should
     put `preferred' in `latin-unity-preferred-coding-system-list'.

 - User Option: latin-unity-preferred-coding-system-list
     List of coding systems suggested the user if feasible.

     The default value is `(iso-8859-1 iso-8859-15 iso-8859-2 iso-8859-3
     iso-8859-4 iso-8859-9)'.

     If none of the coding systems in
     `latin-unity-preferred-coding-system-list' are feasible, this list
     will be recommended to the user, followed by the
     `latin-unity-ucs-list' (so those coding systems should not be in
     this list).  The first coding system in this list is default.  The
     special values `preferred' and `buffer-default' may be present:

    `buffer-default'
          Use the coding system used by `write-region', if feasible.

    `preferred'
          Use the coding system specified by `prefer-coding-system' if
          feasible.

     "Feasible" means that all characters in the buffer can be
     represented by the coding system.  Coding systems in
     `latin-unity-ucs-list' are always considered feasible.  Other
     feasible coding systems are computed by
     `latin-unity-representations-feasible-region'.

 - Variable: latin-unity-iso-8859-1-aliases
     List of coding systems to be treated as aliases of ISO 8859/1.

     The default value is '(iso-8859-1).

     This is not a user variable; to customize input of coding systems
     or charsets, `latin-unity-coding-system-alias-alist' or
     `latin-unity-charset-alias-alist'.


File: latin-unity.info,  Node: Interactive Usage,  Prev: Basic Functionality,  Up: Usage

Interactive Usage
=================

First, the hook function `latin-unity-sanity-check' is documented.  (It
is placed here because it is not an interactive function, and there is
not yet a programmer's section of the manual.)

   These functions provide access to internal functionality (such as the
remapping function) and to extra functionality (the recoding functions
and the test function).

 - Function: latin-unity-sanity-check begin end filename append visit
          lockname &optional coding-system
     Check if CODING-SYSTEM can represent all characters between BEGIN
     and END.

     For compatibility with old broken versions of `write-region',
     CODING-SYSTEM defaults to `buffer-file-coding-system'.  FILENAME,
     APPEND, VISIT, and LOCKNAME are ignored.

     Return nil if buffer-file-coding-system is not
     (ISO-2022-compatible) Latin.  If `buffer-file-coding-system' is
     safe for the charsets actually present in the buffer, return it.
     Otherwise, ask the user to choose a coding system, and return that.

     This function does _not_ do the safe thing when
     `buffer-file-coding-system' is nil (aka no-conversion).  It
     considers that "non-Latin," and passes it on to the Mule detection
     mechanism.

     This function is intended for use as a `write-region-pre-hook'.  It
     does nothing except return CODING-SYSTEM if `write-region'
     handlers are inhibited.

 - Function: latin-unity-buffer-representations-feasible
     There are no arguments.

     Apply latin-unity-region-representations-feasible to the current
     buffer.

 - Function: latin-unity-region-representations-feasible begin end
          &optional buf
     Return character sets that can represent the text from BEGIN to
     END in BUF.

     BUF defaults to the current buffer.  Called interactively, will be
     applied to the region.  Function assumes BEGIN <= END.

     The return value is a cons.  The car is the list of character sets
     that can individually represent all of the non-ASCII portion of the
     buffer, and the cdr is the list of character sets that can
     individually represent all of the ASCII portion.

     The following is taken from a comment in the source.  Please refer
     to the source to be sure of an accurate description.

     The basic algorithm is to map over the region, compute the set of
     charsets that can represent each character (the "feasible
     charset"), and take the intersection of those sets.

     The current implementation takes advantage of the fact that ASCII
     characters are common and cannot change asciisets.  Then using
     skip-chars-forward makes motion over ASCII subregions very fast.

     This same strategy could be applied generally by precomputing
     classes of characters equivalent according to their effect on
     latinsets, and adding a whole class to the skip-chars-forward
     string once a member is found.

     Probably efficiency is a function of the number of characters
     matched, or maybe the length of the match string?  With
     `skip-category-forward' over a precomputed category table it
     should be really fast.  In practice for Latin character sets there
     are only 29 classes.

 - Function: latin-unity-remap-region begin end character-set &optional
          coding-system
     Remap characters between BEGIN and END to equivalents in
     CHARACTER-SET.  Optional argument CODING-SYSTEM may be a coding
     system name (a symbol) or nil.  Characters with no equivalent are
     left as-is.

     When called interactively, BEGIN and END are set to the beginning
     and end, respectively, of the active region, and the function
     prompts for CHARACTER-SET.  The function does completion, knows
     how to guess a character set name from a coding system name, and
     also provides some common aliases.  See
     `latin-unity-guess-charset'.  There is no way to specify
     CODING-SYSTEM, as it has no useful function interactively.

     Return CODING-SYSTEM if CODING-SYSTEM can encode all characters in
     the region, t if CODING-SYSTEM is nil and the coding system with
     G0 = 'ascii and G1 = CHARACTER-SET can encode all characters, and
     otherwise nil.  Note that a non-null return does _not_ mean it is
     safe to write the file, only the specified region.  (This behavior
     is useful for multipart MIME encoding and the like.)

     Note:  by default this function is quite fascist about universal
     coding systems.  It only admits `utf-8', `iso-2022-7', and
     `ctext'.  Customize `latin-unity-approved-ucs-list' to change this.

     This function remaps characters that are artificially
     distinguished by Mule internal code.  It may change the code point
     as well as the character set.  To recode characters that were
     decoded in the wrong coding system, use
     `latin-unity-recode-region'.

 - Function: latin-unity-recode-region begin end wrong-cs right-cs
     Recode characters between BEGIN and END from WRONG-CS to RIGHT-CS.

     WRONG-CS and RIGHT-CS are character sets.  Characters retain the
     same code point but the character set is changed.  Only characters
     from WRONG-CS are changed to RIGHT-CS.  The identity of the
     character may change.  Note that this could be dangerous, if
     characters whose identities you do not want changed are included
     in the region.  This function cannot guess which characters you
     want changed, and which should be left alone.

     When called interactively, BEGIN and END are set to the beginning
     and end, respectively, of the active region, and the function
     prompts for WRONG-CS and RIGHT-CS.  The function does completion,
     knows how to guess a character set name from a coding system name,
     and also provides some common aliases.  See
     `latin-unity-guess-charset'.

     Another way to accomplish this, but using coding systems rather
     than character sets to specify the desired recoding, is
     `latin-unity-recode-coding-region'.  That function may be faster
     but is somewhat more dangerous, because it may recode more than one
     character set.

     To change from one Mule representation to another without changing
     identity of any characters, use `latin-unity-remap-region'.

 - Function: latin-unity-recode-coding-region begin end wrong-cs
          right-cs
     Recode text between BEGIN and END from WRONG-CS to RIGHT-CS.

     WRONG-CS and RIGHT-CS are coding systems.  Characters retain the
     same code point but the character set is changed.  The identity of
     characters may change.  This is an inherently dangerous function;
     multilingual text may be recoded in unexpected ways.  #### It's
     also dangerous because the coding systems are not sanity-checked
     in the current implementation.

     When called interactively, BEGIN and END are set to the beginning
     and end, respectively, of the active region, and the function
     prompts for WRONG-CS and RIGHT-CS.  The function does completion,
     knows how to guess a coding system name from a character set name,
     and also provides some common aliases.  See
     `latin-unity-guess-coding-system'.

     Another, safer, way to accomplish this, using character sets
     rather than coding systems to specify the desired recoding, is to
     use `latin-unity-recode-region.

     To change from one Mule representation to another without changing
     identity of any characters, use `latin-unity-remap-region'.

   Helper functions for input of coding system and character set names.

 - Function: latin-unity-guess-charset candidate
     Guess a charset based on the symbol CANDIDATE.

     CANDIDATE itself is not tried as the value.

     Uses the natural mapping in `latin-unity-cset-codesys-alist', and
     the values in `latin-unity-charset-alias-alist'."

 - Function: latin-unity-guess-coding-system candidate
     Guess a coding system based on the symbol CANDIDATE.

     CANDIDATE itself is not tried as the value.

     Uses the natural mapping in `latin-unity-cset-codesys-alist', and
     the values in `latin-unity-coding-system-alias-alist'."

 - Function: latin-unity-example
     A cheesy example for latin-unity.

     At present it just makes a multilingual buffer.  To test, setq
     buffer-file-coding-system to some value, make the buffer dirty (eg
     with RET BackSpace), and save.

 - Function: latin-unity-test
     A simple automated test suite for latin-unity.


File: latin-unity.info,  Node: Installation,  Next: Configuration,  Prev: Usage,  Up: Top

Installing latin-unity with your (X)Emacs
*****************************************

latin-unity may be installed from XEmacs via the package user interface
(accessible from the `Tools' menu or via `M-x list-packages').

   You can also download the `latin-unity-VERSION-pkg.tar.gz' tarball
from <ftp://ftp.xemacs.org/pub/xemacs/packages/>, and simply unpack it
in the usual place.

   latin-unity sources are available from XEmacs's CVS repository.  The
module name is `latin-unity'.  See
`http://www.xemacs.org/Develop/cvsaccess.html' for more information
about XEmacs's CVS repository.


File: latin-unity.info,  Node: Configuration,  Next: Bug Reports,  Prev: Installation,  Up: Top

Configuring latin-unity for Use
*******************************

If you want latin-unity to be automatically initialized, invoke
`latin-unity-install' with no arguments in your init file.  *Note Init
File: (xemacs)Init File.  If you are using GNU Emacs or an XEmacs
earlier than 21.1, you should also load `auto-autoloads' using the full
path (_never_ `require' `auto-autoloads' libraries).

   You may wish to define aliases for commonly used character sets and
coding systems for convenience in input.

 - User Option: latin-unity-charset-alias-alist
     Alist mapping aliases to Mule charset names (symbols)."

     The default value is
             ((latin-1 . latin-iso8859-1)
              (latin-2 . latin-iso8859-2)
              (latin-3 . latin-iso8859-3)
              (latin-4 . latin-iso8859-4)
              (latin-5 . latin-iso8859-9)
              (latin-9 . latin-iso8859-15)
              (latin-10 . latin-iso8859-16))

     If a charset does not exist on your system, it will not complete
     and you will not be able to enter it in response to prompts.  A
     real charset with the same name as an alias in this list will
     shadow the alias.

 - User Option: latin-unity-coding-system-alias-alist nil
     Alist mapping aliases to Mule coding system names (symbols).

     The default value is `nil'.


File: latin-unity.info,  Node: Bug Reports,  Next: Frequently Asked Questions,  Prev: Configuration,  Up: Top

Reporting Bugs and Problems
***************************

Please report bugs to the author, Stephen Turnbull
<stephen@xemacs.org>, or to the developers' mailing list, XEmacs Beta
<xemacs-beta@xemacs.org>.

   Suggestions for improvement are welcome at the same addresses.


File: latin-unity.info,  Node: Frequently Asked Questions,  Next: Theory of Operation,  Prev: Bug Reports,  Up: Top

Frequently Asked Questions
**************************

  1. I'm smarter than latin-unity!  How can that be?

     Don't be surprised.  Trust yourself.

     latin-unity is very young as yet.  Teach it what you know by
     Customizing its variables, and report your changes to the
     maintainer (*note Bug Reports::).

  2. What is a UCS?

     According to ISO 10646, a Universal Coded character Set.  In
     latin-unity, it's Universal (Mule) Coding System.  *Note Coding
     Systems: (xemacs)Coding Systems

  3. I know utf-16-le-bom is a UCS, but latin-unity won't use it.  Why
     not?

     There are an awful lot of UCSes in Mule, and you probably do not
     want to ever use, and definitely not be asked about, most of them.
     So the default set includes a few that the author thought
     plausible, but they're surely not comprehensive or optimal.

     Customize `latin-unity-ucs-list' to include the ones you use, and
     report your favorites to the maintainer for consideration for
     inclusion in the defaults, *Note Bug Reports::.  (Note that you
     _must_ include `escape-quoted' in this list, because Mule uses it
     internally as the coding system for auto-save files.)

     Alternatively, if you just want to use it this one time, simply
     type it in at the prompt.  latin-unity will confirm that is a real
     coding system, and then assume that you know what you're doing.

  4. This is crazy: I can't quit XEmacs and get queried on autosaves!
     Why?

     You probably removed `escape-quoted' from `latin-unity-ucs-list'.
     Put it back.

  5. latin-unity is really buggy and I can't get any work done.

     First, use `M-x latin-unity-uninstall RET', then report your
     problems as a bug (*note Bug Reports::).


File: latin-unity.info,  Node: Theory of Operation,  Next: What latin-unity Cannot Do for You,  Prev: Frequently Asked Questions,  Up: Top

Theory of Operation
*******************

Standard encodings suffer from the design defect that they do not
provide a reliable way to recognize which coded character sets in use.
*Note What latin-unity Cannot Do for You::.  There are scores of
character sets which can be represented by a single octet (8-bit byte),
whose union contains many hundreds of characters.  Obviously this
results in great confusion, since you can't tell the players without a
scorecard, and there is no scorecard.

   There are two ways to solve this problem.  The first is to create a
universal coded character set.  This is the concept behind Unicode.
However, there have been satisfactory (nearly) universal character sets
for several decades, but even today many Westerners resist using Unicode
because they consider its space requirements excessive.  On the other
hand, Asians dislike Unicode because they consider it to be incomplete.
(This is partly, but not entirely, political.)

   In any case, Unicode only solves the internal representation problem.
Many data sets will contain files in "legacy" encodings, and Unicode
does not help distinguish among them.

   The second approach is to embed information about the encodings used
in a document in its text.  This approach is taken by the ISO 2022
standard.  This would solve the problem completely from the users' of
view, except that ISO 2022 is basically not implemented at all, in the
sense that few applications or systems implement more than a small
subset of ISO 2022 functionality.  This is due to the fact that
mono-literate users object to the presence of escape sequences in their
texts (which they, with some justification, consider data corruption).
Programmers are more than willing to cater to these users, since
implementing ISO 2022 is a painstaking task.

   In fact, Emacs/Mule adopts both of these approaches.  Internally it
uses a universal character set, "Mule code".  Externally it uses ISO
2022 techniques both to save files in forms robust to encoding issues,
and as hints when attempting to "guess" an unknown encoding.  However,
Mule suffers from a design defect, namely it embeds the character set
information that ISO 2022 attaches to runs of characters by introducing
them with a control sequence in each character.  That causes Mule to
consider the ISO Latin character sets to be disjoint.  This manifests
itself when a user enters characters using input methods associated with
different coded character sets into a single buffer.

   There are two problems stemming from this design.  First, Mule
represents the same character in different ways.  Abstractly,
',As(B' (LATIN SMALL LETTER O WITH ACUTE) can get represented as
[latin-iso8859-1 #x73] or as [latin-iso8859-2 #x73].  So what looks like
',Ass(B' in the display might actually be represented
[latin-iso8859-1 #x73][latin-iso8859-2 #x73] in the buffer, and saved
as [#xF3 ESC - B #xF3 ESC - A] in the file.  In some cases this
treatment would be appropriate (consider HYPHEN, MINUS SIGN, EN DASH,
EM DASH, and U+4E00 (the CJK ideographic character meaning "one")), and
although arguably incorrect it is convenient when mixing the CJK
scripts.  But in the case of the Latin scripts this is wrong.

   Worse yet, it is very likely to occur when mixing "different"
encodings (such as ISO 8859/1 and ISO 8859/15) that differ only in a
few code points that are almost never used.  A very important example
involves email.  Many sites, especially in the U.S., default to use of
the ISO 8859/1 coded character set (also called "Latin 1," though these
are somewhat different concepts).  However, ISO 8859/1 provides a
generic CURRENCY SIGN character.  Now that the Euro has become the
official currency of most countries in Europe, this is unsatisfactory
(and in practice, useless).  So Europeans generally use ISO 8859/15,
which is nearly identical to ISO 8859/1 for most languages, except that
it substitutes EURO SIGN for CURRENCY SIGN.

   Suppose a European user yanks text from a post encoded in ISO 8859/1
into a message composition buffer, and enters some text including the
Euro sign.  Then Mule will consider the buffer to contain both ISO
8859/1 and ISO 8859/15 text, and MUAs such as Gnus will (if naively
programmed) send the message as a multipart mixed MIME body!

   This is clearly stupid.  What is not as obvious is that, just as any
European can include American English in their text because ASCII is a
subset of ISO 8859/15, most European languages which use Latin
characters (eg, German and Polish) can typically be mixed while using
only one Latin coded character set (in the case of German and Polish,
ISO 8859/2).  However, this often depends on exactly what text is to be
encoded (even for the same pair of languages).

   latin-unity works around the problem by converting as many
characters as possible to use a single Latin coded character set before
saving the buffer.

   Because the problem is rarely noticable in editing a buffer, but
tends to manifest when that buffer is exported to a file or process, the
latin-unity package uses the strategy of examining the buffer prior to
export.  If use of multiple Latin coded character sets is detected,
latin-unity attempts to unify them by finding a single coded character
set which contains all of the Latin characters in the buffer.

   The primary purpose of latin-unity is to fix the problem by giving
the user the choice to change the representation of all characters to
one character set and give sensible recommendations based on context.
In the ',As(B' example, either ISO 8859/1 or ISO 8859/2 is
satisfactory, and both will be suggested.  In the EURO SIGN example,
only ISO 8859/15 makes sense, and that is what will be recommended.  In
both cases, the user will be reminded that there are universal
encodings available.

   I call this "remapping" (from the universal character set to a
particular ISO 8859 coded character set).  It is mere accident that this
letter has the same code point in both character sets.  (Not entirely,
but there are many examples of Latin characters that have different code
points in different Latin-X sets.)

   Note that, in the ',As(B' example, that treating the buffer in
this way will result in a representation such as [latin-iso8859-2
#x73][latin-iso8859-2 #x73], and the file will be saved as [#xF3 #xF3].
This is guaranteed to occasionally result in the second problem you
observed, to which we now turn.

   This problem is that, although the file is intended to be an
ISO-8859/2-encoded file, in an ISO 8859/1 locale Mule (and every POSIX
compliant program--this is required by the standard, obvious if you
think a bit, *note What latin-unity Cannot Do for You::) will read that
file as [latin-iso8859-1 #x73] [latin-iso8859-1 #x73].  Of course this
is no problem if all of the characters in the file are contained in ISO
8859/1, but suppose there are some which are not, but are contained in
the (intended) ISO 8859/2.

   You now want to fix this, but not by finding the same character in
another set.  Instead, you want to simply change the character set that
Mule associates with that buffer position without changing the code.
(This is conceptually somewhat distinct from the first problem, and
logically ought to be handled in the code that defines coding systems.
However, latin-unity is not an unreasonable place for it.)  latin-unity
provides two functions (one fast and dangerous, the other slow and
careful) to handle this.  I call this "recoding", because the
transformation actually involves _encoding_ the buffer to file
representation, then _decoding_ it to buffer representation (in a
different character set).  This cannot be done automatically because
Mule can have no idea what the correct encoding is--after all, it
already gave you its best guess.  *Note What latin-unity Cannot Do for
You::.  So these functions must be invoked by the user.  *Note
Interactive Usage::.


File: latin-unity.info,  Node: What latin-unity Cannot Do for You,  Next: Interfaces,  Prev: Theory of Operation,  Up: Top

What latin-unity Cannot Do for You
**********************************

latin-unity *cannot* save you if you insist on exporting data in 8-bit
encodings in a multilingual environment.  _You will eventually corrupt
data if you do this._  It is not Mule's, or any application's, fault.
You will have only yourself to blame; consider yourself warned.  (It is
true that Mule has bugs, which make Mule somewhat more dangerous and
inconvenient than some naive applications.  We're working to address
those, but no application can remedy the inherent defect of 8-bit
encodings.)

   Use standard universal encodings, preferably Unicode (UTF-8) unless
applicable standards indicate otherwise.  The most important such case
is Internet messages, where MIME should be used, whether or not the
subordinate encoding is a universal encoding.  (Note that since one of
the important provisions of MIME is the `Content-Type' header, which
has the charset parameter, MIME is to be considered a universal
encoding for the purposes of this manual.  Of course, technically
speaking it's neither a coded character set nor a coding extension
technique compliant with ISO 2022.)

   As mentioned earlier, the problem is that standard encodings suffer
from the design defect that they do not provide a reliable way to
recognize which coded character sets are in use.  There are scores of
character sets which can be represented by a single octet (8-bit byte),
whose union contains many hundreds of characters.  Thus any 8-bit coded
character set must contain characters that share code points used for
different characters in other coded character sets.

   This means that a given file's intended encoding cannot be identified
with 100% reliability unless it contains encoding markers such as those
provided by MIME or ISO 2022.

   latin-unity actually makes it more likely that you will have
problems of this kind.  Traditionally Mule has been "helpful" by simply
using an ISO 2022 universal coding system when the current buffer
coding system cannot handle all the characters in the buffer.  This has
the effect that, because the file contains control sequences, it is not
recognized as being in the locale's normal 8-bit encoding.  It may be
annoying if you are not a Mule expert, but your data is automatically
recoverable with a tool you already have: Mule.

   However, with latin-unity, Mule converts to a single 8-bit character
set when possible.  But typically this will _not_ be in your usual
locale.  Ie, the times that an ISO 8859/1 user will need latin-unity is
when there are ISO 8859/2 characters in the buffer.  But then most
likely the file will be saved in a pure 8-bit encoding that is not ISO
8859/1, ie, ISO 8859/2.  Mule's autorecognizer (which is probably the
most sophisticated yet available) cannot tell the difference between ISO
8859/1 and ISO 8859/2, and in a Western European locale will choose the
former even though the latter was intended.  Even the extension
("statistical recognition") planned for XEmacs 22 is unlikely to be at
all accurate in the case of mixed codes.

   So now consider adding some additional ISO 8859/1 text to the buffer.
If it includes any ISO 8859/1 codes that are used by different
characters in ISO 8859/2, you now have a file that cannot be
mechanically disentangled.  You need a human being who can recognize
that _this is German and Swedish_ and stays in Latin-1, while _that is
Polish_ and needs to be recoded to Latin-2.

   Moral: switch to a universal coded character set, preferably Unicode
using the UTF-8 transformation format.  If you really need the space,
compress your files.


File: latin-unity.info,  Node: Interfaces,  Next: Charsets and Coding Systems,  Prev: What latin-unity Cannot Do for You,  Up: Top

Interfaces
**********

The Latin-9 language environment is provided in
`latin-unity-latin9.el'.  This file when compiled contains Latin 9
characters, so you *must* load `latin-unity-vars.el' first to define
those characters.  Otherwise the Lisp reader is likely to signal an
error due to stray ISO 2022 control sequences.

   Similar considerations apply to `latin-unity-latin7.el',
`latin-unity-latin8.el' and `latin-unity-latin10.el'.

   Sorry, that's all I have to say for now--but it's important!


File: latin-unity.info,  Node: Charsets and Coding Systems,  Next: Internals,  Prev: Interfaces,  Up: Top

Charsets and Coding Systems
***************************

This section provides reference lists of Mule charsets and coding
systems.  Mule charsets are typically named by character set and
standard.

*ASCII variants*
     Identification of equivalent characters in these sets is not
     properly implemented.  latin-unity does not distinguish the two
     charsets.

     `ascii' `latin-jisx0201'

*Extended Latin*
     Characters from the following ISO 2022 conformant charsets are
     identified with equivalents in other charsets in the group by
     latin-unity.

     `latin-iso8859-1' `latin-iso8859-15' `latin-iso8859-2'
     `latin-iso8859-3' `latin-iso8859-4' `latin-iso8859-9'
     `latin-iso8859-13' `latin-iso8859-16'

     The follow charsets are Latin variants which are not understood by
     latin-unity.  In addition, many of the Asian language standards
     provide ASCII, at least, and sometimes other Latin characters.
     None of these are identified with their ISO 8859 equivalents.

     `vietnamese-viscii-lower' `vietnamese-viscii-upper'

*Other character sets*
     `arabic-1-column' `arabic-2-column' `arabic-digit'
     `arabic-iso8859-6' `chinese-big5-1' `chinese-big5-2'
     `chinese-cns11643-1' `chinese-cns11643-2' `chinese-cns11643-3'
     `chinese-cns11643-4' `chinese-cns11643-5' `chinese-cns11643-6'
     `chinese-cns11643-7' `chinese-gb2312' `chinese-isoir165'
     `cyrillic-iso8859-5' `ethiopic' `greek-iso8859-7'
     `hebrew-iso8859-8' `ipa' `japanese-jisx0208'
     `japanese-jisx0208-1978' `japanese-jisx0212' `katakana-jisx0201'
     `korean-ksc5601' `sisheng' `thai-tis620' `thai-xtis'

*Non-graphic charsets*
     `control-1'

*No conversion*
     Some of these coding systems may specify EOL conventions.  Note
     that `iso-8859-1' is a no-conversion coding system, not an ISO 2022
     coding system.  Although latin-unity attempts to compensate for
     this, it is possible that the `iso-8859-1' coding system will
     behave differently from other ISO 8859 coding systems.

     `binary' `no-conversion' `raw-text' `iso-8859-1'

*Latin coding systems*
     These coding systems are all single-byte, 8-bit ISO 2022 coding
     systems, combining ASCII in the GL register (bytes with high-bit
     clear) and an extended Latin character set in the GR register
     (bytes with high-bit set).

     `iso-8859-15' `iso-8859-2' `iso-8859-3' `iso-8859-4' `iso-8859-9'
     `iso-8859-13' `iso-8859-14' `iso-8859-16'

     These coding systems are single-byte, 8-bit coding systems that do
     not conform to international standards.  They should be avoided in
     all potentially multilingual contexts, including any text
     distributed over the Internet and World Wide Web.

     `windows-1251'

*Multilingual coding systems*
     The following ISO-2022-based coding systems are useful for
     multilingual text.

     `ctext' `iso-2022-lock' `iso-2022-7' `iso-2022-7bit'
     `iso-2022-7bit-ss2' `iso-2022-8' `iso-2022-8bit-ss2'

     XEmacs also supports Unicode with the Mule-UCS package.  These are
     the preferred coding systems for multilingual use.  (There is a
     possible exception for texts that mix several Asian ideographic
     character sets.)

     `utf-16-be' `utf-16-be-no-signature' `utf-16-le'
     `utf-16-le-no-signature' `utf-7' `utf-7-safe' `utf-8' `utf-8-ws'

     Development versions of XEmacs (the 21.5 series) support Unicode
     internally, with (at least) the following coding systems
     implemented:

     `utf-16-be' `utf-16-be-bom' `utf-16-le' `utf-16-le-bom' `utf-8'
     `utf-8-bom'

*Asian ideographic languages*
     The following coding systems are based on ISO 2022, and are more
     or less suitable for encoding multilingual texts.  They all can
     represent ASCII at least, and sometimes several other foreign
     character sets, without resort to arbitrary ISO 2022 designations.
     However, these subsets are not identified with the corresponding
     national standards in XEmacs Mule.

     `chinese-euc' `cn-big5' `cn-gb-2312' `gb2312' `hz' `hz-gb-2312'
     `old-jis' `japanese-euc' `junet' `euc-japan' `euc-jp' `iso-2022-jp'
     `iso-2022-jp-1978-irv' `iso-2022-jp-2' `euc-kr' `korean-euc'
     `iso-2022-kr' `iso-2022-int-1'

     The following coding systems cannot be used for general
     multilingual text and do not cooperate well with other coding
     systems.

     `big5' `shift_jis'

*Other languages*
     The following coding systems are based on ISO 2022.  Though none
     of them provides any Latin characters beyond ASCII, XEmacs Mule
     allows (and up to 21.4 defaults to) use of ISO 2022 control
     sequences to designate other character sets for inclusion the text.

     `iso-8859-5' `iso-8859-7' `iso-8859-8' `ctext-hebrew'

     The following are character sets that do not conform to ISO 2022
     and thus cannot be safely used in a multilingual context.

     `alternativnyj' `koi8-r' `tis-620' `viqr' `viscii' `vscii'

*Special coding systems*
     Mule uses the following coding systems for special purposes.

     `automatic-conversion' `undecided' `escape-quoted'

     `escape-quoted' is especially important, as it is used internally
     as the coding system for autosaved data.

     The following coding systems are aliases for others, and are used
     for communication with the host operating system.

     `file-name' `keyboard' `terminal'


   Mule detection of coding systems is actually limited to detection of
classes of coding systems called "coding categories".  These coding
categories are identified by the ISO 2022 control sequences they use, if
any, by their conformance to ISO 2022 restrictions on code points that
may be used, and by characteristic patterns of use of 8-bit code points.

   `no-conversion' `utf-8' `ucs-4' `iso-7' `iso-lock-shift' `iso-8-1'
`iso-8-2' `iso-8-designate' `shift-jis' `big5'


File: latin-unity.info,  Node: Internals,  Prev: Charsets and Coding Systems,  Up: Top

Internals
*********

No internals documentation yet.

   `latin-unity-utils.el' provides one utility function.

 - Function: latin-unity-dump-tables
     Dump the temporary table created by loading `latin-unity-utils.el'
     to `latin-unity-tables.el'.  Loading the latter file initializes
     `latin-unity-equivalences'.



Tag Table:
Node: Top1252
Node: Copying2965
Node: Overview3845
Node: Usage5692
Node: Basic Functionality7409
Node: Interactive Usage12617
Node: Installation21212
Node: Configuration21895
Node: Bug Reports23323
Node: Frequently Asked Questions23708
Node: Theory of Operation25593
Node: What latin-unity Cannot Do for You33684
Node: Interfaces37438
Node: Charsets and Coding Systems38075
Node: Internals44066

End Tag Table
