Can't print barcode on Access report

I'm trying to print an Access report with a barcode, the problem is the source text contains extended ascii codes, the funny chars, like 194 , and the barcode font is not interpreting them properly, whereas the same font does make the funny chars look OK in Word.
Silas2Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

rhandelsCommented:
For as far as i'm aware you actually  need to have a barcode font installed on the machine, or is this the case?
What happens of you print the information as an image file?? Sometimes this could also help. And maybe try and update the drivers of your printer? As in, not the default Windows ones or Universal printer drivers.
0
Silas2Author Commented:
I've got the font, its just the Access report writer renders it badly (some chars it get ok, the others not).
Re printer drivers, my customer has different setups than me, and it looks the same on both of our systems, screen+printers, so it looks like something in the way access report generator renders extended ascii chars with the barcode font.

Is there a way to automate printing the barcode then embedding that image, it would be a bit of a VBA animal I think though, as it would need to print using vba automation to , say , Word...any examples?
0
rhandelsCommented:
Pfff, i'm no hero at all when it comes to VB code. So you say the Access report already is somewhat clunky?? Is there a way to use a side step and convert it into a PDF file?
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

rhandelsCommented:
Have you read this link??
Might be that the font type isn't the correct one??

http://www.makebarcode.com/info/appnote/app_014.html
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<the funny chars, like 194 , and the barcode font is not interpreting them properly>>

  Your mis-understanding something; a font is just a font.  There is no logic for encoding the data associated with a font; that's all up to you. That's why many buy a 3rd party lib or dll; all that logic is done for you.

 Also be aware that normally 3 of 9 does not do the upper "extended" character set, so you need to make sure your using an extended 3 of 9 font,  and the bar code reader reading it also needs to be programmed to pick it up.

Along the lines of what rhandels posted, here's another link that explains all this:

http://www.idautomation.com/barcode-faq/code-39/

and specifically look at the section:

"Encoding ASCII Character Set in Extended Code 39"

and the chart, which shows how to encode the extended character set.

Jim.
0
Silas2Author Commented:
<< Your mis-understanding something; a font is just a font.  There is no logic for encoding the data associated with a font; that's all up to you. That's why many buy a 3rd party lib or dll; all that logic is done for you.>>
What I'm thinking, it (as in report writer) is not encoding but it has to render it, and the chars which are ascii 194 (for example) are rendering incorrectly, although they render correctly in Word.

If it (appears) to render correctly in Word, does that mean that 3 of 9 is working for these extended character set, and its just access which can't plonk them on the page?
0
hnasrCommented:
In Access, the control source for a text field to display barcode is written as:

  ="*" & [txtField] & "*"

[txtField] is a text control value on report.
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<What I'm thinking, it (as in report writer) is not encoding but it has to render it, and the chars which are ascii 194 (for example) are rendering incorrectly, although they render correctly in Word.>>

 Rendering is separate from encoding, but do you know even if Word is correct?

 Also in the Access, there are a number of things that can affect what something looks like.  

Fundamentally there is:

1. The size of the control
2. Padding
3. Is the font a true type font or no?
4. Do you have the "Fast Laser Printing" property set to true?
5. Are you viewing the report in layout view instead of report preview?
6. Are you using the same printer driver that you are using for Word and more specifically, do you have images printing as bitmaps.

 As you can see, there are a number of things that can effect how a bar code looks with Access.   It is not just a matter of using a bar code font for a control and placing the raw data in it.

 To get to the bottom of this, start with Word; can you scan the bar code in Word and get the correct data back?   Now what about Access?

Jim.
0
Silas2Author Commented:
Thanks for that hnsar, I tried that with my fingers crossed, but it looked the same.

Just so you can try, this is the text it can't render:

ÌIMAÇÂÂÂÂÂÂ%ÈTB-Î

Open in new window

0
Silas2Author Commented:
Thnks for being so persistent Jim.
No, I don't know if the Word is correct, I only know it looks better! I.e. there are no gaps.
This is the text I'm trying to render:

ÌIMAÇÂÂÂÂÂÂ%ÈTB-Î

Open in new window


Can you get that to render as a bar code?

I'll check the other things you mentioned.
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<
No, I don't know if the Word is correct, I only know it looks better! I.e. there are no gaps.
>>

 That really means nothing other than the pattern is different.

 My suggestion would be this:

1. Start off slow....encode a few normal characters (i.e. "ABC") and see if you can read it back with a scanner.

2. Now try adding lowercase characters ("ABCabc").  Do you get a good scan?

3. Now add one extended character.  Make sure your encoding it right and get back the correct character when scanned.

4. Now do your full data and ensure that you are getting the correct scan.

 Don't move onto the next step until the current step is working correctly.

Jim.
0
Silas2Author Commented:
To be honest, all the scanners are at the customer, and at various post offices dotted around the world, so...I'll have to ask them.
These encoded characters are coming from a 3rd party, so I can't really get the ones I want to test.
The customer has told me the Word rendering is right and the Access one isn't with the same text, so that kinda puts the Access report rendering engine in the frame if that's true.

But I don't know what I could change about the Access rendering to make to work.
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<To be honest, all the scanners are at the customer, and at various post offices dotted around the world, so...I'll have to ask them. >>

  Well your going to need to get a scanner, or be able to have someone generate the reports for you and scan them to verify your work.

  And be careful if you fax or scan output; it's  very easy for things to get messed up.  For example, you print to PDF and then someone takes that PDF and their print settings are "Fit to Page".  As a result, the PDF is squeezed down and as a result, you may now have a bar code printed at a different density and although it may be correct in every way, it may not scan.

<<These encoded characters are coming from a 3rd party, so I can't really get the ones I want to test.>>

 I do not understand that.  You do not have the actual data that is causing the problem?   Have to say, that is not a great way to understand or fix a problem.  Makes it tough to get any where with it.

<<The customer has told me the Word rendering is right and the Access one isn't with the same text, so that kinda puts the Access report rendering engine in the frame if that's true.>>

 All things being equal yes, but as I have already shown you, there are a number of things that can impact the rendering of what appears on an Access report.   And with that said, I have never had anything in Access render something incorrectly because of a problem in the report engine itself.  It always has come down to the way something was  printed and/or settings.

Jim.
0
hnasrCommented:
Can you upload a sample database to try here.

What do you mean with this text: ÌIMAÇÂÂÂÂÂÂ%ÈTB-Î?
What barcode font are you using?
How does the result look in word?
0
Silas2Author Commented:
The text is the text I'm trying to create a barcode for. Put it into a field, and try to view it on a report, and see if it looks the same in Word.
0
hnasrCommented:
I get same result in Access and Word.
Using 3 of 39 barcode font.

Reply to my previous comment.
Attach a screenshot of what you get in access and word, and specify font used.
0
Silas2Author Commented:
Thanks, let me just do that for you, might be tomorrow now though...
0
DansDadUKCommented:
Even the "extended Code 39" character set does not support characters with code-points above decimal 127 (hexadecimal 7f).
So I don't understand how Word can possibly have rendered your string correctly, unless it is using a different bar-code.

From the wikipedia entry for Code 39:

Code 39 is restricted to 43 characters. In Full ASCII Code 39 Symbols 0-9, A-Z, ".", and "-" are the same as their representations in Code 39. Lower case letters, additional punctuation characters and control characters are represented by sequences of two characters of Code 39.

So if you want to encode extended ASCII characters (including most of those in your sample string of "ÌIMAÇÂÂÂÂÂÂ%ÈTB-Î"), you will have to choose a different bar-code symbology, such as (for example) Code 128.

Note that with almost all bar-code symbologies except basic Code 39, there is not a one-to-one correspondence between the data to be encoded and the encoded string; the encoding mechanism required for some bar-codes is quite complex (hence the function libraries supplied by the bar-code font vendors).
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Silas2Author Commented:
Thnks very much for that research. I'm going back to my customer, to their supplier to tell them to supply tracking codes (that's what they're for) in a more normal format!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.