Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Bar Code Labeling Software
4 views
Skip to first unread message
Ivan Shmakov
May 11, 2013, 2:18:01 PM5/11/13
to
>>>>> Andrew Smallshaw <and...@sdf.lonestar.org> writes:
[Cross-posting to news:alt.barcodes.]
[...]
> I've only had an occasional use for that and I've always found a
> suitable web-based generator to paste in from, e. g.
> http://www.terryburton.co.uk/barcodewriter/generator/. That seems to
> be among the better online options in that it has a wide choice of
> formats and the option of EPS output - I'm not overly inclined to
> trust low res bitmaps for something like this.
Even given that the majority of barcodes (and non-bar codes,
such as the QR code) are essentially raster? (Well, except the
alphanumeric label, if any.)
> Formatted printed output from programs generally means PostScript in
> any event (for a Unix shop at least ;-) ), so inserting a barcode
> generation function in the header and then calling it with the right
> options later is no big hassle.
Yet, I cannot refrain from reminding that PostScript is /not/ a
format, but a fully-featured programming language (which has
certain implications on its own.) Surely, I'd prefer to handle
a format which I can parse, instead of one I have to /execute/.
(Generally, that'd mean either PDF or SVG, although the support
for either seem to be falling behind that for PostScript.)
[...]
--
FSF associate member #7257
[Cross-posting to news:alt.barcodes.]
[...]
> I've only had an occasional use for that and I've always found a
> suitable web-based generator to paste in from, e. g.
> http://www.terryburton.co.uk/barcodewriter/generator/. That seems to
> be among the better online options in that it has a wide choice of
> formats and the option of EPS output - I'm not overly inclined to
> trust low res bitmaps for something like this.
Even given that the majority of barcodes (and non-bar codes,
such as the QR code) are essentially raster? (Well, except the
alphanumeric label, if any.)
> Formatted printed output from programs generally means PostScript in
> any event (for a Unix shop at least ;-) ), so inserting a barcode
> generation function in the header and then calling it with the right
> options later is no big hassle.
Yet, I cannot refrain from reminding that PostScript is /not/ a
format, but a fully-featured programming language (which has
certain implications on its own.) Surely, I'd prefer to handle
a format which I can parse, instead of one I have to /execute/.
(Generally, that'd mean either PDF or SVG, although the support
for either seem to be falling behind that for PostScript.)
[...]
--
FSF associate member #7257
Andrew Smallshaw
May 11, 2013, 4:40:40 PM5/11/13
to
On 2013-05-11, Ivan Shmakov <onei...@gmail.com> wrote:
> [Cross-posting to news:alt.barcodes.]
It seems the biggest problem is that most printers seem to see a
raster image and assume it's fair game for dithering. "Dotty"
barcodes don't scan very well.
> > Formatted printed output from programs generally means PostScript in
> > any event (for a Unix shop at least ;-) ), so inserting a barcode
> > generation function in the header and then calling it with the right
> > options later is no big hassle.
>
> Yet, I cannot refrain from reminding that PostScript is /not/ a
> format, but a fully-featured programming language (which has
> certain implications on its own.) Surely, I'd prefer to handle
> a format which I can parse, instead of one I have to /execute/.
> (Generally, that'd mean either PDF or SVG, although the support
> for either seem to be falling behind that for PostScript.)
It's horses for courses. Personally I view that programmability
as its greatest strength - it means you can draft a standard job
header containing the relevant functions and from then on the
job-specific stuff is high-level stuff that reflects both the
logical layout of the job and the internal layout of the program
doing the generation.
Since the issue here is barcodes consider drawing one "manually".
You'll have a sequence of commands :
Go to x1,y1
Define box width x2 height y2
Fill with black.
Go to x3,y3
Define box width x4 height y4
Fill with black...
30 or 40 times over. That kind of generation gets real tedious
real fast and the resulting code inevitably looks a right mess.
In contrast with postscript you define a standard function once in
the job header and then simply call it, e.g.
(1234567890123) ean13
Of course you can argue that the complexity is simply shifted but
it always seems a _lot_ cleaner to me to put the smarts in the job
itself as opposed to the program - it saves "bitty" I/O for one
thing and expresses the complex stuff in a language designed for
the task at hand.
--
Andrew Smallshaw
and...@sdf.lonestar.org
> [Cross-posting to news:alt.barcodes.]
>>>>>> Andrew Smallshaw <and...@sdf.lonestar.org> writes:
> > formats and the option of EPS output - I'm not overly inclined to
> > trust low res bitmaps for something like this.
>
> Even given that the majority of barcodes (and non-bar codes,
> such as the QR code) are essentially raster? (Well, except the
> alphanumeric label, if any.)
Yes - I've had too many problems with bitmap barcodes in the past.
> > formats and the option of EPS output - I'm not overly inclined to
> > trust low res bitmaps for something like this.
>
> Even given that the majority of barcodes (and non-bar codes,
> such as the QR code) are essentially raster? (Well, except the
> alphanumeric label, if any.)
It seems the biggest problem is that most printers seem to see a
raster image and assume it's fair game for dithering. "Dotty"
barcodes don't scan very well.
> > Formatted printed output from programs generally means PostScript in
> > any event (for a Unix shop at least ;-) ), so inserting a barcode
> > generation function in the header and then calling it with the right
> > options later is no big hassle.
>
> Yet, I cannot refrain from reminding that PostScript is /not/ a
> format, but a fully-featured programming language (which has
> certain implications on its own.) Surely, I'd prefer to handle
> a format which I can parse, instead of one I have to /execute/.
> (Generally, that'd mean either PDF or SVG, although the support
> for either seem to be falling behind that for PostScript.)
as its greatest strength - it means you can draft a standard job
header containing the relevant functions and from then on the
job-specific stuff is high-level stuff that reflects both the
logical layout of the job and the internal layout of the program
doing the generation.
Since the issue here is barcodes consider drawing one "manually".
You'll have a sequence of commands :
Go to x1,y1
Define box width x2 height y2
Fill with black.
Go to x3,y3
Define box width x4 height y4
Fill with black...
30 or 40 times over. That kind of generation gets real tedious
real fast and the resulting code inevitably looks a right mess.
In contrast with postscript you define a standard function once in
the job header and then simply call it, e.g.
(1234567890123) ean13
Of course you can argue that the complexity is simply shifted but
it always seems a _lot_ cleaner to me to put the smarts in the job
itself as opposed to the program - it saves "bitty" I/O for one
thing and expresses the complex stuff in a language designed for
the task at hand.
--
Andrew Smallshaw
and...@sdf.lonestar.org
Ivan Shmakov
May 12, 2013, 4:50:13 AM5/12/13
to
>>>>> Jasen Betts <ja...@xnet.co.nz> writes:
>> I'm not overly inclined to trust low res bitmaps for something like
>> this.
> barcodes have integer-width stripes, this layout fits well with
> bitmaps if the scale factor is an integer.
Yes, that's what I wanted to say. However, there's indeed an
issue with various software packages, which apply interpolation
on scaling by default. Which means that the image gets the
blur, the shades, and, finally, the dithering that was observed.
And, frankly, while searching for an option to disable such
interpolation for raster graphics may be an endeavor on its own,
this whole issue rarely arises when using vector graphics.
> Bitmaps will often be more space-efficient than vector formats,
> especially if the bitmap format allows non-square pixels,
... And as long as one embeds the raster in question into a
vector image, this will almost always be easy to achieve.
>>>>> On 2013-05-11, Andrew Smallshaw <and...@sdf.lonestar.org> wrote:
[Cross-posting to news:alt.barcodes.]
[...]
[Cross-posting to news:alt.barcodes.]
>> I'm not overly inclined to trust low res bitmaps for something like
>> this.
> bitmaps if the scale factor is an integer.
Yes, that's what I wanted to say. However, there's indeed an
issue with various software packages, which apply interpolation
on scaling by default. Which means that the image gets the
blur, the shades, and, finally, the dithering that was observed.
And, frankly, while searching for an option to disable such
interpolation for raster graphics may be an endeavor on its own,
this whole issue rarely arises when using vector graphics.
> Bitmaps will often be more space-efficient than vector formats,
> especially if the bitmap format allows non-square pixels,
... And as long as one embeds the raster in question into a
vector image, this will almost always be easy to achieve.
0 new messages