I am developing a Point Of Sale application, and one of the functionality is to print receipt in a thermal/receipt printer. Currently I have a Datecs DPP-255 printer.
I have no idea where to begin my quest.
I tried search through internet, found out that JavaPOS/UnifiedPOS exists but I couldn't find enough documentation to get me started. Please shed some light.
Here is an open source project for testing, that may also be used as a reference on how to program using JavaPOS (source code available):
JavaPOS POSTest 2 - a JavaPOS application for testing JavaPOS devices (source code is here).
Also here are some projects hosted on GitHub (see the source code to get the idea and to play with):
JavaPOS
POSdeviceSimulator
POStest
Related links:
Old documentation page for
JavaPOS
How to develop using JavaPOS in
Eclipse?
NOTE:
in order to utilize JavaPOS (which is now a part of the UnifiedPOS specification, see Appendix B), the producer of your Datecs DPP-255 device must provide the related drivers. Are they provided? JavaPOS - is a specification, so accordingly there must be some implementation of it.
So it looks like this printer supports something called ESC/POS, which is like a command set that allows you to print and format data. There are a few guides available online, this is one I've used before: http://www.starmicronics.com/support/mannualfolder/escpos_cm_en.pdf
Note that printers sometimes subtly differ in which command sets from ESC/POS they support, so you might have a bit of trial and error on your hands.
In terms of sending that data to the printer, it depends on what type of connection it is. For serial, you should just be able to open and write to that port, using the ESC/POS command set.
Not all of the data you will send will be ASCII or UTF encoded, a lot of them are binary values you need to send. So for example, to tell the printer to write a new line, the Hex value for that is 0A. So in Java you would need to specify that as String s = "\u000A"; etc.
For java you will need to download the Java Comm API from http://java.sun.com/products/javacomm/
There is a tutorial on this here: http://www.java-samples.com/showtutorial.php?tutorialid=214
Hopefully this helps.
I am working on an Android app that stores log on a client's Google Drive. We push static HTML/Javascript files to said Drive in order for the user to be able to read their logs in an user friendly way via their browser. This feature worked relatively well until now (notwithstanding some glitches due to server updates in the last few months).
2 weeks ago (.e. from the beginning of October 2014) we saw that the newer user interface of Google Drive has dropped the web host link capability altogether. For legacy accounts this feature is still there, but not for newer created accounts from the aforementioned date.
Does that mean that Google is planning to ultimately drop this feature, or is it going to be available for the foreseeable future, even if only accessible programmatically via SDK?
Note that we tested to see if programmatic access is affected, and it seems to work fine. We used java SDK function getWebViewLink() (class File) in order to get the link programmatically, and it still works no 1 for now. But the change in UI from Google does worry us that this feature will be dropped, like Dropbox dropped theirs recently. Is that the case? If so, what is the expected timeline of feature deprecation and eventual disappearance?
It looks like they moved/changed it but didn't remove it altogether. The instructions from Google on how to host webpages with Drive worked for me using an account I created after the UI change (after you posted this question).
Since their latest blog post on deprecating APIs does not say anything about getting rid of the web host feature, you are probably fine.
If so, what is the expected timeline of feature deprecation and eventual disappearance?
If the APIs they're deprecating are anything to go by, even if they do get rid of web hosting it will be a couple of years between the time they announce it and it actually being unavailable. It's not a perfect comparison since those are entire APIs and this is just a feature but it doesn't seem like they make a habit of making something unavailable at the drop of a hat.
I tried looking at some posts already posted but it did not help me
What I want to do
Use an SDK (preferably in java) to use in my own application
Scan fingerprints and save them as an image format (bmp,jpg or other)
If possible count ridges of the fingerprint (but this is secondary)
I was looking into different vendors/sdk such as
Digitalpersona
Futronic
Griaulebiometrics -> Griaule AFIS Fingerprint
OpenCV
SourceAFIS
Does one have experience to use any or few of them and which one should I will be able to use for my purpose
I understand SDK may be vendor specific and will be used for their hardware only or is there any other way I can just scan fingerprint and store as images?
You'll need to clarify your requirements before someone can recommend the best SDK for what you want to do. I'm not quite current on opencv modules but that and SourceAFIS have the benefit of being free at any project scale. AFAIK all the others are provided basically on a trial basis by biometric vendors who will eventually want you to purchase a license for every end user.
That being said any biometric scanner vendor should provide you (for free) with device drivers to get an image from their scanner. Typically you'll have to modify some sample C code to do what you're talking about, and without JNI it will likely be impossible to get a scan directly into Java. In my experience it's pretty easy to use a vendor SDK to dump an image into a BMP, so you shouldn't be discouraged even if your C skills are minimal. Of the scanner companies you mention I know that the Futronics sample application is quite simple to adapt to the kind of image acquisition you're looking for, and their basic scanners are cheap and robust.
Update:
Since the media side of JFX has been open sourced, I've looked into this myself and it is indeed possible, but requires changing and rebuilding the JFX source (both Java and C parts.) The process is described here for anyone that wants to have a go - I add MKV support in that example, but it should be very similar for other plugins.
The remainder of the question is thus mainly historical, but I'll leave it here for reference.
Background
I've been using VLCJ thus far for playing video in my application. It works, but if possible I'd like to see if I can achieve a similar level of support for common codecs by migrating to JavaFX and saving myself a lot of hassle with multiple VMs and suchlike that VLCJ needs to play multiple videos reliably. I won't go into it here but see my answer to this question if you're interested in the details. There's also the issue of cross-platform compatibility, it works on Mac and Linux ok but I haven't worked out how to get it to show on Mac yet (I believe there's some security in place to prevent one process gaining access to another's native components, but again that's beyond the scope of this question.)
It boils down to the fact that while it works, it's a lot of maintenance and hassle working with multiple VMs and bridging them stably if there's another solution that would be easier. VLC does have a pretty legendary level of support for playing pretty much anything which is why I've gone with it thus far, and I'd be interested to see if I can get a similar result in JavaFX - or at least if it can provide the means for doing so in a cross platform manner.
Research
JavaFX 2.0 supports video - great! But at the moment the official line is it supports "FLV containing VP6 video and MP3 audio". Is there a way to extend this to add in support for more codecs? There's no hard codec that I'd like to support, it's more a case of as many as I can so I'm looking for an extensible method to go about the above.
I wondered if it would play video for codecs installed natively on the machine and that it just doesn't advertise itself as such (because that functionality obviously is machine dependant and not cross-platform.) But no dice, I've tried a number of common formats and it really does refuse to play anything other than what it states.
From looking at JavaFX 1.3 it also supports other platform dependant codecs depending on where it's installed. Is there a way to get this behaviour with JavaFX 2? Or is it planned at all for a subsequent release? I haven't been able to find any information on it on the roadmap or any comment from Oracle about it.
Only thing I could find from searching extensively is here which implies that it may be possible but no-one seems to know how. I'd also be interested to know if it's based on GStreamer why all the formats supported by GStreamer aren't included by default either?
In terms of playing DVDs with JavaFX I've got absolutely nowhere, so I'm assuming that's just a no-go at the moment. If anyone does have any ideas or information though, I'm all ears.
Other approaches
One approach which I was half wondering may be possible is crowbarring the JMC jar out of the old JavaFX as described here and trying to get that working alongside JavaFX 2. I don't suppose anyone has had any luck with that approach or something similar?
All things failing, if anyone has any information or links on if / when support for additional codecs will be supported out of the box, then I'd be interested to hear that also. Or if anyone has any contact details for someone at Oracle I could ask that would also be appreciated! I've been longing for decent video support in Java for some time, and I guess what this boils down to is trying to figure out if JavaFX is the answer to this, or just another half hearted attempt that will never play more than what it does at the moment! I'm hoping it's not the latter, but I've yet to see much to show that's the case.
Believe me, I feel and know your frustration. I have pondered this for a while, but I had to use un-straight means of solving my issues.
There are many ways around this, each with limitations but depends on what works for you:
Docs say WebView works with HTML5, which plays videos supported on the platform (Though sadly not flash). If using a webview to play video works for you, you can try this out. You can even draw over it with other nodes.
Portable VLC Player! If maybe you're developing some sort of projector/director app and you want fullscreen video, you can have portable VLC player play the video in fullscreen in one screen with it's controls in the other. Used this solution and it works quite well for mac and windows. :)
Only thing is you can't draw nodes on the video as it's an external app, with just the illusion of fullscreen video of your app.
If you ever need to utilize the power of flash within your javafx 2.0 application, then use a swt-based browser(or something Like the DJ Project if you're a Swinger) as they support all features of your native browser.
I've now managed to compile MKV support into JavaFX successfully, and it does take some, but not a great deal of effort on the native layer also. See here for the discussion surrounding it, and here for the result submitted as a patch / JIRA ticket.
I've written a much more comprehensive guide on the process here which may be of interest to anyone else looking to go down this route.
What follows is my brief investigation before I actually seriously looked at compiling other media support in, though I'll leave it here for reference.
Now that JFX8 has been released and is completely open source, I've spent a bit of time looking at how this could be done, and whether it could be done without patching the JFX source. Unfortunately the answer to that latter point is an almost definite no, at least not without horrible bytecode manipulation hacks. I may look into this more practically at a later date, but I'll document what I've worked out so far from the source available.
The magic starts from the Media constructor, which is ultimately where the MediaException pops out from (with the MEDIA_UNSUPPORTED flag if you try to play an unsupported format.) From there it creates the Locator, whose constructor ensures that the URL is one that's supported. It's init() method is then called in a separate thread, which performs some sanity checking on the URL string, reads the file, then proceeds to try to work out what the format is.
The relevant code for this part of the method is thus:
if (scheme.equals("file") || scheme.equals("jar")) {
InputStream stream = getInputStream(uri);
stream.close();
isConnected = true;
contentType = MediaUtils.filenameToContentType(uriString); // We need to provide at least something
}
if (isConnected) {
// Check whether content may be played.
// For WAV use file signature, since it can detect audio format
// and we can fail sooner, then doing it at runtime.
// This is important for AudioClip.
if (MediaUtils.CONTENT_TYPE_WAV.equals(contentType)) {
contentType = getContentTypeFromFileSignature(uri);
if (!MediaManager.canPlayContentType(contentType)) {
isMediaSupported = false;
}
} else {
if (contentType == null || !MediaManager.canPlayContentType(contentType)) {
// Try content based on file name.
contentType = MediaUtils.filenameToContentType(uriString);
if (Locator.DEFAULT_CONTENT_TYPE.equals(contentType)) {
// Try content based on file signature.
contentType = getContentTypeFromFileSignature(uri);
}
if (!MediaManager.canPlayContentType(contentType)) {
isMediaSupported = false;
}
}
}
// Break as connection has been made and media type checked.
break;
}
From this we can see a first "dumb" attempt is made to grab the file content based on its name (this is what MediaUtils.filenameToContentType() does.) There's then some special cases for checking for different types of wav file, but if that fails then we fall back on a cleverer check which looks at the actual file signature. Both these checks are in MediaUtils. This latter check is much more extensive, and looks at the first few bytes of the file to see if it can work out a format that way. If it can't, then it bails out and throws the exception that then pops out as our dreaded MEDIA_UNSUPPORTED flag.
If the type is identified correctly though, there's still another hurdle to go through - it has to be supported by the current platform. Some platforms are loaded dynamically depending on the environment, however the GSTPlatform always exists, thus we would need to put any additional (universal) formats here. This is relatively simple, a CONTENT_TYPES array exists which just holds the array of supported formats.
Unfortunately cloning the JavaFX repo seems to be failing for me at the moment, otherwise I'd attempt to put some of this in practice. But in lieu of the above, what actually needs to happen to add support for further formats? It actually doesn't seem hugely difficult.
In MediaUtils, support needs to be added to the filenameToContentType() method to handle the new file extension. This is trivial.
In the same class, support needs to be added to the fileSignatureToContentType() method to work out the file type based on its signature. This is a tad more complex, but still not too bad. This may even be optional, since the current code only seems to use this as a fallback if the format isn't identified correctly (or at all) from the file extension. A comprehensive list of file signatures for different formats can be found here which should help with this task.
In GSTPlatform, the new content type needs to be added to the list of supported content types.
On the Java side of things, this appears to be all that's necessary to get it to accept the content type and at least attempt to pass it down to the native Gstreamer layer.
However, I'm no expert in GStreamer, so while I'm aware there's many more formats that it can handle and play that JavaFX currently refuses, I'm unsure as to how exactly they've removed this capacity. They've definitely done it in the Java layer above, but they may have also done it on the native GStreamer level - at this point I'm unsure.
I assume they've made some changes to GStreamer for JFX8 - but at the present time they're not listed on the relevant project page, so it's quite hard to work out exactly what they've changed for this version.
The next step would be to grab the JFX8 source, build with the above proposed changes for a new content type, and then see what errors (if any) occur on the native level, then take it from there.
The API design does not appear to have support for rolling your own codecs. Pretty much all of the classes are final (e.g. VideoTrack, Media, MediaPlayer etc). I assume that the actual video decoding is done with internal classes at present, meaning there is no way to override them.
There is a plan to Open Source JavaFX 2.0, I suspect as we approach the release of JDK8. Hopefully when they do this we can see how they resolve their codecs from the Media(String source) constructor and see if we can hook into this somehow.
And now, Javafx2.1 finally supports mp4 H.264 so you should now be good to go without the above posted stunts. :)
Current open feature requests for this in the JavaFX bug tracking system:
JDK-8091656 Wishlist for more media format support
JDK-8091755 Media should support InputStream
Read the linked feature requests and the associated comments on them to understand their current status (or lack thereof ;-) for the JavaFX distribution version that you are using.
Note, for the InputStream based Media API, one of the later comments by a JavaFX developer is "I propose we consider this for JDK 10", so I guess it may be a possibility in the future...
Also note, if you are not sure if JavaFX currently has in-built support for a given encoding type or not, a comprehensive overview of supported media encodings and media container types is provided in the javadoc for the javafx.media package (just ensure that you review the version of the javadoc which matches your version of JavaFX).
Those who may be interested in other solutions to at least get a video to play from JavaFX, even if it is a media type not natively supported by JavaFX and you don't want to hack the native JavaFX media support just to get your video to play, can also see my answer to the related question:
Playing h265 HEVC in a JavaFX client
I’d like to write a simple program that reads a barcode, and makes a note of the barcode as well as the time it was scanned in. Unfortunately I cannot guarantee that the program will have focus when the code is scanned. My understanding is that most barcode scanners act like a keyboard so if the program does not have focus I will have issues. What are the ways to deal with this? Note I’d prefer to code this in Java but I can use .net if the libraries make it easier. I also don’t have a specific scanner in mind so if one model will work better for this that info would be appreciated. I’ve sceen this question but it assumes the app has focus.
Most barcode scanners behave like a keyboard, hence requiring the processing application to have input focus. There are however also barcode scanners, which connect to the serial port or are connected to the USB and offer a virtual serial port interface.
These scanners must be accessed through the real or virtual serial port. For Java, you will need to use the Java Communications API or any other 3rd party library offering access to the serial ports, since this is not possible with the standard Java API.
Most keyboard wedge barcode scanners can be configured (via configuration barcodes) to emulate a keypress of a function key before sending the barcode data. The Windows API includes a RegisterHotkey function to define system-wide hotkeys. When the hotkey is pressed, you could give focus to your program's window to read the barcode.
A Google search reveals a library to register system-wide hotkeys from Java. There's also a question on this site about it, which seems to suggest that there isn't a publicly available library to do so in Mac OS X, though one of the answerers posted a link to such a library he was developing.
After some research on this I implemented as jarnbjo mentioned with a virtual serial port, an example is here (see my answer).