Completed adding support for extensive list of 1D and 2D barcodes to the Free DocxFactory Project

joey.jeremiah

ProgressTalk Moderator
Staff member
Hello All,

Just completed adding support for an extensive list of 1D and 2D barcodes to the Free DocxFactory Project.

Supported barcodes -

1D Barcodes
Code 11
Code 2 of 5 Standard
Code 2 of 5 IATA
Code 2 of 5 Interleaved
Code 2 of 5 Data Logic
Code 2 of 5 Industrial
ITF-14
Code 3 of 9 (Code 39)
Extended Code 3 of 9 (Code 39+)
Code 93
PZN
LOGMARS
Code 32
Code 128 (automatic subset switching)
Code 128 (Subset B)
GS1-128 (UCC.EAN-128)
EAN-14
NVE-18
UPC A
UPC E
EAN (2, 5, 8, 13)
ISBN (EAN-13 with verification stage)
Codabar
Pharmacode
Pharmacode Two-Track
Plessey Code
MSI Plessey
Telepen Alpha
Telepen Numeric
GS1 DataBar-14
GS1 DataBar-14 Stacked
GS1 DataBar-14 Stacked Omnidirectional
GS1 DataBar Limited
GS1 DataBar Extended
GS1 DataBar Expanded Stacked
Channel Code
FIM
Flattermarken
DAFT Code
PostNet
PLANET
USPS OneCode
Royal Mail 4 State (RM4SCC)
Deutshe Post Leitcode
Deutshe Post Identcode
Australia Post Standard Customer
Australia Post Reply Paid
Australia Post Routing
Australia Post Redirection
Dutch Post KIX Code
Japanese Postal Code
Korea Post
2D Barcodes
Code 16K
Code 49
PDF417
PDF417 Truncated
MicroPDF417
Data Matrix
QR Code
Micro QR Code
Maxicode
Aztec Code
Aztec Runes
Code One
Grid Matrix
HIBC Version Barcodes
HIBC Code 39
HIBC Code 128
HIBC PDF417
HIBC MicroPDF417
HIBC Data Matrix
HIBC QR Code
HIBC Aztec Code
Composite Barcodes
Composite Symbol with EAN linear component
Composite Symbol with GS1-128 linear component
Composite Symbol with UPC A linear component
Composite Symbol with UPC E linear component
Composite Symbol with Databar-14 linear component
Composite Symbol with Databar-14 Stacked component
Composite Symbol with Databar-14 Stacked Omnidirectional component
Composite Symbol with Databar Limited component
Composite Symbol with Databar Extended component
Composite Symbol with Databar Exp Stacked component

Screen shots -

screenshot_barcode1.png


screenshot_barcode2.png
 
Last edited:

Chris Kelleher

Administrator
Staff member
This is truly an awesome library! I was able to get this working on 11.3 64-bit Windows, and was able to replace a 2kLOC program which manipulated RTF files with just a few lines of code!

I am now trying to get this to work on Red Hat Linux (32-bit), and am getting the following errors:

Code:
Could not open Dynamic Library: DocxFactoryC.so (8013)
DLL Error : DocxFactoryC.so: cannot open shared object file: No such file or directory (8014)
Could not load DLL procedure DocxFactoryC.so. (3258)

I followed the instructions in the documentation, but am now at a loss at what to try next to get this working. Anyone have any ideas?

Thanks,
Chris
 

joey.jeremiah

ProgressTalk Moderator
Staff member
Hello Chris,

Thank you for your kind words and thank you for using the Project! :)

I will test and fix the problem straight away but before I start are you sure you're using the latest version (I uploaded a new version on the 20th of July)?


Can you please also try the following -

1. First, please make sure the environment variable LD_LIBRARY_PATH is set.

2. In the slibdocxprop.i can you please change the 'DocxFactoryC.so' to it's full path and recompile.


Thank you,
Alon
 

Chris Kelleher

Administrator
Staff member
Hi Alon,

Thanks! Yes, I did just download the latest versions, and I have LD_LIBRARY_PATH set. I put the full path into slibdocxprop.i, which gave me some more information:

Code:
Could not open Dynamic Library: /opt/DocxFactory/lib/DocxFactoryC.so (8013)
DLL Error : /opt/DocxFactory/lib/DocxFactoryC.so: requires glibc 2.5 or later dynamic linker (8014)
Could not load DLL procedure /opt/DocxFactory/lib/DocxFactoryC.so. (3258)

I am just finding out that this server is running a pretty old version of RHEL. Will get the update glib libraries installed and try again.

Thanks,
Chris
 

joey.jeremiah

ProgressTalk Moderator
Staff member
Thank you for finding the problem for me :)


In C/C++ on UNIX/Linux the LD_LIBRARY_PATH environment variable (or ldconfig) is used to search for libraries and PATH is used to search for executables.

On Windows the PATH is used to search for everything, both executables and libraries.


I'd rather not hard code the library's full path.

Maybe Progress uses PATH to search for external libraries on UNIX/Linux as well?


Can you test one more thing for me -

1. Change the slibdocxprop.i back and recompile.

2. Add the /opt/DocxFactory/lib to the PATH and try again.

Can it find the DocxFactoryC.so library now?


Thank you,
Alon
 
Last edited:

joey.jeremiah

ProgressTalk Moderator
Staff member
... Will get the update glib libraries installed and try again.


I doubt you can update glibc.

You would probably also need to update a million other libraries.

It might be the library that has the most dependencies on the whole machine.


I believe, glibc 2.5 was released 2006.

I think, you might have to upgrade to a more modern version of your operating system.


Another option is I could compile the project on an old, 10 year old, version of Linux.

Let me know if that's your only option and I'll see what I can do.
 

Chris Kelleher

Administrator
Staff member
I doubt you can update glibc.

You would probably also need to update a million other libraries.

Yes after doing a bit of research I realized that. There is an option of installing just the updated glibc libraries into another directory and using LD_LIBRARY_PATH to point to those.

But first I am going to see if we have another server that I can use that has a more modern version of Linux on it, I believe we may.
 

joey.jeremiah

ProgressTalk Moderator
Staff member
There is an option of installing just the updated glibc libraries into another directory and using LD_LIBRARY_PATH to point to those.

IMHO I doubt that also

because glibc probably also depends/uses alot of other libraries and you would need to update/install them as well

plus glibc is *very* low level and probably alot of the operating system processes probably even the kernel depend on it and I don't know what effect it will have or if it will break the operating system.

I don't even think it's possible to rpm to a different directory.


What version of RHEL are you using? Maybe I should consider compiling on an older version.

Thank you for your help :)
 
Last edited:

joey.jeremiah

ProgressTalk Moderator
Staff member
Great! Thank you very much! :)

Can you please test one more thing? -

1. Change the slibdocxprop.i back and recompile.

2. Add the /opt/DocxFactory/lib to the PATH and try again.

Can it find the DocxFactoryC.so library now?

Thanks,
Alon
 

Chris Kelleher

Administrator
Staff member
Can you please test one more thing? -

1. Change the slibdocxprop.i back and recompile.

2. Add the /opt/DocxFactory/lib to the PATH and try again.

Can it find the DocxFactoryC.so library now?

Yup, it works perfectly without the hard-coded path in slibdocxprop.i as long as /opt/DocxFactory/lib/ is added into the PATH.
 
Top