USPS Intelligent Mail barcode packing function?

[Brian K. White]

----- Original Message ----- 
From: "Jay R. Ashworth" <jra at baylink.com>
To: <filepro-list at lists.celestial.com>
Sent: Wednesday, September 05, 2007 8:49 AM
Subject: Re: USPS Intelligent Mail barcode packing function?


> On Wed, Sep 05, 2007 at 02:43:27AM -0700, Bob Rasmussen wrote:
>> > So, before I go off and write the code myself, has anyone *else*
>> > already written the filePro code that maps the collection of 31 max
>> > digits into 65 max barcode bars (full, ascender, tracker, descender)?
>>
>> It would be a logical extension of Print Wizard for us to add an IM
>> barcode generator, to complement our 15 other styles. This would give you
>> a solution that would work on any printer, and be easy to use via
>> printcodes.
>>
>> We evaluate features like this on a strictly mercenary basis :-)  If 
>> you'd
>> like to discuss this, please contact me off-list.
>
> I'll warn you: the packing algorithm's a *bear*.  :-)
>
> But, as you know, being a 20 year Unix hand, I'm loathe to install
> anything that makes Unix machines depend on Windows ones.

I installed both facetwin client and Anzio (lite or win don't remember) a 
couple months ago in wine and have tried a few other things here & there. A 
surprising number of things work pretty well.

And by install I mean simply: "wine setup.exe"
It created a C drive under ~/.wine and even made a working icon on the 
desktop.
Didn't need any copy of windows or dll's like the wine of old. I think it 
uses ReactOS for a lot of what it used to require windows for. Anzio and 
facetwin were both quite slow for terminal emulators in this environment, 
but for other stuff that might be less important or less true since maybe 
the slowness was a result of the particular job they are doing (rendering 
text to a fine degree of control). Maybe not all apps run into as bad a 
performance penalty. This was on a 1ghz low power celeron diskless thin 
client too so it might not be noticeable of a faster machine.

I think it's at least worth a shot seeing if printwizard can work this way, 
since I too reject relying on  any pc or win box as a necessary part of "the 
system" other than as the end user client, and I don't like requiring any 
special setup there even. But, printwizard sure would be nice some times...
I think I'll try this out just to see what happens. There's other options 
too like putting a reactos image in a qemu or xen or vmware. I say reactos 
instead of windows and image instead of install because the end result needs 
to be solid, which imo is not possible, or quickly reproduceable to make up 
for the fact that it can't be counted on to stay good.

What I means is, putting a regular windows install in a virtual machine, and 
then having that install go south from any of the various reasons windows 
installs go south, is hardly any different than just using a regular pc. But 
if you could set up a good working installation and then make a nice image 
that that you can copy and restore from at will, (maybe have it unpack fresh 
with every reboot, or every start/stop of a service, or maybe have it run as 
a read-only image with a seperate temp dir, etc...) not to mention 
distribute and install on new boxes at will, that would make up the 
difference pretty well. Thus the image. Windows licencing pretty much 
precludes using real windows for that, thus reactos.

Another idea, go ahead and use a pc, but make a bartpe or ubcd4win cd that 
has the necessary printwizard install files. The hardware of the pc can die, 
the running environment can go south, but the cd is impervious so all 
problems are a reboot away. Not hugely different than needing to power-cycle 
a print server or router.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!