Skip to content

Conversation

@keeguon
Copy link

@keeguon keeguon commented Nov 29, 2013

I'm trying to make this gem as cross platform as possible so I decided to switch to Hoe to create the gems since it's not really stable yet and I don't want people using it directly.

In this PR I implemented Pdf417 in MRI using the C lib.

Just FYI, next up on the todo list is to be able to generate DataMatrix barcodes in Java either by removing the semacode dependency or porting semacode in Java.

@toretore
Copy link
Owner

I like it, but I'm trying to make Barby leaner in terms of including third party code.. Would it be much trouble to make it a separate gem and then use that from Barby? The only real requirement is that it could generate the "squares" in a format which Barby can understand..

Regarding DataMatrix; If there's already a lib for Java to do that we should probably use it. I'm not sure exactly how to best handle loading different dependencies depending on the environment. Right now the files have require statements in them, but we could just remove those and let the user require whichever one they want to use. Either way, the alternatives must be coded for explicitly..

@keeguon
Copy link
Author

keeguon commented Nov 29, 2013

The thing is that using Hoe you can generate two separate gems for each environment and then submit them to RubyGems in fact that's what Nokogiri does and where I got the inspiration to the Hoe based Rakefile. I could do a separate Gem but since you had already written the Pdf417 class I basically wrote the C extension to match the Java bindings which simplifies things and basically installs the C dependencies if you're using MRI and if you're using jRuby it loads the Java class as it used to do. However if you really wish me to do something separate, do you have suggestions on how you want me to handle it...?

Regarding DataMatrix, I've looked around but nothing is as simple as semacode and I looked at the C code in semacode it's simple enough, in that spirit I could probably do a cross-platform semacode gem by rewriting the C code in Java, still not decided though, will think about it over the week-end and I'll get back to you.

@toretore
Copy link
Owner

Yeah, I'd like to move all 3rd party code out of Barby and into gems eventually. The idea of cross-platform datamatrix and pdf417 gems is a good one, I think. Whether it should be two different gems for each type or one for each that does some env checking I'm not sure about.. Personally I don't love the idea of env checks, but if it's contained inside the gem I guess it's ok, and it would be up to the author (you) anyway.. The reasons I haven't done these things myself is I haven't had the time and I don't know much Java or C..

My goal is to keep Barby as simple as possible and not make it a big ball of dependencies that can't be managed independently. As to how Barby will choose which library to use for a symbology, I see two main choices:

  1. Have Barby require the dependency explicitly, but also doing the checks to see which one to require.
  2. Have the user require the library they want Barby to use and remove all require statements. This would still have to know about different class names with different interfaces, but that's not avoidable.

Note that this is only for those files relying on already existing outside dependencies; there are some symbologies that are implemented directly inside Barby (in ruby) and I don't intend to change those.

On Nov 29, 2013, at 18:19, Félix Bellanger wrote:

The thing is that using Hoe you can generate two separate gems for each environment and then submit them to RubyGems in fact that's what Nokogiri does and where I got the inspiration to the Hoe based Rakefile. I could do a separate Gem but since you had already written the Pdf417 class I basically wrote the C extension to match the Java bindings which simplifies things and basically installs the C dependencies if you're using MRI and if you're using jRuby it loads the Java class as it used to do. However if you really wish me to do something separate, do you have suggestions on how you want me to handle it...?

Regarding DataMatrix, I've looked around but nothing is as simple as semacode and I looked at the C code in semacode it's simple enough, in that spirit I could probably do a cross-platform semacode gem by rewriting the C code in Java, still not decided though, will think about it over the week-end and I'll get back to you.


Reply to this email directly or view it on GitHub.

@keeguon
Copy link
Author

keeguon commented Nov 29, 2013

Oh okay I see what you want to do. You want to do some kind of an OmniAuth but for barcodes so I guess, I'll do a separate gem that can integrate w/ barby and all you'll have to do is remove your Pdf417 class since the gem will provide it for you ;).

@keeguon
Copy link
Author

keeguon commented Dec 2, 2013

Okay, so I here's what I did I completely remove the Pdf417 from Barby and created a cross-platform gem called "barby-pdf417" that you can find here: https://rubygems.org/gems/barby-pdf417 which contains the support for Pdf417 and the dependency for both MRI/jRuby, you can see the code here: https://github.com/Keeguon/barby-pdf417. I'm willing to do the same for DataMatrix if that suits you.

@toretore
Copy link
Owner

toretore commented Dec 3, 2013

This looks good. I've been playing around with it, and I like it. I noticed there's already a "pdf417" gem, and I think it's be silly if there was another, very similar one, so I've sent them a message [2] to see if they're interested in merging the two.. It's exactly the same C library, so the merge would be adding the Java bits to their gem.. What do you think?

[1] asee/pdf417#2

@natematykiewicz
Copy link

Is there any update on this? I'd like to generate PDF417 barcodes using Ruby 2.3, and I'd prefer to just use Barby, since that's what I use for the other formats I support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants