raw_base64 type

[phyzalis]

Hi,

I was trying to use PrintNode::Client create_printjob with a "raw_base64" content_type.
As written in PrintNode API, I was trying to pass my base64 encoded content through a PrintNode::PrintJob instance but I was getting:

Errno::ENOENT: No such file or directory @ rb_sysopen - G0AbYTEdIQBUSEFOSyBZT1UKRk9SIFRSWUlORwodVkIA
from /Users/suzukiasuka/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/printnode-1.0.5/lib/printnode/printjob.rb:20:in `read'
from /Users/suzukiasuka/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/printnode-1.0.5/lib/printnode/printjob.rb:20:in `to_hash'
from /Users/suzukiasuka/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/printnode-1.0.5/lib/printnode/client.rb:441:in `create_printjob'

I was surprised to look into the code and see that content seems to have to be a file name when content is a "raw_base64" content_type. Is there a reason why we have to use a file? Isn't it reducing speed by having to create then remove a file?

For now I am going to fork my own version and remove that but could you tell me more about this, if you plan to add something else or not after? If you don't plan to do anything about this (like adding another content_type), maybe you should add something in the documentation about that.

Thank you so much

[PrintNodeJames]

Hi phyzalis,

Thanks for the detail and the issue. To answer your questions.

Is there a reason why we have to use a file?

No reason for this that I'm aware of. Before this summer our team didn't have any ruby experience. A ruby client was popularly requested and we were keen to learn so we had a go. It's entirely possible this is error cause by our ruby inexperience.

Isn't it reducing speed by having to create then remove a file?

That would make sense and it's something we definitely should remove.

The content types we currently support are 'pdf_uri', 'pdf_base64', 'raw_uri', 'raw_base64'. We'll probably add more in the future as we support more document formats. From a HTTP API design perspective it was a mistake to mix the printjob contentType (e.g. pdf, raw) and contentEncoding (e.g. base64, uri) into one field. So we might address that somehow.

If you'd like to submit any pull requests with improvements or modifications we'd be delighted to roll these back into this lib and credit your account with free credit.

Let me know if you have any other questions.

[phyzalis]

Thank you for your prompt support.
If you don't have a lot of ruby users yet, let me tell you that your ruby client is doing the job very well

I will submit you a pull request soon but maybe some users are using this project this way so it might brake their usage.

We will discuss about this later during my pull request

[rjocoleman]

Late reply but I submitted a PR in September last year for this same issue: #3 (it's had no response)

I have been using my branch in production with base64 encoded strings for tens of thousands of print jobs with no issue.

[aaronflorey]

I've just run into the same issue, and came across this. Now using your repo thanks @rjocoleman

[irongaze]

Bump on this! PrintNode is a fantastic service. We're using it to implement print-from-web support in our warehouse automation software. The current implementation of base64 printing is broken for that use-case, as our labels are being generated by FedEx and UPS as Base64 streams of ZPL, and to make PrintNode printing work we need to decode & write a temporary file, that then gets read and re-encoded. Ugh. This is a super-common reason for using a web-based printing solution, and I won't be the last customer who runs into this issue.

[irongaze]

Just add a PR to address this in a manner similar to @rjocoleman's approach, but providing for backwards compatibility with existing installs. Hope that helps someone! Would appreciate someone from PrintNode approving one of these PR's asap. Cheers!

[PrintNodeJames]

Hi,

Thanks irongaze. Sorry for delay in merging in the changes. If you make other improvements then we would be really happy to merge them in.

Thanks,

James

[irongaze]

Thanks for merging the PR, James! Any chance you guys could push a new gem version to RubyGems.org so I can use the official gem instead of my fork?

[kwent]

I think this can be closed ?

[rjocoleman]

This issue may be fixed in master but there hasn’t been a release that incorporates this.

So current best practice is to use github as the gem source.

[kwent]

Best practice is to cut a release and publish to rubygems. Cf. #11. Been almost a year since master has been updated.