Re: MML charset tag regression

[Dave Love]

Kenichi Handa <address@hidden> writes:

> But, ctext itself doesn't have to support it, i.e., decode it as the
> sender's intention.

But then you might as well ignore extended segments entirely, and I
assume it must decode it if the name for the segment is registered.
However, the CTEXT spec says that you must use extended segments
for private charsets.

> It's impossible to know about all possible
> encoding names that will be used in the extended segment.

Sure.  I was holding off changes in this area until I convinced myself
what is the best way to do the heuristic conversion between external
charset names and Emacs names.  (Sorry, I could have saved you the
work.)  At least you have a chance of interpreting the names, but you
can't know anything about private charset definitions, even if they
were allowed.  Extended segment names are supposed to be registered
and follow font encoding names, of course.

> Surely it's not.  ctext and compound-text-with-extensions
> encode text differently.  But, I don't think
> compound-text-with-extensions implies an extended version of
> ctext.

It does to me, and that was clearly intended.  It has been changed
recently, but in my Emacs it says:

x -- compound-text-with-extensions (alias: x-ctext-with-extensions 
ctext-with-extensions)
  Compound text encoding with ICCCM Extended Segment extensions.

and the NEWS entry says only some versions of X use extended segments.

Giving the impression of not following the CTEXT spec can't help with
trying to persuade someone else to fix their problems, as I hope you
can do.

Anyhow the point is that whatever's called compound-text should deal
with extended segments.

> 2002-09-11  Dave Love  <address@hidden>
>
>       * international/mule.el (non-standard-designations-alist)
>       (ctext-pre-write-conversion): Don't generate invalid extended
>       segments for iso8859.
>
> I agree with this change.

[It was essential for people in Latin-9 locales not on recent
XFree86/Gtk systems.]

> If one really want to encode iso-8859-X by using an extended
> segment, he can modify non-standard-designations-alist

But that violates the specification in the same way that xfree86 (or
gtk or whatever it is) does.