2010-10-19 12 views
11

Mi escenario:Aplanar FDF/XFDF formas a PDF en PHP con caracteres UTF-8

  • Una plantilla PDF con FormFields: template.pdf
  • archivo
  • Un XFDF que contiene los datos que se completa: fieldData.xfdf

Ahora tengo que tener estos archivos combinados & aplanado. pdftk hace el trabajo fácilmente dentro de php:

exec("pdftk template.pdf fill_form fieldData.xfdf output flatFile.pdf flatten"); 

Desafortunadamente esto no funciona con soporte completo de UTF-8. Por ejemplo, las letras cirílicas y griegas se mezclan. Usé Arial para esto, con un conjunto de caracteres Unicode.

  • ¿Cómo puedo lograr aplanar mis archivos Unicode?
  • ¿Hay alguna otra herramienta pdf que ofrezca soporte Unicode?
  • ¿Tiene pdftk un conmutador Unicode que me falta?

EDIT 1: Como esta pregunta no se ha resuelto durante más de 9 meses, decidí comenzar una recompensa por ello. En caso de que haya opciones para patrocinar una función o una corrección de errores en pdftk, me gustaría donar.

EDIT 2: Ya no estoy trabajando en este proyecto, por lo que no puedo verificar nuevas respuestas. Si alguien tiene un problema similar, me alegra que puedan responder a mi favor.

+0

¿Ha intentado utilizar la biblioteca iText directamente para realizar esta función? – Merlin

+0

Eche un vistazo en http://stackoverflow.com/questions/6047970/weird-characters-when-filling-pdf-with-pdftk se ha solucionado mi problema –

Respuesta

1

Desafortunadamente, la codificación de caracteres UTF-8 no funciona ni con referencias decimales ni hexadecimales de caracteres que no sean ASCII en el archivo fuente .xfdf. PDFTK v. 1.44.

+0

Eche un vistazo en http://stackoverflow.com/questions/6047970/weird-characters-when-filling-pdf-with-pdftk –

0

¿Qué versión de PDFTK? Intenté lo mismo con caracteres polacos (utf-8).

No funciona para mí.

pdftk.exe, libiconv2.dll de: http://www.pdflabs.com/docs/install-pdftk/

Windows 7, cmd + file.pdf file.fdf -> NUEVO.pdf

pdftk file.pdf fill_form file.xfdf salida de nuevo .pdf aplanar

Unhandled Java Exception: 
java.lang.NoClassDefFoundError: gnu.gcj.convert.Input_UTF8 not found in [file:.\, core:/] 
    at 0x005a3abe (Unknown Source) 
    at 0x005a3fb2 (Unknown Source) 
    at 0x006119f4 (Unknown Source) 
    at 0x00649ee4 (Unknown Source) 
    at 0x005b4c44 (Unknown Source) 
    at 0x005470a9 (Unknown Source) 
    at 0x00549c52 (Unknown Source) 
    at 0x0059d348 (Unknown Source) 
    at 0x007323c9 (Unknown Source) 
    at 0x0054715a (Unknown Source) 
    at 0x00562349 (Unknown Source) 

Pero, con el archivo FDF, con el mismo contenido, funcionó correctamente. Pero los caracteres en new.PDF son malos.

pdftk file.pdf fill_form file.fdf NUEVO.pdf salida aplanar

--- --- FDF

%FDF-1.2 
%âãÏÓ 
1 0 obj<</FDF<</F(file.pdf) 
/Fields[ 
<</T(Miejsce)/V(666 Poznań Śródmieście Ćwiartka Ósma)>> 
<</T(Nr)/V(ęóąśłżźćńĘÓĄŚŁŻŹĆŃ)>> 
]>>>> 
endobj 
trailer 
<</Root 1 0 R>> 
%%EOF 

--- --- XFDF

<?xml version="1.0" encoding="UTF-8"?> 
<xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve"> 
<f href="file.pdf"/> 
<fields> 
<field name="Miejsce"> 
<value>666 Poznań Śródmieście Ćwiartka Ósma</value> 
</field> 
<field name="Nr"> 
<value>ęóąśłżźćńĘÓĄŚŁŻŹĆŃ</value> 
</field> 
</fields> 
</xfdf> 

--- PDF ---

Miejsce: 666 PoznaÅ— ÅıródmieÅłcie ăwiartka Ãfisma 
Nr: ÄŽÃ³Ä–ÅłÅ‡Å¼ÅºÄ⁄Å—ÄŸÃfiÄ—ÅıņŻŹăŠ
+0

Eso es más o menos el mismo escenario. Intenté con la versión 1.41-3 y con 1.43. Como veo, 1,44 está fuera desde el 28 de octubre de 2010. Lo intentaré. – Mateng

+0

Recibo la misma excepción que la anterior uwith fdf también. – atlantis

1

Puede probar la versión de prueba de http://www.adobe.com/products/livecycle/designer/ y ver qué archivos PDF genera.

Otro software comercial que puedes probar es http://www.appligent.com/fdfmerge. Consulte la página 16 en http://146.145.110.1/docs/userguide/FDFMergeUserGuide.pdf para ver cómo maneja xFDF con UTF-8.

También tuve un vistazo a la especificación FDF http://partners.adobe.com/public/developer/en/xml/xfdf_2.0.pdf En la página 12 se afirma:

Although XFDF is encoded in UTF-8, double byte characters are encoded as character references when 
exported from Acrobat. 
For example, the Japanese double byte characters , , and are exported to XFDF using 
three character references. Here is an example of double byte characters in a form field: 
    ... 
<fields> 
    <field name="Text1"> 
    <value>Here are 3 UTF-8 double byte 
     characters: &#x3042;&#x3044;&#x3046; 
</value> 
    </field> 
</fields> ... 

Miré a través de pdftk-1,44-dist/java/com/Lowagie/texto/pdf/XfdfReader.java . No parece hacer nada especial con la entrada.

Quizás pdftk haga lo que desee, cuando codifique los caracteres extraños como referencias de caracteres en su entrada xFDF.

+0

Gracias, intentaré esa referencia de personaje más tarde. – Mateng

+0

Desafortunadamente, mi instalación de la base de código de esta se corrompió. Esto solo significa algunos días más de retraso. – Mateng

+0

@Mateng ¿Funcionó la cosa de referencia del personaje para ti? – wizonesolutions

1

Usando el pdftk 1.44 en una máquina Win7 encuentro los mismos problemas con xfdf-files mientras que fdf funciona bien. Hice un archivo xfdf sin ningún carácter especial (solo ANSI) pero pdftk colapsó nuevamente. Envié por correo al desarrollador. Desafortunadamente no hay respuesta hasta ahora.

1

Hice algunos progresos en esto. Comenzando con el código de http://koivi.com/fill-pdf-form-fields/, modifiqué la codificación del valor para dar salida a códigos numéricos para cualquier carácter fuera del rango de ascii.

Ahora con cadenas especiales de pitulski:

Poznań Śródmieście Ćwiartka Ósma salidas Pozna ródmiecie wiartka Ósma con algunas formas de caja superpuesta

ęóąśłżźćńĘÓĄŚŁŻŹĆŃ salidas óÓ con más formas de caja. Creo que es posible que las formas de las cajas sean caracteres que mi servidor no reconoce.

Lo probé con algunos caracteres franceses: ùûüÿ€’“”«»àâæçéèêëïôœÙÛÜŸÀÂÆÇÉÈÊËÏÎÔ y todos salieron bien, pero algunos de ellos se superponen.

--edit-- Acabo de intentar ingresar estos manualmente en el formulario y obtuve el mismo resultado menos las formas del cuadro (usando Evince). Luego intenté con un formulario diferente (creado por otra persona): después de ingresar ęóąśłżźćńĘÓĄŚŁŻŹĆŃ, se mostró ółÓŁ. Parece que depende de qué caracteres están incluidos en las fuentes incrustadas del documento.

/* 
KOIVI HTML Form to FDF Parser for PHP (C) 2004 Justin Koivisto 
Version 1.2.? 
Last Modified: 2013/01/17 - Jon Hulka(jon dot hulka at gmail dot com) 
    - changed character encoding, all non-ascii characters get encoded as numeric character references 

    This library is free software; you can redistribute it and/or modify it 
    under the terms of the GNU Lesser General Public License as published by 
    the Free Software Foundation; either version 2.1 of the License, or (at 
    your option) any later version. 

    This library 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 Lesser General Public 
    License for more details. 

    You should have received a copy of the GNU Lesser General Public License 
    along with this library; if not, write to the Free Software Foundation, 
    Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 

    Full license agreement notice can be found in the LICENSE file contained 
    within this distribution package. 

    Justin Koivisto 
    justin dot koivisto at gmail dot com 
    http://koivi.com 
*/ 

/** 
* createXFDF 
* 
* Tales values passed via associative array and generates XFDF file format 
* with that data for the pdf address sullpiled. 
* 
* @param string $file The pdf file - url or file path accepted 
* @param array $info data to use in key/value pairs no more than 2 dimensions 
* @param string $enc default UTF-8, match server output: default_charset in php.ini 
* @return string The XFDF data for acrobat reader to use in the pdf form file 
*/ 
function createXFDF($file,$info,$enc='UTF-8'){ 
    $data= 
'<?xml version="1.0" encoding="'.$enc.'"?> 
<xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve"> 
    <fields>'; 
    foreach($info as $field => $val){ 
     $data.=' 
     <field name="'.$field.'">'; 
     if(is_array($val)){ 
      foreach($val as $opt) 
//2013.01.17 - Jon Hulka - all non-ascii characters get character references 
      $data.=' 
      <value>'.mb_encode_numericentity(htmlspecialchars($opt),array(0x0080, 0xffff, 0, 0xffff), 'UTF-8').'</value>'; 
//    $data.='<value>'.htmlentities($opt,ENT_COMPAT,$enc).'</value>'."\n"; 
     }else{ 
      $data.=' 
      <value>'.mb_encode_numericentity(htmlspecialchars($val),array(0x0080, 0xffff, 0, 0xffff), 'UTF-8').'</value>'; 
//   $data.='<value>'.htmlentities($val,ENT_COMPAT,$enc).'</value>'."\n"; 
     } 
     $data.=' 
     </field>'; 
    } 
    $data.=' 
    </fields> 
    <ids original="'.md5($file).'" modified="'.time().'" /> 
    <f href="'.$file.'" /> 
</xfdf>'; 
    return $data; 
} 
2

He encontrado mediante el uso de la plantilla de Jon, pero utilizando el DomDocument la codificación numérica fue manejado por mí y funcionó bien. Mi pequeña variación es la siguiente:

$xml = new DOMDocument('1.0', 'UTF-8'); 

$rootNode = $xml->createElement('xfdf'); 
$rootNode->setAttribute('xmlns', 'http://ns.adobe.com/xfdf/'); 
$rootNode->setAttribute('xml:space', 'preserve'); 
$xml->appendChild($rootNode); 

$fieldsNode = $xml->createElement('fields'); 
$rootNode->appendChild($fieldsNode); 

foreach ($fields as $field => $value) 
{ 
    $fieldNode = $xml->createElement('field'); 
    $fieldNode->setAttribute('name', $field); 
    $fieldsNode->appendChild($fieldNode); 

    $valueNode = $xml->createElement('value'); 
    $valueNode->appendChild($xml->createTextNode($value)); 
    $fieldNode->appendChild($valueNode); 
} 

$xml->save($file); 
0

Puede introducir caracteres UTF-8 dando su código Unicode en octal con \ ddd

0

Para solucionar esto, escribí PdfFormFillerUTF-8: http://sourceforge.net/projects/pdfformfiller2/

+0

Los enlaces no son respuestas. Se espera que las respuestas sobre SO sean autónomas. Por favor, [revise esta meta pregunta] (http://meta.stackexchange.com/q/8231/135887) y agregue suficientes detalles a su pregunta para que no dependa completamente de un enlace externo. Tal vez debería agregar una muestra de código para mostrar cómo esta biblioteca resolverá el problema. – Charles

0

Hay una Mcpdf gota en el reemplazo para la herramienta de pdftk

: https://github.com/m-click/mcpdf

que resuelve problemas de Unicode al rellenar formularios. Funciona para mí con personajes CP1250 (Europa Central).

Desde la página del proyecto:

el siguiente comando rellena los datos del formulario de DATA.xfdf en Form.pdf y escribe el resultado en RESULT.pdf. También se aplana el documento a prevenir su posterior edición:

java -jar mcpdf.jar FORM.pdf fill_form - output - flatten <DATA.xfdf> RESULT.pdf 

Esto se corresponde exactamente con el comando habitual PDFtk:

pdftk FORM.pdf fill_form - output - flatten <DATA.xfdf> RESULT.pdf 

Tenga en cuenta que es necesario tener instalado JRE.

+0

El gitrepo no proporciona archivos pdf de muestra. Para mis archivos PDF no funciona ni siquiera para su uso -caso de la palabra "Łódź" (faltan algunos caracteres. Probé diferentes caracteres en diferentes formas de PDF. Sí, también traté de generar formularios de LibreOffice). Y no funciona para los caracteres rusos en absoluto en mis pruebas, ni en [otros] (https://github.com/m-click/mcpdf/issues/22). mcpdf probablemente funciona para la tubería del autor, aparte de eso, lamentablemente parece estar roto. Aunque la idea de envolver iText es sólida. – Adobe

Cuestiones relacionadas