When rolling back a transaction using rollbackTransaction(true), member of the preserved object copy (in member $this->objcopy) seem to be destroyed, too.
This leads to $this->dpi getting unset, which, in a later AddPage() results in a division by zero exception in setPageOrientation():
because $this->k is calculated based on $this-dpi which is null after _destroy().
When using
$objcopy = clone $this->objcopy;
in rollbackTransaction() instead of
$objcopy = $this->objcopy;
processing PDF is continued successfully.
It seems, that when creating the object copy in startTransaction(), the clone actually isn't a clone but a reference.
When rolling back a transaction using rollbackTransaction(true), member of the preserved object copy (in member $this->objcopy) seem to be destroyed, too. This leads to $this->dpi getting unset, which, in a later AddPage() results in a division by zero exception in setPageOrientation():
because $this->k is calculated based on $this-dpi which is null after _destroy().
When using
$objcopy = clone $this->objcopy;in rollbackTransaction() instead of$objcopy = $this->objcopy;processing PDF is continued successfully. It seems, that when creating the object copy in startTransaction(), the clone actually isn't a clone but a reference.
Bug is present up to the latest version.
Best regards, Claus.