Hi Jeremias,
Thanks for response and for Barcode4J (which under other circumstances I find works very nicely indeed). I look forward to Barcode4J version 1.0.
I had already read the troubleshooting guide and had already tried to apply the recommendations.
Because these particular barcodes I am trying to print are so small and the printers I am trying to use have a fairly low resolution (200 and 300 dpi) there is very little room for manoeuvre with the module width and wide factor. My best results so far have been with a module width of .254 and wide factor of 3.0. However with these values the barcodes are then just a little too wide to fit on the labels. The width of the bars, although more consistent, usually still vary in one or two places.
I don't think that the change to logical unit space will make any difference with regards my current problem.
Thanks,
Patrick
-----Original Message-----
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
Sent: 29 August 2004 21:10
To: Batik Users
Subject: Re: quality issue with svg barcodes on printer with less than
600dpi
I'm Barcode4J's main author and may be ableto add a bit to this. I think
Thomas is probably right with his suspicion. I'm not sure if it helps
but also look at http://barcode4j.krysalis.org/troubleshooting.html for
a checklist when barcodes don't read.
And I've learned from Thomas during the last few weeks how "real world
units" are suboptimal within SVG files. I'll change the SVG generator in
Barcode4J shortly to use a viewBox and a logical unit space. FWIW, I'm
working to release Barcode4J 1.0 final within 2 or 3 weeks. But I should
have the changes for the SVG generation in by tomorrow evening (CEST) in
the codebase (accessible using CVS).
The suboptimal SVG code generated worked fine in Apache FOP (for which
the whole thing was written in the first place) but is obviously flawed
for SVG-embedded-in-SVG scenarios.
On 29.08.2004 02:32:13 Thomas DeWeese wrote:
> Hi Pegan,
>
> I suspect that this is an aliasing issue. This basically
> means that the width of your bar codes might be 3.5 pixels
> wide, does the renderer draw 3 or 4 pixels. In this case
> the most likely problem is that the bar is 4 pixels wide
> but it starts on 1/2 a pixel, this means that the renderer
> needs to decide if it should render 5 pixels, 4 pixels or
> 3 pixels. The way the barcode is currently specified it
> is difficult to know.
>
> You may not be aware but the use of 'real world units' like 'mm'
> means essentially nothing except on the width/height of the outermost
> SVG element. For all other contexts the mapping from the real world
> units to userspace units is fixed.
>
> [EMAIL PROTECTED] wrote:
>
> > When I print small interleaved 2 of 5 barcodes on printers with less
> > than 600dpi from my application I am getting quality problems.
> >
> > The barcode has 14 digits and has to fit on a label 35mm wide. I am
> > using Krysalis Barcode (now Barcode4J) to generate the barcode svg.
> >
> > My attached sample svg has 2 barcodes side by side, they look identical
> > when viewed in Squiggle but are not identical when printed at a
> > resolution of 300dpi or less.
> >
> > With printers that have 300 dpi or less I find that the bar widths can
> > be smaller or larger by one printer dot, likewise the rendered position
> > of the line can also vary by a dot in either direction. Although the
> > barcodes scan, they can be of very variable quality when checked with a
> > barcode verifier (ranging from grade B to F). I frequently find that
> > the barcode on the left scans as B and the one on the right fails as an F.
> >
> > The bars are perfect when printed on printers with 600+ dpi and scan as
> > grade A.
> >
> > Is there anything I can do to improve things ?
> > <<f1.svg>>
> > Thanks,
> > Patrick
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Important - This e-mail and the information that it contains may be
confidential, legally privileged and protected by law. Access by the
intended recipient only is authorised. Any liability (in negligence or
otherwise) arising from any third party acting, or refraining from acting,
on any information contained in this e-mail is hereby excluded. If you are
not the intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or store
or copy the information in any medium. Copyright in this e-mail and
attachments created by us belongs to STR Gresham Business Forms Ltd the
author
also asserts the right to be identified as such and object to any misuse.
