Image support

[robsalasco]

This gem is great! Would be possible to add support for embedding images in the short time?

Thank you!

[mmmries]

@robsalasco can you give me a snippet of how you would like to use that feature?

[garrettpoelman]

http://blogs.msdn.com/b/dmahugh/archive/2006/12/10/images-in-open-xml-documents.aspx?Redirected=true

Great example here.

Download the images.zip file. Unzip it. Has a images.docx in it. Change that file to images.zip unzip it.

_rel dir

On Feb 10, 2014, at 10:10 PM, "Michael" <notifications@github.commailto:notifications@github.com> wrote:

@robsalascohttps://github.com/robsalasco can you give me a snippet of how you would like to use that feature?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-34726910.

[mmmries]

Hmmm, let me summarize to make sure I'm understanding the feature.

It sounds like we probably want to just start with embedded images?

We have a document with a placeholder like ||brand_logo|| and we are going to do the following:

• Make sure the content type is defined in [Content_Types].xml
  • Should we detect the type of image or force the user to pass it in?
• Insert a v:pict snippet where the placeholder was found.
  • How do we determine the dimensions?
  • How do we determine a relation ship id?
  • What the heck is type="#_x0000_t75"?
• Add an xml node to _rels/document.xml.rels with the id and target
• Add the binary contents of the image to the main zipped directory
  • Should we just generate a uniq ID as the file name?

[mmmries]

So the main thing about this feature that adds complexity is the fact that we need to keep document-level context around during placeholder replacement. The current implementation just replaces contents inside of a single xml file at a time. The part of the code that is looking for placeholders has no idea that those placeholders are inside a document that has a _rels/document.xml.rels file or a [Content_Types].xml file. So this would require some restructuring of the library.

I think the feature fits within the scope of the gem just fine so once we can answer the questions above I think this would be a good feature to add overall.

[garrettpoelman]

My thoughts...

Process images and placeholders separately.

Require the calling application to store all images in a local directory

Pass an additional hash to the docx_generator, something like:

{ path => '/xxx' {placeholder => { height => , width =>, type =>, name =>} }, {placeholder => { height => , width =>, type =>, name =>}}

Create the _rels document, context type document
run through placeholder replacements for images, then the current replacement process.

The type="#x0000t75" tells word that it is a "shapetype" so it is the same for all images.

[mmmries]

Here is a possible alternative:

replacements = {
  :quote => "The genius behind Isaac’s design of npm is that it solves dependencies, a longtime problem in computer science...",
  :meme => DocxTemplater::Image.new('public/assets/npm_meme.png', :height => 400, :width => 400)
}

One things I like about this is that if you have images that aren't on disk (ie maybe they are stored in Amazon S3, or maybe you have the blob of data in your database) you could construct an image replacement object. The relationship ID and filename that we use to write the image into the zipped directory could be based on a SHA1 or MD5 of the image data that way embedding the same image multiple times will only actually stick the image data into the docx once.

[catalystmediastudios]

@hqmq I like that idea a lot. It makes a lot of sense and is really flexible!

On Feb 12, 2014, at 10:11 AM, Michael notifications@github.com wrote:

Here is a possible alternative:

replacements = {
:quote => "The genius behind Isaac’s design of npm is that it solves dependencies, a longtime problem in computer science...",
:meme => DocxTemplater::Image.new('public/assets/npm_meme.png', :height => 400, :width => 400)
}
One things I like about this is that if you have images that aren't on disk (ie maybe they are stored in Amazon S3, or maybe you have the blob of data in your database) you could construct an image replacement object. The relationship ID and filename that we use to write the image into the zipped directory could be based on a SHA1 or MD5 of the image data that way embedding the same image multiple times will only actually stick the image data into the docx once.

—
Reply to this email directly or view it on GitHub.

[robsalasco]

omg! @hqmq I really like your implementation! that would be a killer feature!

[handlez36]

Was image support ever added for this Gem?

[mmmries]

@handlez36 no. This gem has been stagnant since 2014. I wrote it for an application for a previous job and haven't had a reason to use it again since then.

I would be happy accept pull requests that add this support or even transfer ownership of the repo/gem to someone else if they want to continue to maintain it.