Server side image maps predate javascript. They were in early versions of Mosaic.
Client side image maps and the script element were (AFAICT) both introduced in Netscape 2.
Even when scripting was introduced, you didn't necessarily have the ability to move elements around freely on the page. I think (but I'm not certain) that it wasn't until Netscape 4 era that you had enough layout primitives to implement the multi-layer positioning approach to custom clickable areas.
But only square hit targets then (until clip paths much later). Image maps supported polygons and circles. And position absolute is still a few years after image maps.
The only time I ever needed dreamweaver: I found an open source imagemap of the US states and I needed to scale it to match my background image of the US provided by an art director. Dreamweaver let me see all the <area>s easily. Maybe there was another way to do it. Fun fact: the art director wanted states to grow on hover, but acquiesced to having them change color when I pointed out how impossible it would be to click on Rhode Island if you'd hovered Massachusetts first. I don't even know how I would have done the grow effect, tbh.
I was a naysayer before I had kids, too. I now am able to get a first person view of Scratch usage through my child who likes the platform very much.
What's missing in a lot of these discussions about Scratch efficacy is the community aspect. Kids like getting a response in the comments section from their peers and many of the alternatives proposed don't have that. Without an active community, a lot of kids might never use the alternative despite being "better". In the case of Scratch (unlike Khan academy, which he completed also), he keeps using it, keeps trying things and keeps coming back because of the rewarding community interactions.
My kids showed more interest in BASIC GOTO 10 on an emulator than school Scratch.
I think it is a decent programming paradigm but really just teach 6502 binary code entered by flipping switches and blinking lights and let only the children who love it go on to learn programming and computer science.
A while back, I powered up an Atari 800, and she was fascinated.
10 Input "What's your name?", N$
20 Print "Hi, ";N$
She was asking questions, trying out things. Something about that simple, imperative, dynamic type of language connects in ways that most conceptually purer and more powerful languages just do not. Python was close, but then it swerved.
My b&w laser from brother has been working perfectly for over 10 years. No software installation. Wifi, Ethernet, or USB. Everything I need and nothing I don't. Color would be nice but I've never seen it be worth the hassle to own.
I, at this point, use Qwen2.5-VL-3B-Instruct for most of the small OCR I want to do. It is much much better than my experience with Tesseract in general. The nice thing about it is that if you give it, say, a movie poster you can ask for the "title of the movie" and it will, to the best of its ability, do just that, no need for regex or filtering after. For smallish images after loading the 3B model runs in <1 second. 7B takes longer but is obviously more accurate.
I might be a bit behind, all of this is from early this year for the most part, but for something like "I have 3000 movie posters and I want to get the titles with like 90% accuracy" it is good (much better than Tesseract), and it'll do that in like an hour.
EDIT: I guess one thing is Tesseract will kind of give gibberish back when it fails. The main issue with the LLMs are that instead they take a stab at it (like for a movie poster it'll give part of a quote, or a actor name) back. Makes knowing when it fails a little harder. As long as you have some way to verify when it is likely failing they are very good though.
Its much lower and the error rate is much higher. It works, but for our usecase, "clean rendered text" (extract from kindle for example) tesseract is much better.
Definitely not. Even Chrome has a built in OCR that performs amazingly. I got an LLM to write a quick python wrapper to it [1], so I'm sure you should be able to access it from an extension
For the input text rendered on screen, Tesseract did better on both accuracy and speed. We got about 0.1% character error vs 1–2% for RapidOCR, and Tesseract was roughly 2.5x faster. Blur was the biggest difference: 0.4% vs 14%.
The big problem is that this is synthetic rendered text, which is basically the easy case and also the only kind of input this extension captures. I wouldn't assume the same results for scanned documents.
