[Linux-bruxelles] Caractères spéciaux - autre histoire

[Alain Barthélemy]

Le mercredi 03 janvier 2007, 17:51:55 ou environ Yannick Warnier <ywarnier at beeznest.org> a écrit:
> Le mercredi 03 janvier 2007 à 15:22 +0100, Alain Barthélemy a écrit :
> > Le mercredi 03 janvier 2007, 10:16:10 ou environ Frederic Peters <fpeters at entrouvert.com> a écrit:
> > > Alain Barthélemy écrivait :
> > > 
> > > > Voir fichier ci-joint (verbes_liste.txt)
> > > 
> > > Il est attaché encodé en iso-8859-15, ce qui n'est probablement pas
> > > son encodage de départ.
> > 
> > Tiens, XEmacs lit les caractères japonais en format iso-8859-15? Je
> > viens de tester. 
> 
> Je sais pas mais en tout cas le seul encodage dans lequel j'arrive à
> voir les caractères japonais, c'est le ISO-2022-JP (dans Evolution en
> changeant l'encodage de l'e-mail complet).

Ici, il s'agit du codage emacs-mule. Cela fonctionne au poil mais il
s'agit d'un "codage interne" d'Emacs.


Le système de codage emacs-mule veut dire que le fichier contient des
caractères non ASCII stockés avec l'encodage interne d'Emacs. Il utilise
la conversion de fin-de-ligne selon les données rencontrées, et a les
trois variantes habituelles pour spécifier le type de conversion de
fin-de-ligne.

> 
> Par ailleurs, je répète qu'UIM fonctionne très bien pour encoder des
> caractères Japonais, et que Evolution (notamment) permet de choisir,
> lors de l'écriture d'un e-mail, l'encodage de caractères à utiliser (ce
> qui est pratique surtout quand certains japonais n'utilisent pas UTF-8
> mais Shift-JIS par exemple).

J'ai installé tous les paquets UIM que je pouvais trouver avec apt-cache
search. En dehors d'Evolution comment cela marche? Emacs utilise le
système d'encodage 'anthy'. Si tu tapes kedit ou gedit + anthy dans
Google, tu as des tas de leins japonais. Apparemment, ils connaissent
mais je n'en suis pas encore à lire une page d'explication en japonais.

> 
> Enfin bref, c'est quoi le problème donc? D'imprimer à partir de XEmacs?
> Moi je vois que ton fichier attaché est en ISO-2022-JP, donc peut-être
> qu'il faut que CUPS comprenne cet encodage-là? Quoi qu'il en soit, je ne
> vois pas trop pourquoi utiliser XEmacs si tu passes quand même par OOo
> au final :-)

Le fichier attaché, selon toi est en ISO-2022-JP. Peux-tu lire les
caractères japonais?

> 
> Yannick
> 
> 

Le problème est bête. Je voudrais travailler avec Debian pour diverses
raisons. Mais il y a incommunication totale entre les applications Emacs
et OpenOffice installées avec les paquets Debian. Ou plutôt, les jeux de
caractères Emacs sont tout à fait hermétiques.
Impossible d'imprimer les caractères japonais à partir d'une
applications sur Debian (serveur Cups sur station SuSE-10.1 car la seule
à avoir le pilote correct pour Laserjet4).

Par contre avec XEmacs et OpenOffice installés avec Yast de SuSE-10.1,
Open-Office n'ouvre toujours pas correctement un fichier (celui que j'ai
envoyé à la liste par exemple), par contre j'arrive à faire un
copier/coller de XEmacs à Open-Office. Là je sauvegarde en format .swx
et je peux alors imprimer (avec le même serveur Cups qui comprend alors
le japonais mais pas version XEmacs).

C'est long et compliqué car je ne peux pas encoder les caractères
japonais avec Open-Office. Juste un copier/coller à partir de XEmacs qui
est l'éditeur de base que ce soit sur Debian ou sur SuSE.

Il y a donc une étape bizarre. Open-Office reconvertit le jeu de
caractères Emacs japonais hermétique, uniquement sur SuSE et avec un
copier/coller, dans un jeu de caractère universel, ISO-2022-JP d'après
toi.


-- 
Alain Barthélemy
cassandre at bartydeux.be
http://www.bartydeux.be