Source

latin-unity / latin-unity.texi

Full commit
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
\input texinfo   @c -*-texinfo-*-

@c Manual for the XEmacs latin-unity package.

@c ** #### something uses these headers, find out how and explain here
@c %**start of header
@setfilename latin-unity.info
@settitle Equivalencing Coded Latin Characters
@setchapternewpage odd
@c %**end of header

@c Version values, for easy modification
@set VERSION 0.8
@set UPDATED Sunday 24 February 2002

@c ** Many people seem to prefer this footenote style
@footnotestyle end

@direntry
* latin-unity::                Remap Latin characters from a single charset.
@end direntry

@c ** It is often convenient to use a macro for names which have unusual
@c ** spelling or formatting conventions.
@c Macro to make formatting of the package name consistent.
@macro pkgname
@i{latin-unity}
@end macro

@c Copying permissions, et al
@c Note that this whole section is repeated twice, once for the Info
@c version and once for TeX.  ####  How about HTML, etc?
@ifinfo
This file is part of XEmacs.  It documents the @pkgname{} package,
which ensures that wherever possible representations of all Latin
characters are drawn from the same 8-bit character set.
     
Copyright @copyright{} 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.
     
@ignore 
Permission is granted to process this file through TeX and print the
results, provided the printed document carries a copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).
   
@end ignore
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.
@end ifinfo

@tex

@titlepage
@title Latin Unity for Emacsen
@subtitle Last updated @value{UPDATED}

@author Stephen J. Turnbull
@page

This manual is part of XEmacs.  It documents the @pkgname{} package,
which ensures that wherever possible representations of all Latin
characters are drawn from the same 8-bit character set.
     
Copyright @copyright{} 2002 Free Software Foundation, Inc.
     
@vskip 0pt plus 1filll
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.

@end titlepage
@page

@end tex

@ifnottex
@node Top, Copying, (dir), (dir)
@top Latin Unity for Emacsen

@html
This project kindly hosted by
<br />
<a href="http://sunsite.dk">
<img src="http://sunsite.dk/images/hostedby.png"
     border="0" alt="sunSITE.dk Logo" /></a>
<a href="http://www.tux.org/">
<img src="http://www.tux.org/images/minibanner.gif"
     width="88" height="31" border="0" alt="Tux.Org Logo" /></a>
<a href="http://sourceforge.net">
<img src="http://sourceforge.net/sflogo.php?group_id=34545"
     width="88" height="31" border="0" alt="SourceForge Logo" /></a>
@end html

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.  @pkgname{} 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 @value{VERSION} of the @pkgname{} manual, last updated on
@value{UPDATED}.

@c ** Currently we provide documentation for the XEmacs core, but not for
@c ** individual packages, on the web.  Check for latest policy either at
@c ** www.xemacs.org or on xemacs-beta@xemacs.org.

@c You can find the latest version of this document on the web at
@c @uref{http://www.xemacs.org/}.

@ifhtml
@c ** Mention translations and other online versions here.

@c ** Adjust to taste.  You may wish to mention newgroups such as
@c ** comp.emacs.xemacs, comp.emacs, and gnu.emacs.help.
Discussion and enhancement of @pkgname{} is conducted on the XEmacs
mailing lists, especially the XEmacs Beta list.  See
@uref{http://www.xemacs.org/Lists/} for more information about the
XEmacs mailing lists.
@end ifhtml

@end ifnottex

@menu
* Copying::                     @pkgname{} copying conditions.
* Overview::                    @pkgname{} history and general information.

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

@c For programmers:
@c * Interfaces::                  Calling @pkgname{} from Lisp code.

@c For maintainers:
@c * Internals::                   Implementation details.

@c ** For small packages, with no or few subnodes, a detailmenu is not
@c ** necessary.
@c @detailmenu
@c  --- The Detailed Node Listing ---

@c @end detailmenu
@end menu

@node Copying, Overview, Top, Top
@chapter @pkgname{} Copying Conditions

@c ** CHECK THE COPYRIGHT DATE(S) AND HOLDER(S)!

Copyright (C) 2002 Free Software Foundation, Inc.

@pkgname{} 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.

@pkgname{} 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.


@node Overview, Usage, Copying, Top
@chapter An Overview of @pkgname{}

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.

@pkgname{} works around the problem by converting as many characters as
possible to use a single Latin coded character set before saving the
buffer.

@node Usage, Installation, Overview, Top
@chapter Operation of @pkgname{}

Normally, @pkgname{} works in the background by installing
@code{latin-unity-sanity-check} on @code{write-region-pre-hook}.  The
user activates this functionality by invoking
@code{latin-unity-install}, either interactively or in her init file.
@xref{Init File, , , xemacs}.  @pkgname{} can be deactivated by
invoking @code{latin-unity-uninstall}.

@pkgname{} also provides a few functions for remapping or recoding the
buffer by hand.  To @dfn{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 @dfn{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.  @xref{Theory of Operation}.

There are a few variables which determine which coding systems are
always acceptable to @pkgname{}, @code{latin-unity-approved-ucs-list},
@code{latin-unity-ignored-coding-system-list}, and
@code{latin-unity-approved-coding-system-list}.  The latter two default
to @code{()}, 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).
@end menu


@node Basic Functionality, Interactive Usage, , Usage
@section Basic Functionality

These functions and user options initialize and configure @pkgname{}.
In normal use, only a call to @code{latin-unity-install} is needed.


@defun 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.
@end defun


@defun latin-unity-uninstall

There are no arguments.

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


@defopt latin-unity-approved-ucs-list

The default value is @code{'(utf-8 iso-2022-7 ctext)}.

List of coding systems considered to be universal.

Order matters; coding systems earlier in the list will be preferred when
recommending a coding system.
@end defopt


Coding systems which are not Latin and not in
@code{latin-unity-approved-ucs-list} are handled by short circuiting
checks of coding system against the next two variables.  A preferable
approach is to define an alist of coding systems to corresponding sets
of ``safe'' character sets, then checking that @code{(charsets-in-region
begin end)} is contained in the appropriate set.  If you want this
@emph{now} do it yourself and send a patch to
@email{stephen@@xemacs.org}.


@defopt latin-unity-ignored-coding-system-list

The default value is nil.

List of coding systems such that the buffer is not checked for Latin unity.

Usually this means that the value of @code{buffer-file-coding-system} is
a member of this list.

This API is likely to change.
@end defopt


@defopt latin-unity-approved-coding-system-list

The default value is nil.

List of coding systems forcing a save of the buffer even if Latin unity
is not satisfied.

This API is likely to change.
@end defopt


@defopt latin-unity-iso-8859-1-aliases

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

List of coding systems to be treated as aliases of ISO 8859/1.
@end defopt


@node Interactive Usage, , Basic Functionality, Usage
@section Interactive Usage

First, the hook function @code{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).


@defun latin-unity-sanity-check begin end filename append visit lockname &optional coding-system

Check if @var{coding-system} can represent all characters between @var{begin} and @var{end}.

For compatibility with old broken versions of @code{write-region},
@var{coding-system} defaults to @code{buffer-file-coding-system}.  @var{filename},
@var{append}, @var{visit}, and @var{lockname} are ignored.

Return nil if buffer-file-coding-system is not (ISO-2022-compatible)
Latin.  If @code{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 @emph{not} do the safe thing when
@code{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 @code{write-region-pre-hook}.  It
does nothing except return @var{coding-system} if @code{write-region} handlers
are inhibited.
@end defun


@defun latin-unity-buffer-representations-feasible

There are no arguments.

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


@defun latin-unity-region-representations-feasible begin end &optional buf

Return character sets that can represent the text from @var{begin} to @var{end} in @var{buf}.

@var{buf} defaults to the current buffer.  Called interactively, will be
applied to the region.  Function assumes @var{begin} <= @var{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 @code{skip-category-forward}
over a precomputed category table it should be really fast.  In practice
for Latin character sets there are only 29 classes.
@end defun


@defun latin-unity-remap-region begin end character-set &optional coding-system

Remap characters between @var{begin} and @var{end} to equivalents in @var{character-set}.
Optional argument @var{coding-system} may be a coding system name (a symbol) or
nil.  Characters with no equivalent are left as-is.

When called interactively, @var{begin} and @var{end} are set to the beginning and
end, respectively, of the active region, and XEmacs prompts for
@var{character-set}.

Return @var{coding-system} if @var{coding-system} can encode all characters in the
region, t if @var{coding-system} is nil and the coding system with G0 = 'ascii
and G1 = @var{character-set} can encode all characters, and otherwise nil.  Note
that a non-null return does @emph{not} mean it is safe to write the file, only
the specified region.  (This behavior is useful for multipart MIME encoding
and the like.)

Interactively @var{begin} and @var{end} are set to the current region and the function
prompts for @var{character-set}.  There is no way to specify @var{coding-system}, as it
has no useful function interactively.

Note:  by default this function is quite fascist about universal coding
systems.  It only admits @samp{utf-8}, @samp{iso-2022-7}, and
@samp{ctext}.  Customize @code{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
@code{latin-unity-recode-region}.
@end defun


@defun latin-unity-recode-region begin end wrong-cs right-cs

Recode characters between @var{begin} and @var{end} from @var{wrong-cs} to @var{right-cs}.

When called interactively, @var{begin} and @var{end} are set to the beginning and
end, respectively, of the active region, and XEmacs prompts for @var{wrong-cs}
and @var{right-cs}.

@var{wrong-cs} and @var{right-cs} are character sets.  Characters retain
the same code point but the character set is changed.  Only characters
from @var{wrong-cs} are changed to @var{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.

Another way to accomplish this, but using coding systems rather than
character sets to specify the desired recoding, is
@samp{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 @samp{latin-unity-remap-region}.
@end defun


@defun latin-unity-recode-coding-region begin end wrong-cs right-cs

Recode text between @var{begin} and @var{end} from @var{wrong-cs} to @var{right-cs}.

When called interactively, @var{begin} and @var{end} are set to the beginning and
end, respectively, of the active region, and XEmacs prompts for @var{wrong-cs}
and @var{right-cs}.

@var{wrong-cs} and @var{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.

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 @code{latin-unity-remap-region}.
@end defun


@defun latin-unity-test

Really cheesy tests for @pkgname{}.

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.
@end defun


@node Installation, Configuration, Usage, Top
@chapter Installing @pkgname{} with your (X)Emacs

@pkgname{} may be installed from XEmacs via the package user interface
(accessible from the @samp{Tools} menu or via @kbd{M-x list-packages}).

You can also download the @file{latin-unity-@var{version}-pkg.tar.gz}
tarball from @url{ftp://ftp.xemacs.org/pub/xemacs/packages/}, and simply
unpack it in the usual place.

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


@node Configuration, Bug Reports, Installation, Top
@chapter Configuring @pkgname{} for Use

If you want @pkgname{} to be automatically initialized, invoke
@samp{latin-unity-install} with no arguments in your init file.
@xref{Init File, , , xemacs}.  If you are using GNU Emacs or an XEmacs
earlier than 21.1, you should also load @file{auto-autoloads} using the
full path (@emph{never} @samp{require} @file{auto-autoloads} libraries).


@node Bug Reports, Theory of Operation, Configuration, Top
@chapter Reporting Bugs and Problems

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

Suggestions for improvement are welcome at the same addresses.


@node Theory of Operation, What latin-unity Cannot Do for You, Bug Reports, Top
@chapter 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.
@xref{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, @dfn{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 this case, ISO 8859/2).  However,
this often depends on exactly what text is to be encoded.

@pkgname{} 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
@pkgname{} package uses the strategy of examining the buffer prior to
export.  If use of multiple Latin coded character sets is detected,
@pkgname{} 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 @pkgname{} 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 @dfn{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 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, @pxref{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, @pkgname{} is not an unreasonable place for it.)  @pkgname{}
provides two functions (one fast and dangerous, the other slow and
careful) to handle this.  I call this @dfn{recoding}, because the
transformation actually involves @emph{encoding} the buffer to file
representation, then @emph{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.  @xref{What latin-unity Cannot Do for
You}.  So these functions must be invoked by the user.  @xref{Interactive
Usage}.


@node What latin-unity Cannot Do for You, , Theory of Operation, Top
@chapter What latin-unity Cannot Do for You

@pkgname{} @strong{cannot} save you if you insist on exporting data in
8-bit encodings in a multilingual environment.  @emph{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 @samp{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.

@pkgname{} 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 @pkgname{}, Mule converts to a single 8-bit character set
when possible.  But typically this will @emph{not} be in your usual
locale.  Ie, the times that an ISO 8859/1 user will need @pkgname{} 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.  But 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 @emph{this is German and Swedish} and stays in Latin-1, while
@emph{that is Polish} and needs to be recoded to Latin-2.

@c end of latin-unity.texi