EAN-13 /Code39 Barcode in FileMaker w/o Fonts

[cjaeger]

I just wondered if you might be interested - A platform independant, basic approach to barcodes not involving plugins or fonts. Great for printing product id labels. However, barcode length is limited to 64 characters because of FileMaker's ability to display only 1000 repeats.

[color:"red"] attachment deleted

[color:"blue"]New Code39 and EAN samples at the end of this thread

[AudioFreak]

Hello,

Just out of curiosity I printed the barcode and tried to scan it using our scanner which will read code 39. Well in short the scanner can't read the barcode.

Michael

[cjaeger]

The bars are probably too wide, that's why I wrote print scaled (at 50% maybe).

Good you tested it, though, as I do not have a scanner ready. I did this only by textbook and visual comparison to results in Bar Code Font ...

just let me know if it works, because I am just starting EAN-13 using a similar technique ...

[AudioFreak]

I believe the length of the barcode is fine. I just printed a barcode using the same text, printed in code 39 using a plug-in and they are different.

[cjaeger]

but then, maybe my pattern formula is wrong ...

Will have a look at it and re-check.

This will be part of a solution where i hope someone can scan a package slip number directly from screen and enter the data into a shippers label printing application on a 2nd computer. Don't know if it works yet - especially with the customers barcode readers, but i'll see soon enough.

[AudioFreak]

We have a SPT 1700 here and I was hoping to be able to read the barcode off the screen too. I tried but it does not work. Maybe due to the glare not quite sure. Tried it on a flat LCD screen also, no luck there either. I'm considering Trying to change the background color and/or text color to see if this will make it work. I'll let you know.

Michael

[cjaeger]

I useda different font now, and yes - the patterns are different. Will look it up & repost file ...

[LiveOak]

Of course this won't work. There is really nothing there to scan. With laser scanners, the laser source wipes out the screen image. The reflectivity of the screen phosphor doesn't change with illumination by the electron beam. With imaging scanners and the light source disabled, the scan rate of the scanner will interact with the scan rate of the crt and create unpredictable results. There is no static, whole image on the screen, you vision just make it appear that way.

Tell me you guys are just putting us on.

-bd

[cjaeger]

Update - tried the patterns from GD::Barcode 1.3 (CPAN), won't work either without applying some bit masks. working on it ...

[cjaeger]

Of course this won't work. There is really nothing there to scan. With laser scanners, the laser source wipes out the screen image. The reflectivity of the screen phosphor doesn't change with illumination by the electron beam. With imaging scanners and the light source disabled, the scan rate of the scanner will interact with the scan rate of the crt and create unpredictable results. There is no static, whole image on the screen, you vision just make it appear that way.

Just thought it might have been possible using a TFT screen.

And there have been a "data watch" once that grabbed data directly from screen using some patterns generated by software.

OK, but still it should be possible to print those codes. I hate having to install expensive fonts just to print such simple things as barcodes ...

[BobWeaver]

No, a TFT screen would be no different. It might be possible with a non-backlit LCD display. But, I don't know where you would find one these days.

[cjaeger]

OK, get your scanners ready and test the EAN-13 implementation.

I might have to tweak the dividers, but it should work.

Code 39 is not ready yet.

[color:"red"] attachment deleted

[color:"blue"]New Code39 and EAN samples at the end of this thread

here are some codes for testing:

7611819001480

7611819001497

7611819001503

7611819001510

7611819001527

7611819001534

7611819001541

7611819001558

7611819001565

7611819001572

7611819001589

7611819001596

7611819001602

7611819001619

7611819001626

7611819001633

7611819001640

7611819001657

7611819001664

7611819001671

[cjaeger]

Here is the corrected Code39 file.

Bar widths ar set to 3:1, character spaces are set to 2 times singlewidth for easier readability. (a ratio of 2:1 and 1 are perfectly legal but harder to scan...).

Please test and tell me if it works

Code39new.zip

[cjaeger]

while I am at it: I finally scarpped the book & went googling...

here are some interesting sites about barcodes:

http://www.barcodeman.com/info/c39_1.php

http://www.aaa-technologies.com/General/code39.htm

[Robert Schaub]

Works good iin my house, but I have always simply made a field called barcoded calcualted = "*"& Barcode & "*" unstored calc when needed.

[cjaeger]

that's right if you distribute a font with your bound solutions. However, sometimes you cannot install fonts or do not want to because of licensing restrictions or software policy.

Barcode fonts are expensive and fonts from different vendors usually don't mix because of different character mappings.

Just imagine you create a product catalog on cd and want the shopping cart faxed/snail mailed to you with barcodes. With the UPC/EAN example, you have a checksum and encoding logic that can not be simply typed in.

"Taking the code down to the bars" is a royalty-free, pure Filemaker way of doing barcodes without the need of extra software.

BC fonts usually operate at a higher resolution and include hints to allow for dot gain etc, but for most applications this will not be necessary. You could easily recreate the logic behind it in javascript to include the bars in an invoice printed from a webpage (although the perl gdbarcode is an easy way of doing this in cgi), or you can do the same with XSL and SVG.

[cjaeger]

Here is a working version of the EAN-13 barcode example. There was an error in the divider bar calculation.

To see how to implement this code in existing solutions, see the upcoming UPC-A example in this Forum.

Since the solutions are working now, I will delete all intermediate uploads.

CodeEAN13new.zip

[cjaeger]

BE AWARE THAT THIS TECHNIQUE MAY NOT WORK IN FILEMAKER 7.

It relies on repeating container fields displaying images without a gap. Not possible anymore with FileMaker's new graphic engine without major workarounds.. But they may fix this in the future.

One workaround involves working in 400% scale, then copying the result in preview. See the EAN 13 example. You may want to copy the container field and offset it a half pixel.

Due to variable length this is not always possible with Code39 strings.Get one of the free fonts (google: 'code39.ttf' ) available on the internet. They work on OS x now without mods.

[Mc128k]

Use this, I created it myself. It's available for free. http://www.mc128k.info/2015/12/codici-a-barre-su-filemaker-con-una-funzione/

It generates a BMP for a container field, I believe paid solutions use the same technique.

[dronte]

cjaeger and Mc128k - I Love YOU guys

[MonkeybreadSoftware]

If you use MBS Plugin, you can try our Barcode functions.

We can create picture for a barcode with various options and a lot of barcode types (EAN, UPC, QRCode, DataMatrix, PDF417, etc.).

And we can write image files (JPG, GIF, PNG, SVG, TIFF, PS) and draw vector graphics of barcode on PDF pages.

[Mc128k]

Such a shame this isn't included in FM itself, reminds me how unprofessional this solution is. Anyway I plan to support QR too in the future, and probably I'll post it here when it's done. A good hack I think would be to use a "complex" javascript inside a web viewer to generate the binary, anybody had some experiences with it?

[jbante]

On 3/29/2017 at 9:14 AM, Mc128k said:

Use this, I created it myself. It's available for free. http://www.mc128k.info/2015/12/codici-a-barre-su-filemaker-con-una-funzione/

It generates a BMP for a container field, I believe paid solutions use the same technique.

Nice! Yes, Barcode Creator uses a similar approach: building base 64 that can be converted to container data. The details are more complicated for different image file types and barcode symbologies, but that's the gist of it. I'd suggest you try EPS next if FileMaker's support for EPS in containers weren't deprecated.

Other folks have used existing JavaScript libraries to render a QR Code in a web viewer. There are some challenges with that, though:

• The JavaScript QR Code libraries are mostly designed to draw the QR Code. I haven't seen one that actually makes a separate image file, but I haven't really been looking.
• In case you opt to display a QR Code in a web viewer, printing web viewers looked pretty awful on Windows last time I checked (on-screen resolution instead of print-quality). This might be worth someone checking again. Images in container fields print much better.
• Web viewers don't work in server-side scripts, if you ever want to move barcode creation from clients to the server.
• All the JavaScript libraries I've seen that generate QR Codes don't do it well. I have yet to see a JavaScript QR Code library that both supports all the basic encoding modes and optimizes the size of the encoded data.

[Mc128k]

Thanks for the insight! Actually I'm looking to use the web viewer just to "execute decent code" and then get data from it, maybe a base64 encoded image. I read somewhere that it's possible to communicate bidirectionally.

Too bad you say that js code for qr is bad. And no server support. I'll try researching...

******* filemaker scripts. They are close to true code, but not enough.

[Edit] Wow, I didn't know da-mn was a censored word. 

Edited May 8, 2017 by Mc128k

[jbante]

1 hour ago, Mc128k said:

******* filemaker scripts. They are close to true code, but not enough.

I'm not sure what you mean by "true code". Can you elaborate? What makes code "true" that FileMaker scripting does not satisfy, as you understand it? As an abstract-computer-science-minded kind of person, any series of instructions that a computer will execute is "code" enough for me — maybe I'll throw in Turing completeness if I'm being really picky, but FileMaker scripts satisfy that criterion, too.

[Mc128k]

Sorry about the upcoming rant, you are free to ignore it. I've been working for years with filemaker and other languages, despite its easy-to-use interface I think scripts are one of the worst thing of this platform.

Correct me if I'm wrong on any of this.

For starters, I need a text editor. Or source files I can version with git and edit with sublime. Not a fancy drag-and-drop (now it's better) script editor. This really looks like a toy, and scripts are slow too (execution). Can't I just write functions and parameters with code completion? Nope, I have to mix writing and clicking windows every time. Keyboard shortcuts help here, but not that much.

Then, it's not trivial to build some abstractions. Using an object-oriented language is too much maybe, but at least some functions and complex data structures are necessary. Everything comes down to rebuilding the wheel, inventing (or adhering to) standards or creating hacks to make something useful. Decoupling scripts is hard given their nature, parameter passing needs a parser every time, RPC is complicated and resource-intensive. What about error handling? Logging? Exceptions? Data observables?

Yes, we can build everything I mentioned, but it's rather complicated, and for a platform like this I begin to think if I'm being stupid not using any other serious framework for building apps. It's perfect for small projects, but it doesn't scale any good. And it becomes expensive too.

Scripts ARE turing-complete, but still they are pure madness when it comes to it, basic language constructs that are implemented in nearly every other serious language are missing (for loops, arrays, variable scope, types, tables/dictionaries) and have to be built with other elements. There is no search, no find/replace, no simple import/export. Asynchronous programming is complicated, and sometimes impossible (HTTP requests), it's hard to work with data without entangling everything with a VIEW (yes, I have to be in a layout to build a context). They are called "scripts" for a reason after all. 

Patterns can be built, but it's hard to make them good. What if I wanted to create an "universal sync system" that didn't rely on the table schema? Is there an API to simply get the table items as... dictionaries? Nope, I have to build a layout with every field and enumerate them! If I add a new field I have to edit the layout too. Cool.

I'm researching a way to do it with ExecuteSQL, there is a hidden FileMaker object that seems absent from every document on the official site (or maybe I missed it), this could probably eliminate enumeration problems. What about exchanging data?

Well, "serious" languages have libraries (objects or functions) that create an XML DOM and then serialize it, right? Not here, even the most basic plugin implies heavy limitations (like not running on iOS or having to upgrade at every release) and they cost a f..* ton of money. Want to do it with scripts? Possible of course, I just have to implement it from scratch. OR we can use JSON, at least they implemented native functions for it! Hooray!

Now, we have our serialized records (and base64 encoded containers, thanks fmp12), I just need to compress it to send it over a slow WAN link.. Oh right, sorry. I'll just send uncompressed code. Still I can encrypt it, right? Nope. No security functions outside of expensive plugins that stop working after the new release. Filemaker encrypts its protocol at least.

Shared libraries amonst files? Yeah, have to open the entire file at runtime. Again, RPC sucks. Encapsulation? Decoupling? What's that? This is a script.

Localisation and internationalisation? Build it yourself. Also there is some "black magic" with locales, like "the number formats are determined by the system with FMP that saves the file". Background processing? Just use a temporary window placed at +999999 +99999 with dimensions of 1px 1px, do your stuff here and then close it. This is the only way to correctly preserve UI state while doing other operations like editing an item's stock. Seriously? Run the script in the server! And meanwhile rebuild the entire context, wait a couple of seconds and you're done. Do this for every record in a list of 1000 elements. Remotely.

This is not a platform for professionals. This is just a prototyping system for databases.

 

[Mc128k]

One last thing. If we call them "Macros" instead of "Scripts" it makes more sense. They are a bunch of macros for writing UI operations.

[jbante]

Show me a programming language that doesn't have dozens of the same kind of rant written about it, and I'll show you a programming language no one really uses for professional purposes.

One note on execution speed, though, since this was in the context of rendering QR Codes in a web viewer: JavaScript rendering a large QR Code in a web viewer isn't particularly fast, either. If FileMaker scripts aren't good enough in that respect, neither is JavaScript (or at least not JavaScript in a web viewer). A plug-in or a web service (with a low-latency connection) would be a stronger comparison.

Edited May 8, 2017 by jbante

[Josh Ormond]

4 hours ago, Mc128k said:

This is not a platform for professionals. This is just a prototyping system for databases.

This is cute. And completely not the case in reality. I have seen so many "professionals" try to replicate work we have done in FileMaker, and they have been ridiculously unsuccessful.

I don't disagree with some of what you mentioned. There are things I would love to see done differently. But that is also the case with every other programming environment I've dabbled in. To be fully honest, they all suck in their own way. 

Scale? What kind of scale are you referring to? I ask because I see 2 types of people that say this ( note I'm not implying anything about you specifically, just a general observation ). (1) People who built themselves into a corner, and just set up the data model the "wrong way". For them handling a few thousand records is painful. (2) People who want to process 20 million records in a second or two. Constantly. All day. Yeah, FileMaker isn't that tool.

Relatively speaking, the number of companies needing to process millions of records a day is kind of small...compared to the companies that only need to handle a few thousand to a few million records a year. So for developers, this is one tool they have in their toolbelt. And they get paid well for the work they do. That's the definition of professional. Many developers I know have more work than they can handle right now. So it's hard to agree with you on that point.

[Mc128k]

9 hours ago, jbante said:

Show me a programming language that doesn't have dozens of the same kind of rant written about it, and I'll show you a programming language no one really uses for professional purposes.

Except that this isn't actually a "programming language", it's more a scripting system, or like I said a "macro" system. But there's no problem after all, as long as it's possible to build everything with it. Still, it's hard to create maintainable and reusable code.

Quote

One note on execution speed, though, since this was in the context of rendering QR Codes in a web viewer: JavaScript rendering a large QR Code in a web viewer isn't particularly fast, either. If FileMaker scripts aren't good enough in that respect, neither is JavaScript (or at least not JavaScript in a web viewer). A plug-in or a web service (with a low-latency connection) would be a stronger comparison.

You're right of course, I'm not expecting execution speed for JS either (even if it's way faster in theory compared to other high-level languages), but at least that scripting steps do not take forever to execute. It's like an automation system, where every step uses an incredibly high processing power to be parsed, checked and executed. Excellent for small things, terrible for bigger ones.

Quote

I don't disagree with some of what you mentioned. There are things I would love to see done differently. But that is also the case with every other programming environment I've dabbled in. To be fully honest, they all suck in their own way. 

Again, I agree that some other systems totally fail. And that's the beauty of FileMaker, it makes easy what takes a lot of effort to build. I would prefer creating stuff with it rather than Java.

Quote

Scale? What kind of scale are you referring to?

When you deploy with many users (I am working on a medium sized project atm) you encounter sync and versioning issues. Building reusable and modular code becomes hard. About the number of records I'm not referring to millions here (somebody would lose their head if he put FM for a solution this big), but only thousands. Make a script that does an operation on say 2000 records, and run it. It's slow compared to other programming environments. Even PHP can be faster.

 

I don't have a good definition of "professional", I can just feel that compared to other systems in the industry this looks like a toy. Actually this is like MS Access to a higher level.

To understand FileMaker we have to go back to Claris and v2.0. See what the "Macintosh UI" innovation really meant back there. No code, intuitive graphical interfaces, drag and drop and so on. Other systems have failed, I think "Double Helix" was somehow similar, but I might be wrong here.

[jbante]

7 hours ago, Mc128k said:

Except that this isn't actually a "programming language", it's more a scripting system, or like I said a "macro" system.

That's not a meaningful distinction.

7 hours ago, Mc128k said:

Make a script that does an operation on say 2000 records, and run it. It's slow compared to other programming environments. Even PHP can be faster.

"Slow compared to other programming environments" doesn't make FileMaker slow in any absolute sense. "Slow compared to user needs for a particular application" is much more meaningful, and once an application is fast enough to exceed user needs, pursuing additional speed may be wasted effort. FileMaker passes this threshold for many applications, including applications working with millions of records. Working with large data sets efficiently with FileMaker may take additional work, which makes it no different from any other programming environment, and achieving the best possible performance from FileMaker often takes less effort than achieving the best possible performance from other tools. At least FileMaker doesn't claim that processing speed is an absolute top priority, then make design decisions contradicting that every step of the way — just look at what the HPC community has to say about Hadoop.

[Mc128k]

20 minutes ago, jbante said:

That's not a meaningful distinction.

If you are too much generic, yeah, it's meaningless. Still there is a distinction. Otherwise all languages would be exactly the same. Would you like to program in Assembly or brainf*ck? Perl? Ruby? C? They are all turing-complete, so they are all the same. That sounds wrong to me.

Working with filemaker scripts is like being able to only speak using concrete words. You cannot make abstractions or generalise concepts. The dictionary is poor.

Macros are like the mouse/keyboard recording programs, they tell what to do with the UI, and if you see the command palette, that's exactly it. "Go to field".. "Perform find"... "Select all"... "Insert"... these are all actions that an user can do. That is exactly what irritates me, as I learned what can be done with more complex languages, filemaker makes me feel stupid because programming here is like trying to teach algebra to a five years old child.

I hope that makes it clearer

And about speed.. yeah, that could be sufficing, but it hurts a lot scalability and usability. It really makes a difference to have a fast application.

[Josh Ormond]

9 hours ago, Mc128k said:

When you deploy with many users (I am working on a medium sized project atm) you encounter sync and versioning issues. Building reusable and modular code becomes hard. About the number of records I'm not referring to millions here (somebody would lose their head if he put FM for a solution this big), but only thousands. Make a script that does an operation on say 2000 records, and run it. It's slow compared to other programming environments. Even PHP can be faster.

We have millions of records in multiple tables, being hammered on by 100 users... And processing 3-5k records at a time. Rarely takes longer than a few seconds. So I'm not sure what you mean.  I'll agree, FM will let you build it so it's slow, but that doesn't mean it can't be faster. And as Jeremy said, performance increases are only beneficial to a point. 

There are so many variables that can make a process or script perform poorly, it's short-sighted to always blame FM for that. Sometimes, and probably more often than we would like to admit, it is the developer's fault.

[jbante]

2 hours ago, Mc128k said:

Working with filemaker scripts is like being able to only speak using concrete words. You cannot make abstractions or generalise concepts. The dictionary is poor.

Macros are like the mouse/keyboard recording programs, they tell what to do with the UI, and if you see the command palette, that's exactly it. "Go to field".. "Perform find"... "Select all"... "Insert"... these are all actions that an user can do. That is exactly what irritates me, as I learned what can be done with more complex languages, filemaker makes me feel stupid because programming here is like trying to teach algebra to a five years old child.

You definitely can make encapsulated or generalized logic in FileMaker. You can't do it the same way you would in Java or Haskell, but Java and Haskell can't encapsulate or generalize logic the same way the other does, either. FileMaker's abilities seem about on par with C in this respect.

Every useful programming environment has its building blocks, such as in a standard library; and the contents of that standard library dictate much of how programs written for that environment operate, both internally and with the outside world. The operating environment or standard library is often a more significant contribution to the value of a programming language than the logical structures it uses. Java is popular because of the portable virtual machine, despite being awful as a language. JavaScript is another example. C(++) is popular because its operating environment is close to the silicon, despite that making it more difficult to encapsulate certain highly consequential concerns. FileMaker scripting starting with options available in the user interface is just one reasonable choice of building blocks to start with, and a pretty inspired choice, designed to minimize the learning curve for "citizen developers". In a Darwinian sense, FileMaker's choice is successful. (The script engine also includes many steps that have no counterpart in the user interface.) Every Turing machine has its tape, and failing to embrace the nature of that tape will doom a developer to never using that machine well.

Edited May 9, 2017 by jbante

[cjaeger]

Well, good to know that my 2003 solution still works in 2017. And on. thx. C.