PDF-Writer

Community FR
21

Bon j’ai découvert un drôle de truc, sur une appli rails toute simple
sans avoir rien configuré du côté charset, un “é” est entré dans mon
mysql comme un “Ã?©”.
Un pdf généré par pdf::writer me recopie texto ce caractère étrange
alors que mon appli sait me le transformer en “é” dans les vues.
J’ai tenté via phpmyadmin de remplacer le “Ã?©” par un “é”. Désormais mon
appli rails m’affiche un point d’interrogation à la place de l’accent
mais le pdf::writer me sort un accent.

Je deviens fou, mon appli rails entièrement utf-8 (qui écrit donc les
“é” comme des “é” dans ma base) est, elle, incapable de générer un pdf
correct !

22

Thibaut Barrère wrote:

Bon j’ai découvert un drôle de truc, sur une appli rails toute simple
sans avoir rien configuré du côté charset, un “é” est entré dans mon
mysql comme un “Ã?©”.

tu as passé l’option ‘DEFAULT CHARSET=utf8’ au create_table ?

Non je l’avais pas fait mais du coup je l’ai intégré à mes scripts de
migration mais je suis pas certain que ça soit pris en compte vu que
phpmyadmin me l’indique comme étant en latin_swedish…

def self.up
create_table :items do |t|
# t.column :name, :string

      t.column "id", :integer
       (...)
      t.column "created_on", :datetime
      t.column "updated_on", :datetime,
      "DEFAULT CHARSET=UTF-8"
end

end

def self.down
drop_table :items
end
end

23

Ben :

tu as passé l’option ‘DEFAULT CHARSET=utf8’ au create_table ?

Non je l’avais pas fait mais du coup je l’ai intégré à mes scripts de
migration mais je suis pas certain que ça soit pris en compte

à vérifier dans les logs.

      "DEFAULT CHARSET=UTF-8"

ah, et ça marche ?

end

end

create_table :items, :options => “DEFAULT CHARSET=utf8” do |t|
t.column …
end

 -- Jean-François.
24

Bon j’ai découvert un drôle de truc, sur une appli rails toute simple
sans avoir rien configuré du côté charset, un “é” est entré dans mon
mysql comme un “Ã?©”.

tu as passé l’option ‘DEFAULT CHARSET=utf8’ au create_table ?

25

Jean-François wrote:

Ben :

tu as passé l’option ‘DEFAULT CHARSET=utf8’ au create_table ?

Non je l’avais pas fait mais du coup je l’ai intégré à mes scripts de
migration mais je suis pas certain que ça soit pris en compte

à vérifier dans les logs.

      "DEFAULT CHARSET=UTF-8"

ah, et ça marche ?

Non non ça marchais pas mais j’avais pas d’erreur.

create_table :items, :options => “DEFAULT CHARSET=utf8” do |t|
t.column …
end

Là ça marche toute la base est configurée utf8.

Pour que tout ça soit clair, j’ai une appli (un peu lourde) qui était en
utf8 en suivant les conseils du wiki officiel (et ça fonctionne
parfaitement). Sur cette dernière je n’arrive pas à sortir d’accents sur
PDF::Writer (cf les posts du haut).
Voyant que Mathieu arrive à produire des PDF accentués, j’ai décidé de
créer une appli rapide avec scaffolding pour mieux isoler mes pbs.

  1. Sans paramétrages du côté charset mes enregistrements sur une BDD
    Mysql 4.0 via scaffolding = de drôles de caractères.
  2. Même appli, même base mais modification de l’enregistrement par
    phpmyadmin, mon accent ressemble à un accent dans pdf::writer mais plus
    dans mon appli Rails (ce qui doit se régler via un header).
  3. J’aimerai en fait que via mon appli Rails mes enregistrements
    accentués correspondent à ceux faits via phpmyadmin. C’est là que je me
    dis qu’il faut tout passer en utf8.
  4. Je tente donc de passer sous mysql 5.0, j’ajoute “DEFAULT
    CHARSET=utf8” Ã mon script de migration mais impossible d’ajouter
    “encoding:utf8” dans database.yml car mon appli ne démarre plus…
  5. Sans ajouter “encoding:utf8” dans database.yml mes enregistrements ce
    font comme dans le cas 1.

C’est un peu long mais il doit y avoir un grain de sable quelque part !

Ben

26

Le 30 sept. 06, à 17:17, Ben B. a écrit :

Donc mon problème viendrait plus de webrick que de l’encodage de ma
base
? Tes applis rails qui génèrent du pdf ne tournent pas sous webrick ?

As-tu essayé d’utiliser iconv sur la sortie de ta base pour convertir
en iso9959-1 ou -15
avant de le passer au pdf ?

Jean-Christophe M.

Symétrie, édition de musique et services multimédia
30 rue Jean-Baptiste Say
69001 LYON (FRANCE)
tél +33 (0)478 29 52 14
fax +33 (0)478 30 01 11
web www.symetrie.com

27

±Le 30/09/2006 17:17 +0200, Ben B. a dit :
| Mathieu A. wrote:
|
|>
|> �a me para�t normal, en utf-8, le caract�re “�” est
|> repr�sent� par “é”, forc�ment tu ne vois que des “�” parce que
|> par d�faut, webrick met utf-8 comme charset.
|> Bien sur, si tu �cris “é” dans un pdf, �a va faire “é” et pas
|> “�”.
|
|
| Donc mon problème viendrait plus de webrick que de l’encodage de ma base
| ? Tes applis rails qui génèrent du pdf ne tournent pas sous webrick ?
|
| Merci de ta patience…

Mes applis qui génèrent du pdf ne tournent pas avec webrick, et elles ne
tournent pas en utf-8, mais en iso-8859-15 vu que je parle français.

28

Mathieu A. wrote:
…

Mes applis qui génèrent du pdf ne tournent pas avec webrick, et elles ne
tournent pas en utf-8, mais en iso-8859-15 vu que je parle français.

Pour de l’iso-8859-15, fais-tu un réglage particulier dans database.yml
?
J’ai essayé html entities pour ruby, j’obtiens de l’utf-8 que je passe
en iso via iconv mais ça donne toujours le même pdf tout moche.

@ Jean-Christophe M. :

As-tu essay� d’utiliser iconv sur la sortie de ta base pour convertir
en iso9959-1 ou -15
avant de le passer au pdf ?

Oui, j’arrête pas utf8 vers iso 15, iso 1 vers iso 15, utf8 ver cp1252
etc.

29

Ben B. wrote:

Oui, j’arrête pas utf8 vers iso 15, iso 1 vers iso 15, utf8 ver cp1252
etc.

J’ai réglé mon problème !

Mauvaise utilisation de iconv la syntaxe est :
Iconv.new(to, from).iconv(text) or je faisais l’inverse Iconv.new(from,
to).iconv(text)

:slight_smile: