New function in TemplateProcessor to add images to documents

[ejn]

Image placeholders have the form ${img:<name>}.

The width and height of the image to insert may be specified as
additional arguments to the placeholder: ${img:<name>:width:height}

For the width and height, CSS units cm, mm, px, pt and pc may be used,
e.g. ${img:beispiel:15cm:360pt}

[ejn]

(updated the PR to split into two PRs due to code overlap with #1086)

[SadPencil]

that's helpful.
I wonder if it's possible to give a base-64 image string instead of a file path to add image in template?

[ejn]

@SadPencil tbh I'm not sure what would be possible internally in the DOCX, but it should be straightforward to allow the image to be passed as a string (no need for base64-encoding!) instead of a file path and then write the string to an internal file in the DOCX. It would require a little refactoring of addImageToArchive() and insertImage() (probably to API methods insertImageFromString() and insertImageFromFile() with a common helper method), but the changes to this PR should be pretty straightforward. Why not give it a go?

[SalvatorePollaci]

When will this pull request be merged?

[FBnil]

@ejn:

I like your work a lot. And I've got a working copy of something similar to insertImageFromString() but broader.
I've exposed zipAddFromString(), basically:

    /**
     * Updates a file inside the document, from a string (with binary data)
     *
     * @param string $localname
     * @param string $contents
     *
     * @return bool
     */
    public function zipAddFromString($localname, $contents)
    {
        return $this->zipClass->AddFromString($localname, $contents);
    }

That already allows to retain the dimensions/position/properties of the image and only change the image. Tested to work with Office 365 and LibreOffice. Even if the new jpg has a bigger size.

A working example is in my pull request: #1147

@SadPencil You can do exactly what you describe in the current PHPWord version 0.13; first define this class (You can do it inline, just above your code):

class OpenTemplateProcessor extends \PhpOffice\PhpWord\TemplateProcessor
{
    protected $_instance;

    public function __construct($instance) {
		return parent::__construct($instance);
    }

    public function __get($key) {
        return $this->$key;
    }

    public function __set($key, $val) {
        return $this->$key = $val;
    }
}

now instead of new TemplateProcessor(), do a new OpenTemplateProcessor()
This object behaves the same, but has access to the zipClass, like so:

$replace = "word/media/image2.jpeg";
$met = file_get_contents(storage_path('anyNewImage.jpg'));
$templateProcessor = new OpenTemplateProcessor($file_dir);
$templateProcessor->zipClass->AddFromString($replace,$met);
// now use save() or saveas()

and you have injected a new image.

[FBnil]

@ejn Still working on a united script, can you make your script that it also allows a insertImageFromString() and a insertImageFromFile() where the latter just uses the first to do all the job?

Still waiting for your Feedback about if it is better to have uniform names, setValue(), setImage(), etc.
At least for the public functions, the protected functions can stay named the way they are.

[rkorebrits]

Hi @ejn , I'm trying to implement your changes, but the output file is borked. I've checked out your branch and using the code 100% as you pushed it.

I've set up an empty file with just the variable to test, this is the result:

Template: empty.docx
Output: CV_680989964_Test_Name_20180507-140848.docx

When I open the output file, I get this message:

After clicking "ok" here, I get the option to "recover the contents", which works, but it's not a viable solution. Am I missing something here? Or what could cause this issue?

[ejn]

@rkorebrits: Looking at the result file and the file after Word has repaired it, the [Content_Types].xml is borked - I'm guessing by a . in the filename of the image you're adding which is being interpreted as the file extension (Extension="76766837.jpeg").

The workaround is probably to make sure that there is no . in the filename apart from before the real extension, a real fix would be to replace strpos with strrpos in line 820/821 (or do getting the extension in some other better way).

If/when I get around to reworking this to take care of the points raised by @FBnil (using the existing methods to generate the XML rather than just slapping in pre-prepared chunks) then I'll be sure to take care of that too.

[rkorebrits]

Thanks @ejn! That did the trick :-)

[rkorebrits]

@ejn I have updated the code to check if there is an image passed, and if the image actually exists. If the image doesn't exist it threw a PHP error before on getimagesize. When there is no image, the tag should be removed imho.

public function insertImage($name, $srcFilename, $width = null, $height = null, $mimeType = null, $filename = null)
{

    if ( ! $srcFilename || ! file_exists($srcFilename)) {
        $removeImageRegex = '/\${img:' . $name . '.*?}/i';

        foreach ($this->tempDocumentHeaders as $index => $header) {
            $this->tempDocumentHeaders[$index] = preg_replace(
                $removeImageRegex, '', $this->tempDocumentHeaders[$index]
            );
        }

        $this->tempDocumentMainPart = preg_replace(
            $removeImageRegex, '', $this->tempDocumentMainPart
        );

        foreach ($this->tempDocumentFooters as $index => $footer) {
            $this->tempDocumentFooters[$index] = preg_replace(
                $removeImageRegex, '', $this->tempDocumentFooters[$index]
            );
        }

        return $this;
    }

[troosan]

I merged #1170 which is doing the same. Feel free to open a new PR if features are missing