Is there any python library to generate ean128 barcode. I tried 'python-barcode' , but in that library there is no option for ean128.
The person who originally asked this question may not benefit from this, but this is for those who are still looking for an answer.
Note: Code-128 is not same as GS1-128
I was also stuck with this issue a few days ago, and I finally managed to find a python library which supports the GS1-128(UCC/EAN-128) barcode.
The library I am referring to is called "treepoem". Strange name I agree that's what makes it so hard to find. It is a wrapper for BWIPP library. And it has a dependency on ghostscript as well. About the name; Barcode -> Bark ode -> Tree poem.
Important links:
1) Ghostscript; download and install it and also add its "bin" and "lib" folder to
system's path variable.
https://www.ghostscript.com/download/gsdnld.html
2)treepoem
https://pypi.org/project/treepoem/
3) All-codes; here in the repository you will find all supported barcodes here.
https://github.com/adamchainz/treepoem/blob/master/treepoem/data.py
import treepoem
image = treepoem.generate_barcode(
barcode_type='gs1-128', # One of the BWIPP supported codes.
data='(01)14-digit-product-code')
image.convert('1').save('barcode.png')
I think that EAN 128 is the same thing as Code 128 (https://en.wikipedia.org/wiki/Code_128). It seems to be supported by python-barcode
There is an alternative lib with code 128
Related
I am trying to install a C++ library called FastAD ( https://github.com/JamesYang007/FastAD#user-guide) in Rcpp but the installation instructions are generic (not specifically for Rcpp).
It would be greatly appreciated if someone coule give me some guidance for how to install and be able to #include the files?
FastAD is a header-only library which only depends on Eigen3. That makes for a pretty straightforward application for Rcpp and friends.
First, rely on the RcppEigen.package.skeleton() function to create the barebones RcppEigen-using package.
Second, we copy the FastAD library into inst/include. We add a PKG_CPPFLAGS variable in src/Makevars to let R know to source it from there. That is all the compiler needs with a header-only library. (Edit: We also set CXX_STD=CXX17 unless one has a new enough compiler or R (currently: r-devel) which already default to C++17.)
Third, we create a simple example in src/ based on an example in FastAD. We picked the Black-Scholes example.
Fourth, minor cleanups like removing the hello* stanza files.
That is pretty much it. In its embryonic form the package is now here on GitHub. An example is
> library(RcppFastAD)
> blackScholesExamples()
56.5136
0.773818
51.4109
-0.226182
>
Does anyone knows a good Python library to parse MSDOS files and obtain metadata and start()'s bytecodes? Like an alternative version of pefile library but for MSDOS? I can't seems to find any via Google.
If there isn't, is there a good source to refer to on MSDOS's file format? This way, I can create my own parser instead. I know there are tools like IDA Pro and Reko decompiler but I need a MSDOS file parser to automate some stuff. Thank you in advanced!
Reko decompiler maintainer here. For what it's worth, you can use Reko's MS-DOS source code and translate it to Python. It's not a lot of code and MS-DOS executables aren't that complex to parse -- it's quite a simple format. The relevant files are:
https://github.com/uxmal/reko/blob/master/src/ImageLoaders/MzExe/ExeImageLoader.cs
https://github.com/uxmal/reko/blob/master/src/ImageLoaders/MzExe/MsdosImageLoader.cs
You could also try executing the Reko code directly from Python. The Reko binaries are available as a nuget package: https://www.nuget.org/packages/Reko.Decompiler.Runtime
Use the class Reko.ImageLoaders.MzExe.ExeImageLoader in the Reko.ImageLoaders.MzExe class. Integration could be done with http://pythonnet.github.io/
I created a simple hierarchial C++ project to help me learn the use of scons as I want to get away from cmake and qmake. I have registered it in a github repository at https://github.com/pleopard777/SConsEx . This project is organized into two primary subdirs; packages contains two libraries and testing contains two apps. The packages dir needs to be built first and when complete the testing dir needs to be built. Under the packages library the core library must be compiled first and the numerics library second. The numerics library depends on the core library. Under the testing dir the core_tests app depends on the core library and the numerics_tests app depends on core and numerics.
I am struggling with what seems to be limited documentation and examples for scons so I am posting this here in search of some guidance. Here are some of the initial problems I am having, any guidance will be greatly appreciated:
1) [Edit/FIXED]
2) In the packages/numerics/ dir the source files depend on the core library. The file numerics_config.h requires the file ../core/core_config.h however when building that core file cannot be found. The following SConstruct lines don't help:
[code]
include = '../../packages'
env = Environment(CPPPATH=include)
[/code]
Again, this is just a start to the project and I am using it to learn scons. Any guidance will be appreciated ... I'm sure I will be asking lots more questions as this project progresses.
Thanks!
P
Fixed in pull request to your repo.
Note you had some c++ issues as well. I've fixed them too.
See:
https://github.com/pleopard777/SConsEx/pull/1
(Please don't delete your repo so others can find the solution as well)
I've looked around (including StackOverflow), but the only question close to mine, as far as I can tell, is specific to Windows distributables, which doesn't apply to me.
I want to release a library: MyLibrary.lib
It uses some third-party libraries, for instance, ZMQ
I've included the third-party library into MyLibrary both with either #pragma or actually adding it to the project.
Either way, MyLibrary.lib compiles fine and creates a .lib file
HOWEVER.
An executable that is linked to MyLibrary complains at link time that it can't find the referenced ZMQ functions, as if ZMQ is not incorporated into MyLibrary.
Looking at MyLibrary with a hex editor it doesn't seem like ZMQ.LIB was incorporated. There are references to it but it seems "weak linked". I don't see the ZMQ code in there.
Alternatively, if I can get the application/executable to build and run it, it'll complain at runtime that it can't find zmq.dll.
Either way, it's obviously not in "MyLibrary".
How can I get a library to include other third-party libraries, so I don't have to distribute a bunch individually? What step am I missing?
Using MSVC2013
Thanks
Although I had the .lib I needed, it turns out it was an import lib, and the .dll was distributed elsewhere. I found the .dll and now it works. Thanks to all who responded.
What about the flags described in this article:
https://msdn.microsoft.com/en-US/library/2kzt1wy3%28v=vs.120%29.aspx
Can they help you?
I'm trying to use the new OpenCV 2.0 API in MS Visual C++ 2008 and wrote this simple program:
cv::Mat img1 = cv::imread("image.jpg",1);
cv::namedWindow("My Window", CV_WINDOW_AUTOSIZE);
cv::imshow("My Window", img1);
Visual Studio returnes an unhandled exception and the Console returns:
OpenCV Error: bad flag (parameter or structure field)
(Unrecognized or unsupported array type) in unknown function,
file ..\..\..\..\ocv\opencv\src\cxcore\cxarray.cpp, line 2376
The image is not displayed. Furthermore the window "My Window" has a strange caption: "ÌÌÌÌMy Window", which is not dependent on the name.
The "old" C API using commands like cvLoadImage, cvNamedWindow or cvShowImage works without any problem for the same image file. I tried a lot of different stuff without success.
I appreciate any help here.
Konrad
As I just commented, imread isn't working for me either. A little googling shows other people having the same problem; I guess it's a bug in the library code. For now, here's a hacky workaround:
IplImage* img = cvLoadImage("lena.jpg");
cv::Mat lena(img);
cvReleaseImage(&img);
This way, you can at least use the C++ API for the rest of your stuff.
There's help for this issue.
The solution is, that the usual proposed opencv library files in the linker are not working properly. Instead try to use the debug library files by this:
In Visual C++:
go to Project->Properties (or Alt-F7)
Configuration Properties->Linker->Input->Additional Dependencies
replace the usual
" cv210.lib cxcore210.lib highgui210.lib" by
" cv210d.lib cxcore210d.lib highgui210d.lib" - which are the debugging libraries.
The OpenCv 2.0 API commands should work now.
I had the same problem described above which turns out to be caused by the settings of the linker.
I found the answer in another thread,
OpenCV 2.3 and Visual Studio 2010.
To repeat it here:
Properties of your project (right click on it)
C/C++
General
include directory add the < your directory >\OpenCV2.3\include\opencv2, < your directory >\OpenCV2.3\include\opencv and < your directory >\OpenCV2.3\include
Linker
General
List item
Input
Add all the libs like opencv_core230d.lib opencv_highgui230d.lib and so on...
Once I've done the above, I can run imshow and imread + all other cpp functions seamlessly! OP's problem has probably already been resolved, but hopefully this will be useful to other people who are led here looking for the same solution.
Are you sure you added the whole path starting from /home/.... I had the same problem as you but when I added the whole path, things work out pretty well. The whole path had to be added despite the fact the path exists in the include files.
imread in openCV unlike Matlab does not return an error when file/folder is not found - instead it returns a null matrix, which in turn is reflected as an error during imshow.
Also, imread does not look for image files in the included folders or the workspace. So, specify the entire path whenever possible.
Please take a note of this for future references.
Firstly, you'd better compile your own version OpenCV.
I had the same error with the build (I got from Sourceforge), and solved by compiling my own version in debug and release versions.
And make sure you change the original system env variable PATH to the new build folder build/bin, then you could build and run the imshow() in Debug mode.
I believe this might be related to unicode.
Try the macro _TEXT()
For example:
cv::Mat img1 = cv::imread(_TEXT("image.jpg"),1);
Unicode in Visual C++ 2