Added Ability to turn template into a byte string

[d1ngd0]

Not sure if you want to pull this in, but it makes the default FpdfTpl serialize-able using gob. This allows an external package to save a template to memory or a file and turn it back into a template.

The one issue is all templates within a template are assumed to also be FpdfTpl objects. Considering the interface Tpl is public it would allow a user to create an external struct that implements Tpl that could not be a child of a FpdfTpl object.

Also there may be a better way to do this using reflection that wouldn't need to be updated in the event more properties are added to the FpdfTpl and ImageInfoType structs. Although I'm not sure that is possible considering they are non exported fields.

Anyway, figured I would send this your way too.

[jung-kurt]

Thanks, @d1ngd0! Storage of templates is a useful concept. I will look into this and will likely have questions.

[d1ngd0]

One thing to note. It looks like if you have a template within a template and then gob encode and decode it, the images within the inner template won't render. I hope you followed that.

[jung-kurt]

It looks like if you have a template within a template and then gob encode and decode it, the images within the inner template won't render.

If all ImageInfoType and FpdfTpl fields were exported, would the inner template images render? This would allow the FpdfType to be more easily extended, and if it solved the image problem with nested templates the case for simply exporting the fields would be stronger.

[d1ngd0]

If they were all exported there wouldn't be a need for the gob encoding functions because the reflection used in the gob package would pick everything up which would be nice. However, I personally would argue against exporting everything considering how much you would be allowing external packages to break things.

That being said it probably still wouldn't work. I created a gob encoded template from an existing template and saw no difference in the structure of the data. The only difference I saw was cap size differences for arrays and pointer changes.

I will keep playing around with this. I mostly made the comment to ensure you didn't merge.

[jung-kurt]

Thanks for all of your efforts on this. I really like the idea of independent template storage and hope we can come up with the cleanest possible solution.

On the topic of exports, I agree that the problems that would be introduced by exposing internal fields outweigh the (possible) benefits of simpler gob encoding.

Keep up the good work!

[d1ngd0]

This is pretty messy and there is a better way of doing this I'm sure but.... I found that on deserialization the pointer references throughout the tree were being lost. So each ImageTypeInfo object ended up becoming it's own thing. In the original template they would have all pointed to the same thing. Therefore when putimage assigned an object number to an image, it would only assign it to a single object.

I want to find a way of referencing other objects when I am gob encoding, though that might take some time and thought... so if anyone really needs this for the time being, like myself, this will kind of do.

Sorry for the word vomit, I am about to leave work.

Edit: I should also add some tests.

[d1ngd0]

So now it saves the images at the leaf nodes within the tree and then the encoding process knows if it should reference the child's image or not. This fixes the pointer issue described above, as well as having the added benefit of a smaller byte string. I also added a Serialize and DeserializeTemplate function for ease of use.

I have changed the Template interface some, however I question if anyone has ever implemented the template outside of the package considering it requires the user to create an ImageTypeInfo object which is comprised of all un-exported fields, so I think the risk or breaking someones Custom Template is low if not none.

[jung-kurt]

Very good -- I'll look this all over soon.

[jung-kurt]

Very nice work, @d1ngd0! I tweaked some comments and the placement of the decoded templates in the test function.

Please let me know if you would like the acknowledgment in doc.go (landing page) changed to reflect your name.

[d1ngd0]

I wouldn't mind it I guess. But if it's more than a 5 second deal don't worry about it. Thanks for pulling

[jung-kurt]

Currently I've got "d1ngd0" there. Are you OK if I replace that with "Paul Montag"?

[d1ngd0]

Oh sure