On 8/26/21 5:14 PM, Ray Jewhurst via cctalk wrote: is a card-driven don't boot My Cards are just ASCII lines separated by newlines> For more information, see: https://www.yumpu.com/en/document/read/3610586/ibm-1620-simulator-usage-01-…

It's been years since I used the SIMH 1620 simulator, so I can't even claim to be remotely current. I used it to check out some sample code back then. My reaction: It's just not the same. I guess you had to be there. Did anyone manage to snag a copy of Monitor IID? Or is the only extant version Monitor I? The differences were significant.

Also, don't forget SPS!

If you're new to the 1620, I recommend the following book: http://bitsavers.org/pdf/ibm/1620/Basic_Programming_Concepts_and_the_IBM_16…

If you want to use a totally (i.e. no disk) card-driven version of the 1620, I'd recommend that you start with simple machine language programs. I (dimly) recall that using the card-only FORTRAN compiler was a bit of a chore: read pass 1, read your program, while punching an intermediate deck, read pass 2 and the intermediate deck, read the subroutine library and wind up with an executable deck.

--Chuck

There was a professor at Purdue who had two 20-drawer card cabinets full of 1620 software. I think his name was Maniotis. I think the Computer History Museum in Mountain View has it now. Maybe it's online.

On Thu, 2021-08-26 at 20:17 -0700, Al Kossow via cctalk wrote: Should be http://bitsavers.org/bits/IBM/1620/1620.zip

For material such as the RSX manuals you mentioned, the tool needed is a compression algorithm that handles color with hard edges faithfully. Basically that means a lossless compression scheme. That should be fine, since pages like that should compress very well, at least if the scan has been touched up just a bit to make the page background reasonably pure white.

On Aug 27, 2021, at 5:19 PM, Al Kossow via cctalk <cctalk at classiccmp.org> wrote: Probably the way to deal with DEC tri-color would be to define rectangular regions and have three separate bitonal layers colored black red and blue, and a third JPEG-2 for grayscale or color images. Doing the layer separations would be the non-fun part.

On 27/08/2021 22:10, Al Kossow via cctalk wrote: I did see it, but it didn't look like a cookie-cutter recipe. I'd be happy to be proved wrong though. What I don't want to have to do is manually process each page (beyond having to decide which to scan in colour). I would be looking for an algorithm or process that I can just point at scanner data for a page and have it spit out the optimised PDF page. I'm sure that will appear at some stage, but I don't think it exists yet. The RSX-11M/M-PLUS Error Logging Manual, for example, has somewhere between 20 and 50 pages with colour present. I can pick those out and re-scan them and I can relatively easily merge those pages with the original B&W scan, but if I have to manually examine each page, I'll never make it to whatever manual is in my list after that one :-) Thanks, I'll look into tumble. Antonio -- Antonio Carlini antonio at acarlini.com --

This isn't a default part of Debian distributions, and apt-get can't find it. I found it on github https://github.com/brouhaha/tumble I had to install several packages that are not default parts of Debian "Buster" 10, such as bison, flex, libtiff-dev libjpeg-dev libnetpbm11- dev I wasn't able to compile it on Debian "Buster" 10. Ultimately, "make" gave up:

JPG is the wrong tool for pages with color text or color line art. As I've mentioned before, JPG is fit ONLY for photos, not for any image with hard edges. Text compressed with JPG will suffer badly.

On Aug 27, 2021, at 8:32 PM, Paul Koning via cctalk <cctalk at classiccmp.org> wrote: ... TIFF is (normally) lossless. I think PNG also, or at least can be, but I don't understand it as well.

On Aug 27, 2021, at 8:55 PM, Al Kossow via cctalk <cctalk at classiccmp.org> wrote: I was also just thinking you would probably have to have a layer (black) with all of the stuff to OCR including the stuff in red and blue, then overlay the color on that after the pass through whatever you're using to do the OCR. The one bottleneck I would really like to fix is getting the 24 cores on my machine doing OCR on 24 different pages at the same time.

I didn't see an obvious example of ocrmypdf doing OCR in parallel on a single document

I have a few manuals to scan and I'm looking for suggestions, about how to add bookmarks and how to handle colour. Bookmarks should be easier, so lets start with that. I want to add bookmarks (or whatever they are called) so that it is easy to navigate to page "2-48" or "C-17" in a document. Many of the PDFs on bitsavers have that and I've found it very useful so I'd like to do that for my future scans. I've tried with pdftk (the Java port as the original is no longer available on my distro) but that failed. So I tried GhostScript and that also failed, while also rewriting the PDF to be considerably larger. Is there simple way to achieve this (ideally from the CLI)? Now for the scanning itself. For manuals that are simple monochrome, I plan to scan at 600dpi bilevel G4 encoded, wrapped in PDF. For photographs or shaded areas that don't necessarily come out well under those settings, I plan to use 8-bit greyscale. I'd prefer to use 600dpi but I may have to fall back to 300dpi if the per-page fiile size shoots up too much. The real issue is colour. I know that various people have looked at the issue of how to efficiently scan pages that are mostly black and white but have some coloured text (RSX-11 manuals and early VMS manuals did this to highlight terminal input, for example). I don't think this is a solved problem and I'm not expecting a solution, what I'm really looking for is to check that what I'm about to produce will have all the information that a future efficient algorithm is likely to need. I'm going to start by scanning the whole manual as though it had no colour (so 600 dpi bilevel G4 encoded, except for pages with photos and shading and so on). Then I'm going to go back and rescan the pages that have colour and scan those at 600 dpi and save as a JPG. Then I'll produce a final PDF with the colour pages inserted. I'll also produce a PDF with the B&W pages that were replaced by colour pages (I assume OCR will be better served by non-jaggy scans). So the final outputs will be: manual.pdf? - the whole manual, including whole pages scanned as colour if any colour is present on them manual_BW.pdf? - the G4-encoded bilevel pages that were replaced by colour pages Thanks Antonio -- Antonio Carlini antonio at acarlini.com

i've achieved satisfactory results paletteizing scans of low-color-depth material using a tool called 'noteshrink': https://mzucker.github.io/2016/09/20/noteshrink.html

I always fail to understand this ... With prices for hard drives like they are, and comparing to the amount of work, it really is to scan a manual, I would recommend to scan with the best resolution you have, and have those files as you "original scans" Than, you apply whatever tricks you have in your bin, to "publish" those scans.

Probably, one day there will be a nice tool, to do whatever you expected, and you have the scan already on your drive, and the original manual is digitized and preserved already.