301
OD/WEK & JAVA API / Re: What is your AFP to PDF Transform of choice?
« on: January 22, 2019, 10:05:10 AM »
3 Scenarios I've seen. The last one appears to be the most common and plainless
1) Transforming from AFP to PDF, storing as PDF (We didn't care about storage sizes..)
Transforming Xerox to AFP via Infoprint XT, then AFP2PDF (We tried this with both the C version and Java version of AFP2PDF, similar results...Slow)
AFP2PDF to transform HP Exstreme AFP files to PDF (painless and quick)
PCL2PDF to transform PCL to PDF, then it used the CMOD PDF Indexer (painless and quick)
The indexing tool that we used to index the AFP files, was pretty slick and simple to use, and with the support we had from Ricoh they were able to build us custom filters, it supported regular expressions, etc. This was Ricohs AVE (AFP Visual Environment?)
The integration to our custom loaders and CMOD was a long drawn out process, but it worked. Indexing new reports became easier, but it took significantly longer to load very large xerox files.
2) Transforming from AFP/Xerox/PCL to PDF, storing as PDF.
We used Xenos 5.6 for this. This is an extremely outdated version from what I remember, but it worked and it was extremely fast as far as indexing. The d2e studio was very complex, and it was the most expensive option. I believe a lot has changed since then though.
3) Loading AFP files, converting on the fly with afp2pdf/ODWEK
Currently using the C++ version of afp2pdf on solaris to convert natively loaded AFP files mostly from exstream upon retrieval. Zero issues. We can also customize fonts and things via the out of the box configuration files provided by Ricoh.
1) Transforming from AFP to PDF, storing as PDF (We didn't care about storage sizes..)
Transforming Xerox to AFP via Infoprint XT, then AFP2PDF (We tried this with both the C version and Java version of AFP2PDF, similar results...Slow)
AFP2PDF to transform HP Exstreme AFP files to PDF (painless and quick)
PCL2PDF to transform PCL to PDF, then it used the CMOD PDF Indexer (painless and quick)
The indexing tool that we used to index the AFP files, was pretty slick and simple to use, and with the support we had from Ricoh they were able to build us custom filters, it supported regular expressions, etc. This was Ricohs AVE (AFP Visual Environment?)
The integration to our custom loaders and CMOD was a long drawn out process, but it worked. Indexing new reports became easier, but it took significantly longer to load very large xerox files.
2) Transforming from AFP/Xerox/PCL to PDF, storing as PDF.
We used Xenos 5.6 for this. This is an extremely outdated version from what I remember, but it worked and it was extremely fast as far as indexing. The d2e studio was very complex, and it was the most expensive option. I believe a lot has changed since then though.
3) Loading AFP files, converting on the fly with afp2pdf/ODWEK
Currently using the C++ version of afp2pdf on solaris to convert natively loaded AFP files mostly from exstream upon retrieval. Zero issues. We can also customize fonts and things via the out of the box configuration files provided by Ricoh.