[barcode] proposed code change

[Ciaran Mac Lochlainn]

Hi Alessandro,

I've got a first version of the change working - it's more of a hack than a
patch as you describe it!  I haven't debugged the PostScript output fully
yet, but PCL is working (I'm testing with a HP LaserJet 4 that doesn't
support PS!)

I made a few changes to the spec that I outlined a few days ago.  It now
also reads in the price from the input file, and if the description to be
printed is longer than 18 characters (hardcoded) it will split it into two
or three lines.  I've written a function to encode spaces as underscores,
and to replace PS special characters with 'similar' ones ('\' replaced with
'/' etc), and a function to convert underscores back to spaces before the
text is printed.  I also included a function written a few years ago here at
Merit to split a long line of text into shorter lines.

I haven't paid much attention to margins, bounding or user control over text
placement, as I was mainly aiming to get the software to do one layout in
particular!

I had to put in a workaround to test 12 digit codes for UPC compliance
_before_ EAN as at the moment it was adding an EAN-13 check digit to codes
that should have been printed as UPC.  Now if a code has 12 digits the
software will test UPC first and if that doesn't work it will go through the
normal process and treat it as EAN-13.

Things I don't like about how I've done it...

-Input is comma delimited, maybe tagged would be better?
-Input parser should ignore spaces after the commas
-Font sizes and number of chars per line of text are hardcoded (in
library.c)
-pcl.c doesn't use font size passed to it to manage placement
-Text placement should really be user definable
-Margins may need a look
-Should maybe use a command line option or environment variable to switch
changes on/off
-PS & EPS output are not finished

Since it does what Merit wants it to do for now, I'll probably take a break
from it for a while.  In the meantime, can I mail/ftp the source diffs
somewhere?  The changes are based on 0.98, not the current snapshot.

Ciaran

----- Original Message -----
From: "Alessandro Rubini" <rubini@gnu.org>
To: <ciaran@meritsolutions.ie>; <barcode@lists.linux.it>
Cc: <rob@wordstock.com>
Sent: Friday, August 16, 2002 8:15 AM
Subject: Re: [barcode] proposed code change


>
> Hi. Thanks for your message.
>
> Actually, the idea of adding text labels is pretty old. I received a patch
> by Rob Seace in March 2000. He modified the input format in this way:
>
>   <BC>:1111111111
>   BOGUS TITLE ONE
>   Our Price: $11.11
>   Bogus Bookstores, Inc.
>   <BC>:2222222222
>   BOGUS TITLE TWO
>   Our Price: $22.22
>   Bogus Bookstores, Inc.
>
> He only changed the cmdline frontend, not the backend. I didn't integrate
> the patch mainly for the same reasons I detail below. Plus, it's not
compatible
> with current behaviour and making it compatible is boring.
>
> > When the barcode program reads input from a file or from stdin, if that
> > input is comma delimited and the part before the comma is a valid EAN-8,
> > EAN-13 or UPC code, the part after the comma will be treated as "extra
text"
> > to be printed in ASCII.
>
> I like this, as it is compatible, but there are drawbacks. I list
> them one-paragraph-each.
>
> Some encodings (although not the UPC/EAN sets) can use the
> comma. Actually, all 7-bit ASCII symbols can be encoded so we can't
> choose a separator that always works (short of going to 8-bit codes,
> but these may be hairy to represent and their meaning varies according
> to localization.  Otherwise, a rob-seace-like approach may be better,
using
> the "<" as a sign that this is tagged input. A literal less-than can be
> escaped as "\<"; missing the "<" at start-of-input, the old behaviour is
used.
>
> If text is included in the output, there should be some control on it.
Where
> is it located, what font and what size. Missing that, the thing is more
> like a hack than a serious tool. While you make a good suggestion for
> the internal representation (using textinfo), the external one must be
defined.
> Similarly, more than one string must be allowed (Rob Seace needed two), so
> probably a more structured item should be better.
>
> The official GNU barcode now supports PCL output, so things should be
> ported to PCL as well (Andrea Scopece: that's homeworks for you :).
>
> Using EPS as output format requires the bounding-box to be known. This
> is not a difficult problem to solve, but still it's something more to
> consider. Actually, EPS is included exactly to ease adding custom text
> to the output.
>
>
> > Let me know if there's anything else you think I should do (e.g. only
> > activating the above code with an environment variable or a command line
> > option) or if you think this implementation won't fit in with what
you're
> > doing - obviously I'd like if my changes could be merged into some
future
> > version.
>
> Activating by command-line is fine, although being this an interesting
> feature it could well be in by default (provided it doesn't turn out
> too incompatible).  However, I still think using an external script
> (perl or whatever) might be best. Or even a different frontend
> altogether.  I'd see this tool as a postscript-only tool that doesn't
> touch the internals of the library and uses libbarcode (or the barcode
> frontend) to generate barcodes, while doing by itself when text is
> needed. Being a different tool, we don't need to offer EPS and PCL as
> additional outputs. Being different, it can use its own input format
> (I'd use tagged, as it's extensible, *ml-like or whatever). If it's
> interpreted, it can even be lazy in the amount of external
> configuration and documentation, provided the code has all
> customization concentrated at the head and well commented.
>
> I'd be happy to have such a tool in the distribution. Although, actually,
> it's only slightly easier than writing postscript directly.
>
> foobar: Fancy Output Organizer with BAR codes.
>
> /alessandro
>