Recent changes to bugs

Segment fail for latin1 characters

Javier Gracia — Wed, 04 Jun 2014 10:59:38 -0000

Assigning variables on Segment objects fails on (non ASCII) ISO 8859 characters.
Bug can be solved switching 2 lines in Segment::setVars() function:
$value = ($charset == 'ISO-8859') ? utf8_encode($value) : $value;
$value = $encode ? htmlspecialchars($value) : $value;
Thanks for this project!

tag with inner xml

luca capra — Sun, 27 Mar 2011 16:14:48 -0000

This not really a bug, but a workaround.
I generate an odt document prepared from users.
Many times there are tags like:
{<text:span text:style-name="T34">M</text:span>y<text:span text:style-name="T34">Tag</text:span>}

I've solved in the way that follow, hope could be useful.

<?php
$data = array(
"tag"=>"value",
);
$odf = new odf(...);

$fulltext = $odf->__toString()
preg_match_all("~\{([^{]+)\}~ium", $fulltext, $res);

foreach($tokens[1] as $token)
{

if(key_exists($tokenx = strip_tags($token), $data)){
preg_match_all("~<[^<]*>([^<>]*)~iu", $token, $res);
$pieces = $res[1];
$tmpk = implode("", $pieces);
// echo "<p>".htmlspecialchars($token)." -> $tmpk";
if(strlen(trim($tmpk)) > 0 && key_exists( $tmpk, $data ))
{
$data[$token] = $data[$tmpk];
}
}
else
if(! key_exists( $token , $data) )
{
$data[ $token ] = "";
}
}
// go on rendering
foreach($data as $k=>$var)
$odf->setVars($k, $var);

$odf->exportAsAttachedFile();
?>

Openoffice 3.x gives corrupted document warning

Anonymous — Thu, 09 Dec 2010 16:47:44 -0000

When the odt generated by odtPHP contains images, upon opening the document OpenOffice shows a dialog box saying that odt file is corrupted and ask to repair it or not. After studying Openoffice document structuring I found reason of this problem and also be able to solve it. Refer to my blog post for more details-:
This warning is due to the fact that odtPHP does not modifies manifest.xml file. For details about problem and its solution see my following blog spot-:
http://vikasmahajan.wordpress.com/2010/12/09/odtphp-bug-solved/

Bug with the charactere "<"

Anonymous — Tue, 01 Jun 2010 10:12:15 -0000

To start, we have a text like "3<6". When we open the document with OpenOffice, we have an error to the content.xml because of the character.

html_entity_decode in setSegment() invalidated my document

Anonymous — Sat, 22 May 2010 07:36:20 -0000

i had a '&' in my odtphp template file (& in the content.xml) and after parcing, the document was unreadable.
the '&' was inside a segment. i changed the line 243 from

if (preg_match($reg, html_entity_decode($this->contentXml), $m) == 0) {
to
if (preg_match($reg, ($this->contentXml), $m) == 0) {

that seemed to have worked for me. just wanted to share ;-).
realy great work you guys did!!! saved me a bunch of work. keep it up, love windwerfer.

problem with oo 3.2.0 and images

Anonymous — Wed, 24 Feb 2010 10:40:13 -0000

Hi, everybody
I've found a nasty behavior. Consider an odt file with

{image1}

on opening OO gives you "corrupted file" warning but fix it.

in odf file with

{image1} {image2}

on OO give you a "corrupted file" warning and fix only the first image.

I dug in with a xml explorer the original and fixed content.xml and found out that the original have the images in a text tag
while the fixed has all the images out of text tag and listed as siblings.

bug avec open_basedir restriction

Eriseux — Fri, 02 Oct 2009 18:25:22 -0000

Le pb : l'appel $tmp = tempnam(null, md5(uniqid())); dans le constructeur échoue ; le passage du paramètre null essaye d'ouvrir un dossier temp par défaut qui n'est pas trouvé ("open_basedir restriction in effect. File(/tmp) is not within the allowed path(s)") ; dans la config de nos serveurs (hotes virtuels), le dossier tmp n'est pas dans les chemins accessibles par défaut ; il faut du coup lui passer "en dur" le chemin : $tmp = tempnam('/var/www/virtual/www.monsite.fr/phptmp', md5(uniqid())); pour que cela marche. On tombe donc dans le cas du pb de la maj de la classe pour suivre son évolution.

L'extension de la classe + redéfinition du constructeur (pour pallier le pb) provoque une erreur : Fatal error: Call to private method Odf::_moveRowSegments() from context 'Odf_Dfoad' in C:\wamp\www\phpodt\library\odf_dfoad.php on line 34

puisque la méthode $this->_moveRowSegments(); est appelée dans le constructeur parent

Pour que cela fonctionne il faut soit passer la méthode à public (pas une bonne idée) ou protected (mieux) pour que la classe fille puisse l'étendre ; Dans ce cas je redéfini le constructeur dans la classe fille en passant en dur mon chemin ; marche bien tant que le constructeur de la classe parente n'évolue pas, c'est un copier/coller... (pas terrible pour l'évolutivité). Donc pas une très bonne solution non plus.

En définitive ce qui me semble le plus approprié (dans une première approche) :

Proposition de patch :
Passer par le chemin vers le répertoire d'upload temporaire du serveur et profiter du tableau $config et lui ajouter un paramètre par exemple : 'PATH_TO_TMP' => null

soit : protected $config = array(
'ZIP_PROXY' => 'PclZipProxy',
'DELIMITER_LEFT' => '{',
'DELIMITER_RIGHT' => '}',
'PATH_TO_TMP' => null
);

et modifier $tmp = tempnam(null, md5(uniqid())); en

$tmp = tempnam($this->config['PATH_TO_TMP'], md5(uniqid()));

du coup on peut passer le paramètre à la création de l'objet et profiter des mises à jour de la classe... (qui est très bien au passage !! ;) )

Patch testé et validé sur mon serveur de prod.

ou 2ème solution : récupérer la valeur de la directive upload_tmp_dir avec ini_get("upload_tmp_dir") si la tempnam échoue (peut être plus portable que la solution 1 ??) ; pas encore testé pour ma part.
Qu'en pensez-vous ?

Bug with ZipArchive since PHP 5.3.7

Vincent Brouté — Fri, 15 May 2009 13:50:14 -0000

Since PHP 5.2.7, the archive copression with Zip extension make troubles for ODT documents. The generated ODT document will be corrupted. This bug was confirmed by the php-zip author. It should be fixed in the next version of Zip.

Pictures are always centered

Vincent Brouté — Fri, 15 May 2009 13:45:41 -0000

Pictures are always centered, even if in the template, the tag for the picture is to the right or to the left.

Carriage returns don't take effect

Vincent Brouté — Fri, 15 May 2009 13:42:06 -0000

Carriage returns in data source don't take effect in the generated ODT document. All the text is displayed in line.