Develop Reference

Tesseract in a specific information

I want to scan a Spanish DNI ang get some information and print it in the screen. A DNI has this form: 1
And i want to take the fields DNI, Nombre and Apellidos (in the image, it would be 99999999R, CARMEN, ESPAÑOLA ESPAÑOLA).
I thought that the best way is using "cut tool" and use the OCR in the cut images. What do you think? I have to make the project in HTML/JS and I don't really know how to program this.
Thanks.

This is not an easy task and to do it, you need to do the following:
Make sure you "cut" the image precisely around the borders. This method needs to be robust to lightning conditions, low contrast situations, etc. Ideally, it should use advanced computer vision and ML techniques
Then you need to define where the individual fields are. This is also not an easy task, because the sizes and positions of the fields vary between different IDs.
In the final step, you need to have a very reliable OCR tool, one which would give you a low error rate, so that you actually have a benefit of doing this automatically, compared to just retyping all these fields manually. Although OCR seems like an easy problem today, it's still very hard, especially on ID documents which can be worn out and damaged and taken in weird lighting conditions.
My company Microblink has spent years working on ID scanning, not just for Spanish DNIs, but also for many other document types (there are more than 5000 different types in the world).
If you are interested in reading how we're doing it, here are some of the materials:
Goodbye Templates
BlinkID v5
From OCR to DeepOCR
As for the "cut tool" - we do have a feature that allows you to automatically capture the image of a document and crop it around the edges of the document. We call it "Document capture" and it's a part of our BlinkID SDK.
As for the HTML/JS - it's not clear what exactly you need, but we do have a React Native and Cordova plugins which allow you to build cross-platform mobile apps in JS, and we also have a Frontend SDK and Web API which allow you to scan documents in any browser.

JS - How to update DOM in realtime across multiple instances of the same web app?

I am building a massive real-time collaboration web application. It is a Web IDE that has support for HTML, CSS & JS programming and a stage area that would reflect the results a la JSFiddle, Plunker etc.
Now, the twist is that, it would support multi-user real-time collaboration, where people viewing the same instance of the web application would be able to write code together that would reflect across all the open instances. I have figured out the race conditions, session management et al
What I am having trouble with is
how to reflect the typing and/or deleting along with caret positioning
across these multiple instances giving the illusion that when one
person is typing, he is actually typing on all the instances.
The other thing is that RactiveJS says that it
updates only those parts of the page that are out of date. Tedious DOM
manipulation is a thing of the past.
Which is a very nice effect in their Demo. Imagine, you are on JSFiddle and you don't have to re-run every time. So, my question is, how do they do it? What is the concept behind it?
I don't want to use any library for this. I am pretty good in JS. I am having a hard time figuring out the algorithm.
Things I have considered:
Dirty Checking [but, its dirty right?]
Delta Differencing [but like ReactJS, it would have to update the entire application state every time]
Object.observe [the browser compatibility is not realistic yet]
So, if you have anything that can help me go in the right direction, I would be really thankful.

Realtime-collaboration tools, that allow concurrent editing/manipulation of objects/texts etc, usually use a variant of the Operational Transformation algorithm.
OT is not trivial to understand, much rather implement so I'd suggest you take a look at already-cooked libs for this such as:
ShareJS
Racer for Node
OT works, in some very basic way, similar to GIT
As an update to what you posted in the comments.
You say you are using Python. You wouldn't rebuild your whole codebase, I guess, but keep in mind that real-time collaboration tools usually benefit a lot from using an event-driven server-side language.
Since you are using Python, you could check out the Twisted Framework

Starting game development in javascript. Where to draw the line between JS and Server Language

Im fairly proficient in php and am also learning python. I have been wanting to create a basic game for some time now and would like to create it in python. But in order to have a fancy smooth interface I need to use javascript (i dont much care for the flash/silverlight route). So I decided to start looking up game development in JavaScript. And in doing so most of the examples I have seen are games nearly completely done in javascript. And many of these games are quite nice.
But what im wondering, is if i combine python and javascript together for creating games; should I rely more heavily on javascript and let python do some of the background stuff? Or should I only use javascript for the basic UI elements, animation, flashy stuff and whatnot and keep the core game engine in python. Or some kind of mix between the two.
For php/python im mostly used to MVC style frameworks. So if i used JS only for the visuals would I just make heavy use of the in the view files as I would with a normal application? I know I can make a game in either language completely, but to use the best of both worlds im not quite sure where I should draw the line on letting python do work and letting JS do the work.
Also as a reference I would like to use some advanced features like canvas/svg and so on. Not really so much WebGL. And the game I have in mind to practice on is an isometric style RTS. The game will mostly be for learning. Im not really planning on releasing it.
Any input is appreciated.
Clarification:
the game will be web based. My web server is nginx. The games i would like to to would be multiplayer games where multiple people are playing online at the same time. Think world of warcraft. each server could hold up to N players that play against eachother. When that one is say 80% full a new one is spun up. Or something along those lines. I would like for the players to actually be able to interact with eachother live. Which is why in same ways i was also kind of looking into node.js but dont know as much about it yet. but seemed like it could fit.
--
Update: Im also planning on using mongodb as the database, if that matters to anyones answer.

to a certain extent, the problem can be considered in terms of economic forces, where you maximize your own utility and minimize costs. In the case of a game with a client/server aspect, The actual forces acting on you are
consuming server resources costs you actual money, but consuming client resources doesn't
clients could try to cheat, so you have to validate some of the data coming from a client
if you consume too much client resources, clients won't want to play, since their utility is outweighed by their costs.
Each of these points can be subtle enough to merit some additional discussion.
The actual cost of getting your game to clients comes in two parts, the cost of the physical hardware necessary to run the game, and the cost of the network bandwidth to distribute it to clients. Often you might have to trade one for the other; optimizing network usage means you have to be better at anticipating what clients will need or do, increasing processing demands, but offloading more of processing the work to the client means sending more data to the client.
There's only so much work the client can do, though. For instance You can't always trust the client to tell you where they aught to be, because that might mean that they are flying around in the air, or teleporting from place to place; You have to actually make sure that clients actually can do the things that they say they're doing. The particular nature of the game can determine how far you have to go, though. In man MMO games, extreme measures are often taken to limit the activity of bot players, but that often has a negative affect on real players. Strictly cooperative games often suffer less even when abusers are at work.
Not all potential users of your game have the best available hardware, or are willing to upgrade to the latest, fastest browser, So to make a successful game often means toning down the graphics enough so that a majority of users can play it.
Surprisingly, it's often the case that an either client or server approach doesn't actually produce the ideal results. Instead you have to implement key game logic in both places, On the client so that the game feels responsive to the user, but also on the server to mitigate abuse and decide player to player interactions fairly.

python would probably run on the server powering your web server.
If you want to write multiplayer client-server games then a lot of server code/logic would be in python.
If you want to write simpler singleplayer games then all your code is in the client (browser) and would be javascript. Python would just be there for serving your web game.
If you want to write desktop games you can do that in python using the pygame library.
So depends on what you want.
Multiplayer web game : client in JS, server in pythong
Singleplayer web game : client in JS, server only for serving web files
Desktop game : client in python.

Real-time collaborative drawing whiteboard in HTML5/JS and websockets?

I'm trying to put together a small(ish) summer school project for some of my advanced students and am researching how to do it best and what to use - hopefully somebody here could point me in the right direction.
What we are interested in is researching if HTML5 came far enough to create a real-time collaborative drawing whiteboard in it - purely by using web technologies without plugins (so CSS, HTML5/DOM and Javascript). What we'd ultimatelly strive for is this - for example have an online canvas/page on a central server displayed on a big screen in the classroom. Then our students/users would take out their smartphones, load the page in their mobile browsers (I'm perfectly ok with limiting this to webkit mobile browsers for now) and draw on their screens with touch/fingers (or on PCs with the mouse - guessing this doesn't make a lot of difference) and it would get updated in real time for everybody - both on their screens and on the central big screen in the classroom.
I'm guessing push/get requests would be too slow for this - could it be solved by websockets? Does anybody have any good JS libraries to recommend for this?
Also what would the ideal (but easier for students to understand) architecture look like. Lets say you have 30 simultaneous users in a clasroom - each of them would connect with websockets to the server and the server would pool/combine all of their requests into one and then return the combined file (some sort of minimal JSON or even just coordinates) for every connected user?
Would websockets and (I'm guessing) canvas be able to take this? So that everything still looks snappy? Are there (jQuery-like) JS libraries available to make our lives easier - or do you think its something thats too complex for a 2-week summer school project?

here's a tutorial describing how to create a multiuser whiteboard with javascript/html5/canvas:
http://www.unionplatform.com/?page_id=2762
the example uses a collaboration framework and server named "union platform". even if you decide to roll your own server and client framework, the messaging in the example should give you an idea of how to structure the code.
for an apples-to-apples speed comparison of websocket vs comet, see:
http://www.unionplatform.com/?page_id=2954
in my tests, a basic ping over WebSocket is normally about twice as fast as the ping over http. both websocket and coment are more than fast enough to create a collaborative whiteboard.

Definitely check this out:
http://wesbos.com/html5-canvas-websockets-nodejs/

For the networking side of things, try looking at node.js for the server, along with socket.io for the client.
As for the drawing itself, a few popular choices are processing, raphael and cakejs.
When it comes to the implementation, you may want to look at how networked games deal with similar issues (gamedev.stackexchange.com could be useful).
What you are going to be doing is essentialy the same as a simple top down multiplayer game, with each 'player' in this case being a students fingertip, and the 'level' being the canvas. You need to update the server as to their position and whether or not they are 'shooting' (drawing).

I'm guessing push/get requests would be too slow for this - could it be solved by websockets? Does anybody have any good JS libraries to recommend for this?
If you need real-time infrastructure I've created a list of real-time technologies which might be of use to you. These include hosted service, such as Pusher who I work for, and self-install technologies such as WebSocket and Comet solutions.
WebSocket sounds like the idea choice of technology for you since they have become part of HTML5 and offer the most efficient for of realtime bi-directional communication between a web server and a browser (or other clients).
Also what would the ideal (but easier for students to understand) architecture look like. Lets say you have 30 simultaneous users in a clasroom - each of them would connect with websockets to the server and the server would pool/combine all of their requests into one and then return the combined file (some sort of minimal JSON or even just coordinates) for every connected user?
It sounds like you should probably store the current state somewhere and on the initial load of the application display that state. Then use your real-time infrastructure to send deltas on that state, or if it's a drawing on canvas, just information on the line etc. that has been drawn and information about who drew it.
Would websockets and (I'm guessing) canvas be able to take this? So that everything still looks snappy? Are there (jQuery-like) JS libraries available to make our lives easier - or do you think its something thats too complex for a 2-week summer school project?
Real-time collaborative drawing is most definitely achievable and there have been a number of examples created of this. A google bring up a number of possibilities.
If this technology is completely new to you and you would prefer to concentrate on building the collaborative application then I would consider using a service for your app rather than going through the hassle of learning how to install and configure, or even code, your own infrastructure (I'm not just saying this because I work for such a service. I honestly think it makes the most sense).

Importance of graceful degradation to non-javascript ui

How important is it to gracefully degrade or inversely Progressively Enhance the UI experiance? I mean am I going to lose a LOT of business if I don't? Do you practice this concept? Are there any web 1.0 users still left out there?
Please could you also include if you practice this personally and how much time you've spent relative to the entire project. I realize every project is different, I want to get a sense of how much time as a general rule I should be allocating toward this goal.
EDIT
Firstly, i'm looking for guidance around how much time I should be devoting to making my applications run without javascript.
Secondly, the BS term "web 1.0" (...lol... I don't really like it either) works because we all understand that as the iteration before ajax and all its goodness.
Thirdly, the kind of applications I'm describing are the ones we are all building, not Facebook, not Twitter (unless you're from Facebook or Twitter) but service or utitlity programs like a web calendar, or an online todo list or [INSERT YOUR APP HERE].

Progressive enhancement is more a mindset than a particular task that you need to allocate time to. If you're doing it right (and if it's important to you), you should be enhancing the user experience with JavaScript, but not relying on it.
For example, a link will point to a new page, but with JavaScript you'll disable the link and load new content into the current page with Ajax. Start off without JavaScript and progressive enhancement will follow naturally.

Progressive enhancement is not only smart but it is faster and easier to develop.
And at each stage, you almost always have a working fall-back.
Here's what it looks like in a nutshell:
Boss/client approves mock ups.
We code to valid HTML output. At this point, the boss/client can start using the site. Baring any boss/client changes, the HTML is mostly done. The site is usable at this point.
We start tweaking the CSS to make it match the boss/client's graphic expectations. Changes to the HTML are minor, if any.
In parallel, JavaScript is added to do non-critical, but nice, things. (Sort tables, Fancy CSS helping, replace some links with AJAX calls, warn the user -- client-side -- of input problems.)
If any one of these things breaks, the site still works.
Also, little, or usually no, html changes are needed.

First of all, lets not start using bullshit terms like "web 1.0" and "web 2.0" etc, the fact is the web is forever progressing and new websites are starting to use JavaScript to enhance the user experience.
I don't know anyone that doesn't allow their site to gracefully degrade when JavaScript isn't available, this is for the same reason we use semantic markup so screen readers can correctly interpret our websites for users with visual impairment, and whilst the vast majority of your visitors / users won't fall into these categories it's still important to think about the minority.
Will you lose a LOT of business, well that depends on how successful you are now and how badly your site degrades, chances are you probably won't lose any business... but that should not be the measure yo use to decide whether to gracefully degrade a website.
So unless you can come up with a pretty good reason, you should probably use JavaScript for the purposes of progressive enhancement, don't depend too much on it.
:-)

This greatly depends on the nature of your aplication and its data. If it's something that you know will be mostly used via computers, than degrading to non-script version UI wouldn't make any obvious benefit (even loss of money because it will take considerable time to develop). You can always tell people to enable javascript in their browsers (similar to what's done here on Stackoverflow - try disabling script and reload the page). Your app/site should display at least something when there's no Javascript posibility.
But if your application has simple data to display and users should access it frequently wherever they are, than degrading to lesser browsers (without script engines like Opera Mini) is a must. Creating a separate UI will less functionality, but keeping everything in that users need to access is probably your best option. UIs like separate iPhone applications for example...

JavaScript is disabled by a small proportion of web users, but when you start to talk big volumes this can make a difference. For example for 1 million visitors, you can expect more than 10,000 not to be able to user your site.
You should decide how much lost business is worth the additional cost of having a non-JavaScript version of your site.
You can have an approach where the entire site may not work without JavaScript but that some of the core features are there.