iconv is a tool dedicated to character sets conversion.

Install iconv :

root@localhost:~# apt-get install iconv

To see all the character sets available with iconv :

fool@localhost:~$ iconv –list

To convert a file encoded in iso-8859-15 into utf-8, here is the complete command to run :

fool@localhost:~$ iconv -f iso-8859-15 -t utf-8 file_to_convert

By default, the result is displayed on the standard output.

You can redirect it :

fool@localhost:~$ iconv -f iso-8859-15 -t utf-8 file_to_convert > file_newly_converted

הלוח, שבדיוק כתבתי, מתבסס על libhdate.

כמיטב המסורת, libhdate תומך ב NLS, קרי – Native Language Support. או בתרגום חופשי – “תמיכה בשפת המשתמש”. זה אומר שמשתמש שהלוקאל שלו אנגלי ירצה מן הסתם לקבל מ libhdate ערך אנגלי, ולהפך, משתמש עם לוקאל עברי ירצה פלט בעברית.

התרגום נעשה בעזרת קריאה ל- gettext, ונשמר כקבצים נפרדים, בלתי תלויים בתוכנה (כך שניתן להתקין ולמחוק תרגומים בנפרד ממנה, למשל).

כמובן שאפשר לקבוע גם לוקאל לתוכנה ספציפית, ולהכריח רק אותה להיות בשפה מסויימת. למשל, אצלי כל המחשב באנגלית, אך אני אוהב כש- libhdate נותן תוצאות בעברית, כמובן.
אז איך דואגים לכך? קובעים לוקאל מקומית:

hdmoshe@debian:~$ hdate
Tuesday, 13 October 2009, 25 Tishrei 5770
moshe@debian:~$ LC_ALL=he_IL hdate
שלישי, 13 אוקטובר 2009, כ"ה תשרי התש"ע

כך עשיתי גם בלוח שלי למשל, אלא ששיניתי את הלוקאל מתוך הקוד עצמו, ולא הותרתי למשתמש בחירה בעניין.

כל זה טוב ויפה על מערכות נורמליות, לינוקס למשל.
אך מה לגבי חלונות?
זה אמנם אפשרי, אך לא תמיד כזה פשוט. בעזרתו האדיבה של ארתיום הצלחתי בסופו של דבר, ובלחץ של אחרים אני מפרסם כאן איך עשיתי את זה. אני לא מתחייב שזו הדרך המושלמת, אבל אצלי לפחות היא עבדה.

אני מפרסם פה את הקווים הכללים. בהחלט נדרש כאן ידע קודם של התקנת תוכנות, קימפול תוכנות, והבנה של מי נגד מי בלינוקס. אל תצפו לצעד-צעד.

קודם כל נחלק את הבעייה לשתיים -
א) צריך לגרום ל gettext לעבוד על חלונות, בשביל התרגום בפועל, ולמקם את קבצי התרגום של libhdate במקום הנכון.
ב) צריך לקמפל את libhdate עם תמיכה ב NLS, ולשם כך צריך את ספריות הפיתוח שקשורות ב gettext, מקומפלות לחלונות.

א’ לא מסובך. מתקינים gettext for windows, ושלום על ישראל. את החלק השני שלו נעשה אחרי ב’.

איך עושים את ב’?

בשלב הראשון צריך לארגן cross compiler של mingw ללינוקס, ולוודא שהוא עובד. התקנה שלו ממנהל החבילות אמורה להספיק.
כדאי ליצור לו תוכנית הדגמה קטנה (שלום עולם יספיק), לקמפל איתו, ולראות שנוצר קובץ .exe. הקובץ הזה צריך לעבוד על wine וחלונות, אך לא על לינוקס. מצויין, אפשר להמשיך.

עכשיו, אנחנו יכולים לקמפל גם תוכנות מורכבות יותר לחלונות, בעזרת הרצת

./configure --host=i586-mingw32msvc --prefix=/path/for/win/version

מה שיצור לנו makefile שמותאם ל mingw. אם הכל תקין – make עכשיו יבנה את התוכנה, או הספרייה, לחלונות.

דא עקא, שאם ננסה לעשות את אותו דבר עכשיו עם libhdate, נקבל:

...
checking for iconv... no, consider installing GNU libiconv
checking for GNU gettext in libintl... no
checking whether to use NLS... no

בגלל שחסר לנו, כפי שהזכרנו, את libiconv ו libintl.

כדי לטפל ב libiconv, הורדתי את קוד המקור שלו, קימפלתי לחלונות עם mingw, ודחפתי באיזה מקום. צריך להגיד ל configure איפה זה יוצא, אבל על זה בהמשך.

את קוד המקור של libintl לא מצאתי. אולי אם בונים את gettext לחלונות זה יכלול את זה, לא ניסיתי. התקנתי הרי את gettext לחלונות קודם, אז העתקתי את כל מה שהתקנתי, ודחפתי לתקייה כלשהי על הלינוקס.

הדגש הוא על הקבצים libintl.h, libintl.dll.a ו- libintl.lib .
צריך למקם אותם איפשהו, אני למשל מיקמתי אותם תחת:

עכשיו שיש לנו את gettext (עם libintl) ו libiconv , צריך רק ליידע את configure.
שיטוט באניטרנט העלה את האפשרות של שימוש ב env, ולכן הפקודה יצאה כך:

env CPPFLAGS="-I/usr/winlib/iconv/include -I/usr/winlib/libintl" LDFLAGS="-lintl -L/usr/winlib/iconv/lib -L/usr/winlib/linintl" ./configure --host=i586-mingw32msvc --prefix=/usr/winlib/libhdate

ואכן:

checking for GNU gettext in libc... no
checking for iconv... yes
checking for working iconv... guessing yes
checking how to link with libiconv... /usr/winlib/iconv/lib/libiconv.dll.a -L/usr/winlib/iconv/lib
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes

הידד!
אבל לפני שאנחנו רצים לבנות את libhdate, כדאי לתקן את המקום שבו הוא מחפש את המילון, כדי שיתאים גם לחלונות.
אם נפתח את קובץ ה makefile שבתקייה src ידנית, נגלה לחרדתנו את הקביעה:

... -DPACKAGE_LOCALE_DIR=\"/usr/winlib/libhdate/share/locale\"

זה אולי נתיב סביר ללינוקס, אבל אין לי מושג איפה הוא ייצא בחלונות.
כפיתרון, שיניתי ידנית את הערך ל:

-DPACKAGE_LOCALE_DIR=\".\"

זה אומר שהמילון יחופש במיקום של התוכנה, ובמקרה שלנו, תחת

he/LC_MESSAGES/libhdate.mo

מהתקייה שבה התוכנה שלנו.

זהו, עכשיו נבנה את libhdate, נתקין, ואת כל מה שיצא, נעתיק איפשהו לחלונות.

עכשיו צריך לעדכן את קובץ ה pro של Luach, כך שהקטע הבא יתאים למיקום של libhdate:

 win32 {
    LIBS += -lintl \
        -LC:\libhdate\lib
    INCLUDEPATH += C:\libhdate\include
}

כעת הקימפול צריך לעבוד עם libhdate שקומפל עם NLS, ובא לציון גואל (כמעט).

נותר לנו עדיין להעתיק את קובץ התרגום (libhdate.mo), אל התקייה he\LC_MESSAGES שממוקמת איפה שהבינארי שנוצר לנו נמצא.

זהו. אם הכל הלך כמו שצריך – התוכנה אמורה לקבל עברית כשהיא משתמשת ב libhdate. אם לא – באסה. נסו שוב.

בהצלחה,
משה

No necesitas instalar nada en tu ordenador. Solo tienes que subir el archivo que quieres convertir, elegir el formato en el que quiere convertir el archivo, dejar tu email y Cometdoc te envía el resultado en un segundín sin afectar al archivo original.

Lo bueno que tiene esta página es que puedes hacer hasta 50 conversiones distintas en el mismo sitio.

Esta es la lista de distintas conversiones:

Convert from PDF:
(some conversion support OCR conversion for scanned PDF)
PDF to Open Office Writer format
PDF to Open Office Calc format
PDF to Open Office Impress format
PDF to image BMP
PDF to image JPG
PDF to image GIF
PDF to image PNG
PDF to image TIF
PDF to text
PDF to HTML
PDF to MS Word
PDF to MS Excel
PDF to AutoCAD (dwg)
PDF to AutoCAD (dxf)

Convert to PDF:
Bmp to PDF
Word (doc, docx) to PDF
Gif to PDF
htm to PDF
html to PDF
jpeg to PDF
jpg to PDF
log to PDF
mht to PDF
mhtml to PDF
ODF to PDF
ODP to PDF
ODS to PDF
ODT to PDF
PNG to PDF
PPS to PDF
PPT to PDF
RTF to PDF
SDA to PDF
SDC to PDF
SDD to PDF
SDS to PDF
SDW to PDF
SXC to PDF
SXD to PDF
SXI to PDF
SXM to PDF
SXW to PDF
TIF to PDF
TIFF to PDF
TXT to PDF
WRI to PDF
Excel (xls, xlst) to PDF
Publisher (pub) to PDF

Convert from XPS:
Convert to Open Office Writer format
Convert to Open Office Calc format
Convert to Open Office Impress format
Convert to image BMP
Convert to image JPG
Convert to image GIF
Convert to image PNG
Convert to image TIF
Convert to text
Convert to HTML
Convert to MS Word
Convert to MS Exsel

Other File Conversions:
Excel to CSV (XLSTOCSV)
XML to LINT (XMLLINT)
HTML to RSS (HTMLTORSS)
ASC TO PDB
ASC TO EBC
UNIX TO DOS
DOS TO UNIX
MAC TO UNIX
FIX TO DELIM
DELIM TO FIX
CSV TO DELIM
SORT FILE
PDF INFO
COMPARE FILES
MP3 INFO
FILEINFO
ICONV

Não sei se o iconv está disponível em todas as distribuições, mas no Slackware tem.

$ iconv -f iso-8859-1 -t utf-8 arquivo_iso.txt > arquivo_utf.txt

Dentre as páginas que citam o comando, uma delas é esta – de onde busquei o exemplo.

Geralmente uma simples conversa de IRC gera um projeto. Desta vez foi o meu iconv_codecs, um módulo python para encodificação e decodificação usando os codecs definidos pelo GNU iconv. Leia aqui a conversa na íntegra:

<NandoFlorestan> socorro, o Python não tem uma encoding de que preciso. self._current_txt = pay.decode(charset, ‘ignore’)
<NandoFlorestan> LookupError: unknown encoding: ansi_x3.110-1983
<nosklo> NandoFlorestan, crie seu proprio encoding e registre-o
<NandoFlorestan> heheheheh. Talvez eu consiga usar o iconv
<vambboy nosklo, como criar um coding?
<vambboy> num sabia q era possível
<nosklo> vambboy, faca uma funcao pra encodificar, uma pra decodificar, uma classe que encodifique e decodifique incrementalmente, e subclasses para escrita e leitura de streams
<NandoFlorestan> vambboy, tá interessado? Quer fazer pra mim? Implementa aí o tal ansi_x3.110-1983…
<nosklo> vambboy, em seguida registre estas funcoes usando codecs.register()
<NandoFlorestan O nosklo é uma enciclopédia
<nosklo> eu ja fiz um encoding pra 13375p34k
<vambboy>  é o eu diga, ele nasceu com sangue de cobra
<vambboy> e cabra era o python
<vambboy> kkkkkk
<NandoFlorestan> “é o eu diga”?
<NandoFlorestan> cabra?
<vambboy> foi mal
<vambboy> era cobra
<nosklo> precisamos de um encoding pra decodificar as frases do vambboy
<NandoFlorestan> só por causa disso, meu próximo software em python vai se chamar CABRÓN
<vambboy nosklo, c te ofendi desculpa
<nosklo> ofendeu nada, eu nem entendi o q vc falou
<vambboy> kkkkkkkkkkkkk
* NandoFlorestan vê que vambboy está na berlinda…
<NandoFlorestan> cabra + python = cabrón
<nosklo> NandoFlorestan, tem alguma documentação deste encoding? não é mto difícil implementar encodings.
<NandoFlorestan> Maldito seja o feadapot que resolveu me mandar email com essa desgraça…
* NandoFlorestan não quer ficar fazendo encodings, saco
<vambboy> num intendi direito o q o NandoFlorestan quer fazer
<NandoFlorestan> vambboy, existe uma encoding chamada ansi_x3.110-1983
<NandoFlorestan> se você tentar usá-la no Python, dá erro
<NandoFlorestan> Ele não a conhece
<vambboy> nunca vi
<NandoFlorestan> Então eu vou ter que implementá-la e registrá-la
<NandoFlorestan> Tou a fim de delegar para o iconv que todo linux tem
<vambboy> onde é aplicada
<NandoFlorestan> também nunca vi
<vambboy> em q tipos d caracteres?
<NandoFlorestan> não sei, mas é exótica mesmo
* NandoFlorestan não decodificou e portanto não leu o email
<vambboy> ah tah
<vambboy> e quem diabos mandaria um email assim?
<vambboy> um agente secreto?
<NandoFlorestan> heheheh
<NandoFlorestan> vai ajudar ou só zoar?
<vambboy> bem
<vambboy> procurarei algo
* NandoFlorestan saca seu editor de textos colaborativo
<NandoFlorestan> …como chamava mesmo?
<nosklo> NandoFlorestan, se vc tiver documentação do encoding fica fácil, delegar pro iconv sux
<nosklo> hummmmmmmm
<NandoFlorestan> gobby
* nosklo começa a escrever um encoding para iconv x.decode(‘iconv:XXXX’) onde XXXX é passado para o iconv
<nosklo> mas relaxe, mto breve vc poderá usar qq codec suportado pelo iconv
<NandoFlorestan>
* nosklo está modificando o código q já tinha
* NandoFlorestan pensa num recurso: dar um iconv –list e registrar todos os codecs que Python não tenha
<nosklo> besteira
<nosklo> NandoFlorestan, x.decode(‘iconv:xxxx’)
<nosklo> NandoFlorestan, vc só roda o subprocesso iconv se precisar usar o codec
<vambboy> em q módulo se encontra o iconv?
<nosklo> vambboy, iconv é um aplicativo escrito em C
* NandoFlorestan testa
<nosklo> NandoFlorestan, hah, teste depois q eu mandar o codigo
<NandoFlorestan nosklo, não faz ‘iconv:xxx’
<NandoFlorestan> faz com o nome correto da encoding: ansi_x3.110-1983
<nosklo> NandoFlorestan, entao, isso q estou falando
<nosklo> NandoFlorestan, no seu caso vc vai usar, suastring.decode(‘iconv:ansi_x3.110-1983′)
<NandoFlorestan> mas sem prefixo iconv:
<NandoFlorestan> tá, mas eu vou mudar seu código pra tirar o prefixo
<nosklo> NandoFlorestan, bom ok
<NandoFlorestan> porque isso tá chegando de um email e eu não quero ficar lidando com exceções
<nosklo> NandoFlorestan, a minha idéia é não precisar saber de antemão quais os codecs que tem disponíveis, pq senão eu tenho que chamar o iconv mesmo se não for precisar dele
<NandoFlorestan> Faz sentido, mas eu acho que precisamos dos 2 modos de operação então
<NandoFlorestan nosklo, o comando é iconv -f utf8 -t ansi_x3.110-1983 -c
<NandoFlorestan> -f é from, -t é to, -c é pra omitir caracteres inválidos.
<nosklo> o -c será dado se vc passar x.decode(‘iconv:xxx’, errors=’ignore’)
<NandoFlorestan> isso isso
<nosklo> pronto, .decode e .encode já está funcionando
<nosklo> agora vou fazer codecs.open(‘arq’, encoding=’iconv:xxxx’)
<vambboy> quando terminarem manda um paste aí, quero estudar o código
<NandoFlorestan nosklo, http://pypi.python.org/pypi/iconv/1.0
<nosklo> argh
<nosklo> ja existe
* nosklo deleta tudo
<NandoFlorestan> caaalma
<NandoFlorestan> tem que ver se é bom
<nosklo> testa aí então, vou comer alguma coisa
<NandoFlorestan> nosklo, import iconv já dá pau
<NandoFlorestan> nosklo, essa porcaria de módulo iconv não funfa porque foi feito em C em 2005
<nosklo> NandoFlorestan, okay, continuando

(… alguns minutos depois …)

<nosklo> bom, tá funcioando
<nosklo> funcionando
<nosklo> NandoFlorestan, vambboy, huahauhauahuaha
<nosklo> >>> u’teste’.encode(‘iconv:CP284′)
<nosklo> ‘\xa3\x85\xa2\xa3\x85′
<nosklo> >>> _.decode(‘iconv:CP284′)
<nosklo> u’teste’
<NandoFlorestan> nosklo, cadê?
<NandoFlorestan> cá… dê !!! dê cá!
<NandoFlorestan nosklo… por favor?
<nosklo> NandoFlorestan, opa… ja vai, colando…
<vambboy> nosklo, tô vuando isso quer dizer que funcionou?
<nosklo> NandoFlorestan, vambboy, tá ai http://dpaste.com/5377/
<nosklo> só dá um import estearquivo
<nosklo> e pronto
<nosklo> vc pode usar qq codec do iconv
<nosklo> no codecs.open etc

Un petit truc ràpid que poso en el blog.

Microsoft Outlook té problemes amb la codificació UTF-8. Aquest fet és notori quan des d’una web fas ús de la comanda “mailto” en un enllaç per a què se t’obri directament el gestor de correu.

Si tens la web codificada en UTF-8, tindràs problemes si el teu gestor és l’Outlook. Caràcters amb accents o “ñ” o dièresis, no es veuran correctament. El truc és utilitzar les llibreries de conversió en PHP ‘iconv’.Amb aquesta funció pots passar una cadena de UTF8 a ISO-8859-1 (que si interpreta outlook).

Així que si programes amb PHP amb codificació UTF-8, i utilitzes “mailto”, et pot anar bé aquest codi:

$subject = “El meu assumpte té un accent.”;

$subject_mailto = rawurlencode(iconv(‘UTF-8′,’ISO-8859-1′,$subject));

echo ‘<a href=”mailto:desti@test.com?subject’.$subject_mailto.’”>enviar mail</a>’;

Following up on my previous post about the differences between the mbstring and iconv international characters libraries (which resulted in a tentative conclusion that nobody knew anything about those differences), and particularly the comments by Nicola, we have combined forces (mostly efforts from Nicola, actually) to provide you with a little benchmarking, if that can help you decide.

Nicola wrote the following script (which he gladly releases as public domain license) to test the efficiency of both the mbstring and iconv extensions for PHP5:

<?php

ini_set(‘iconv.internal_encoding’, ‘UTF-8′);
ini_set(‘mbstring.internal_encoding’, ‘UTF-8′);

function dummy_strlen($str)
{
}

function scan_file($file, $strlen)
{
fseek($file, 0);

$chars = 0;
$lines = 0;
$start_time = microtime(true);

while (!feof($file)) {
$chars += $strlen(fgets($file));
++$lines;
}

// Calculating elapsed time
$sec = microtime(true) – $start_time;
$usec = (int) ($sec * 1000000);

// Formatting
$strlen = str_pad($strlen, 20);
$usec = str_pad($usec, 10);

echo “$strlen$usec($lines lines and $chars chars)\n”;
}

// Text: 13083-utf8.txt
// From: http://www.gutenberg.org/files/13083/13083-utf8.txt

$file = fopen(‘13083-utf8.txt’, ‘r’);

scan_file($file, ‘dummy_strlen’);
scan_file($file, ’strlen’);
scan_file($file, ‘mb_strlen’);
scan_file($file, ‘iconv_strlen’);

fclose($file);

?>

Although we were expecting boring results, they are actually quite interesting. The following are results for the script above (always prefixed by the system details)

Linux amd64 2.6.26-ntd #1 PREEMPT Mon Jul 28 18:54:30 CEST 2008
x86_64 x86_64 x86_64 GNU/Linux

PHP 5.2.4 (cli)
iconv library version => 2.5
Multibyte regex (oniguruma) version => 4.4.4

dummy_strlen 5853 (4485 lines and 0 chars)
strlen 4853 (4485 lines and 150846 chars)
mb_strlen 8574 (4485 lines and 140932 chars)
iconv_strlen 38774 (4485 lines and 140932 chars)

————

PHP 5.2.4 (CLI version)
iconv 2.7 for glibc
mbstring regex oniguruma 4.4.4 (string engine libmbfl)
on an Apple Mac Book Pro (II), at 2.1GHz

dummy_strlen        15965     (4485 lines and 0 chars)
strlen              12470     (4485 lines and 150846 chars)
mb_strlen           34167     (4485 lines and 140932 chars)
iconv_strlen        48865     (4485 lines and 140932 chars)

Second execution (caching might help):
dummy_strlen        15692     (4485 lines and 0 chars)
strlen              12532     (4485 lines and 150846 chars)
mb_strlen           14727     (4485 lines and 140932 chars)
iconv_strlen        40086     (4485 lines and 140932 chars)

Tenth execution (stabilised):
dummy_strlen        15661     (4485 lines and 0 chars)
strlen              8369      (4485 lines and 150846 chars)
mb_strlen           6906      (4485 lines and 140932 chars)
iconv_strlen        34092     (4485 lines and 140932 chars)

—–

PHP 5.2.4 (Apache 2 version)
iconv 2.7 for glibc
mbstring regex oniguruma 4.4.4 (string engine libmbfl)
on an Apple Mac Book Pro (II), at 2.1GHz

dummy_strlen  38218 (4485 lines and 0 chars)
strlen        35356 (4485 lines and 150846 chars)
mb_strlen     35804 (4485 lines and 140932 chars)
iconv_strlen  66275 (4485 lines and 140932 chars)

And second execution:

dummy_strlen  52164 (4485 lines and 0 chars)
strlen        34219 (4485 lines and 150846 chars)
mb_strlen     35706 (4485 lines and 140932 chars)
iconv_strlen  65080 (4485 lines and 140932 chars)

Tenth execution:

dummy_strlen  59885 (4485 lines and 0 chars)
strlen        35341 (4485 lines and 150846 chars)
mb_strlen     36179 (4485 lines and 140932 chars)
iconv_strlen  66632 (4485 lines and 140932 chars)

The evident conclusion from this set of results is that iconv is quite slower than mbstring, although we do not have enough insight to tell if this is due to a compilation difference or anything like that.

The idea is that anyway, we have configurations identical to what most people will have, so it is very likely that the results will be the same in many cases, and as such iconv should be avoided for efficiency reasons, unless some of its very specific functions are required.

You can download the text file used in this example from here:http://mirror3.mirrors.tds.net/pub/gutenberg.org/1/3/0/8/13083/13083-utf8.txt

You will have to copy and paste the script above (there is no way to upload a simple text file here).

Mdb tool is a strong tool to convert your mdb files (microsoft access database files) to any other format. I had a problems with mdb tool with encoding.

I had a files of “bok” extension, but they are mdb files. those files are uft-8 but the content is windows-1256 and i don’t know why. Exporting the data of those files gives a corrupted data. and I couldn’t convert the output back again

Finally I gathered the scattered information about mdb-tool and I found that I have to set TWO environment variable, the first one is MDB_ICONV

export MDB_ICONV=utf-8

The other variable related on which JET version you are using

mdb-ver file.mdb

If you have JET3 then set the second env variable MDB_JET3_CHARSET

export MDB_JET_CHARSET=utf-8

After setting the env variables, export the data into csv file for example

mdb-export -q ‘”‘ -d ‘,’ -R ‘\n’ > file.csv

or your can get SQL insert statements:

mdb-export -I -q ‘”‘ -d ‘,’ -R ‘\n’ > file.txt

Los juegos de caracteres o las nuevas líneas diferentes pueden complicar el intercambio de datos entre usuarios Linux. Un par de herramientas de conversión nos evitarán el quebradero de cabeza.

Heike Jurzik

Olá pessoal!

Hoje vou iniciar uma série de postagens sobre como gerar documentos em PDF usando a classe FPDF.
Por agora vou mostrar como fazer a configuração básica e criar um exemplo funcional. Go, Go, Go!!

Você pode baixar o FPDF no site oficial do projeto: http://www.fpdf.org/. Para começar a criar seus arquivos em PDF, basta copiar os arquivos para seu servidor web. Certifique-se de que os arquivos estão no seu include path.

Vamos então à um exemplo prático:

<?php

define(‘FPDF_FONTPATH’,'font/’);

require(‘fpdf_dir/fpdf.php’);

$pdf = &new FPDF(“L”,”mm”,”A4″);
$pdf->Open();
$pdf->AddPage();
$pdf->SetFont(‘Arial’,'B’, 14);
$pdf->Text(40,20,’Título do Relatório’);
$pdf->SetLineWidth(0.7);
$pdf->Line(40,22,200,22);
$pdf->SetXY(40,26);
$pdf->SetFont(”,”,12);
$pdf->Cell(30,5,’Modelo’,0,0,’C',0);
$pdf->Cell(30,5,’Fabricante’,0,0,’C',0);
$pdf->Output();
?>

Explicando o código:

Define o caminho para as fonts usadas pelo FPDF. Em outro post irei explicar como criar suas próprias fonts.
define(‘FPDF_FONTPATH’,'font/’);

Inclui as definições da classe FPDF no script PHP.
require(‘fpdf_dir/fpdf.php’);

Cria uma nova instância da classe FPDF para um documento com orientação paisagem (Landscape), com medidas em milímetros e no formato A4. Feito isso, o documento é iniciado.
$pdf = &new FPDF(“L”,”mm”,”A4″);
$pdf->Open();

Adiciona uma nova página ao documento.
$pdf->AddPage();

Define a font do documento como Arial, tamanho 14 em negrito. Essa configuração será válida até que SetFont() seja chamado novamente.
$pdf->SetFont(‘Arial’,'B’, 14);

Escreve o texto “Título do Relatório” na linha 40 (eixo x) e coluna 20 (eixo y)
$pdf->Text(40,20,’Título do Relatório’);

Cria uma linha horizontal logo abaixo do texto definido anteriormente.
$pdf->SetLineWidth(0.7);
$pdf->Line(40,22,200,22);

Aponta o cursor para a posição (x,y) definida em SetXY(). Retira o negrito da font e altera o tamanho para 12.
$pdf->SetXY(40,26);
$pdf->SetFont(”,”,12);

Cria duas células com as mesmas dimensões ( 30mm de largura e 5mm de altura ), sem borda, apontando o cursor para o final da linha, após a célula criada, com o texto alinhado no centro e com prenchimento transparente.
$pdf->Cell(30,5,’Modelo’,0,0,’C',0);
$pdf->Cell(30,5,’Fabricante’,0,0,’C',0);

Finalmente, renderiza o seu documento \o/.
$pdf->Output();

Encoding

Caso você tenha problemas com acentuação na saída do documento, use a função iconv do PHP. Nela você irá converter um texto de um charset de origem para outro de destino. Use desta forma:
$pdf->Text(40,20,iconv(‘utf-8′,’iso-8859-1′,’Título do Relatório’));

É isso ai, espero que tenham gostado. Um abraço e até o próximo post.

I am working on something that needs a list of words, without regard to american vs. british or accents or anything: just has to be as many words as possible.  There are a whole bunch of aspell dictionaries available.  First expand the files:

preunzip *.wl

Then merge into a single list, eliminating duplicates:

sort –unique –ignore-case *.wl >list.txt

In additon, I want everything to be UTF-8:

iconv -f ISO8859-1 -t UTF-8 list.txt >ulist.txt

Pretty simple.  The merged english word list has 137,883 words.

Pido disculpas desde ya por haber dejado un poco desatendido el blog, pero entre el blog de Software Libre de la Universidad de Deusto, que me sirve de opinódromo, y la migración del servidor de mi casa a godaddy, que me ha forzado a hacer más tareas de administración (backups de bases de datos con cambios de “encoding” de por medio, configuración de mod_rewrite en godaddy, intento frustrado de instalar dotclear 2.0 en lugar de dotclear 1.2, etc.), es cierto que no he aparecido mucho por aquí. Supongo que no os interesará mucho, pero en este artículo os contaré un poco qué he ido haciendo para migrar…

Exportar la base de datos MySQL del blog

En godaddy todavía usan un vetusto MySQL 4.0.x y en el servidor de casa, después de ir migrando desde MySQL 3.3.x hasta MySQL 5.0.x ya no sabía ni lo que tenía, así que a la hora de hacer el mysqldump hubo unos pocos problemas:

1. Diferentes charsets en las bases de datos.
2. Diferentes versiones, diferente SQL.
3. Comentarios no soportados a la hora de importar la base de datos.

Todos los problemas se resuelven fácilmente:

1. El charset, utilizando la opción –default-character-set al exportar y usando iconv para pasar de un charset a otro.
2. Las versiones de MySQL, usando la opción –compatible=mysql40.
3. Los comentarios, con sed o el propio vi.

Así pues, la cosa quedaría de esta manera:

mysqldump --default-character-set=latin1 --compatible=mysql40 -u usuario -p > basededatos-latin1.sql

iconv -f iso-8859-15 -t utf8 basededatos-latin1.sql > basededatos-utf8.sql

sed -e "s/\/\*.*\*\///g" < basededatos-utf8.sql > basededatos-fin.sql

Con el sed lo que hago es sustituir el patrón /*algo*/ por nada (la cadena vacía), lo que pasa que como hay que escaparlo todo con \s queda un poco farragoso de entender.

Instalar dotclear 1.2

Realmente lo que yo quería era aprovechar y migrar a dotclear 2.0, pero dotclear 2.0 necesita MySQL 5.0.x y en godaddy todavía van por la 4.0.x Así que me bajé el tarball de dotclear de su página web, lo descomprimí y lo subí a godaddy por FTP (leeeeento). Una vez subido, simplemente seguí los pasos de install.php y me dí cuenta de que tenía que importar previamente la base de datos recién exportada (lógico), así lo hice y todo funcionó bien. Bueno, todo no. Se veía la página principal bien, pero en cuanto pulsaba algún enlace para ver las entradas del blog, me daba un error 404 muy extraño. Investigando un poco ví que godaddy no tiene PHP como módulo, sino como un CGI, así que era necesario utilizar mod_rewrite del Apache para que todo funcionara bien.

Configurar mod_rewrite en godaddy

El módulo mod_rewrite te permite hacer muchas reescrituras de la petición realizada al servidor (si os queréis rayar de verdad, visitad la página de ayuda de mod_rewrite, muy ilustrativa). La verdad es que no me comí mucho el coco y directamente busqué cómo lo había hecho otra gente. Casi nadie usa dotclear, pero había muchos usuarios con un problema similar en WordPress y godaddy, así que copié un ejemplo de configuración, y funcionó. Además, aproveché para usar PHP5 en lugar de PHP4 en mis páginas, dejando un .htaccess como este:

AddHandler x-httpd-php5 .php
AddHandler x-httpd-php .php4

# BEGIN dotclear

RewriteEngine On
#RewriteBase /blog/
#RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d
#RewriteRule . /blog/index.php [L]

# END dotclear

Como se puede ver, toda la configuración de mod_rewrite está comentada (con #s) salvo RewriteEngine On. Al principio pensé que tenía que configurarlo específicamente para ese directorio en el servidor, tomar lo que me había pedido, pasárselo a index.php y demás, pero luego ví que mod_rewrite hacía todo eso él solito. Subí el .htaccess a mi directorio de hosting y… ¡listo!

Gros problème dans une appli, suite à la modification avec Eclipse de fichier JS on obtient des erreurs.

Le fait est qu’Eclipse n’encode pas en ISO-8859-1 (AKA Latin-1) les fichiers de type JS par défaut. Du coup on se retrouve avec des fichiers mal ouverts, mal encodés et surtout mal enregistrés.

La première des choses est donc d’aller dans Windows->Preferences puis Général -> Content types -> Text -> Javascript et de spécifier Default encoding à UTF-8.

UTF-8 est le choix le plus judicieux au niveau compatibilité mais on aurait, dans le cas d’un dev’ non internationnal, pu forcer le serveur web à définir dans l’en-tête un encodage de type ISO-8859-1 pour les fichiers de type .JS.

Quoiqu’il en soit nous voici avec moults fichiers JS encodés en ISO-8859-1 et un éditeur configuré en UTF-8, il nous reste donc à modifier tous nos fichiers afin de les ré-encoder de l’ISO vers l’UTF-8.

Pour ce faire on peut utiliser unitairement iconv ou un traitement batch via le script suivant

#!/bin/bash
FROM=latin1
TO=utf8
ICONV="iconv -f $FROM -t $TO"

# Convert pages/ subdir
find repToConvert/ -type f -name "*.txt" | while read fn; do
cp ${fn} ${fn}.bak
$ICONV  ${fn}
rm ${fn}.bak
done

ATTENTION toutefois, les utilisateurs de Cygwin devront utiliser

#!/bin/bash
FROM=ISO8859-15
TO=UTF-8

Un petit tour sur splitbrain.org pour trouver l’origine de ce script.

In order to properly display NFO files, their content has to be converted to your local codepage.
In my case that is UTF-8. The conversion will be done with iconv. To get the solid block characters I chose the input codepage IBM 437.
So the resulting command is:

iconv -f 437 -t UTF8 dafile.nfo | less

For a list of available formats type:

iconv --list

It is handy to have this command as a script. That would be something like this:

#!/bin/bash
# Display DOS ASCII Arts (e.g. NFO Files)

if [ -z "$@" ]
then
  echo "No filename given."
  echo "Usage: `basename $0` filename(s) [filename(s)]..."
else
  iconv -f 437 -t UTF8 "$@" | less
fi

exit 0

You can download this script from my Box.net share.

Click on the screenshot to view a larger version.

ChangeLog

[2006-04-23: Add tags.]
[2007-05-23: Download link.]