Thank you for uploading a decent quality scan, Brian! This is something we’ve been needing.
I’ve created a much smaller version of the PDF <https://gist.github.com/hackerb9/4b993d3e204a0eb0e46859a276b22fee/raw/59f26ba22962e78005fee4ee18fec42bdab570e0/TRS-80_Model_100_Portable_Computer-jbig2.pdf> (40 MB instead of 2 GB) by using JBIG2 symbol compression. pdfimages -all TRS-80_Model_100_Portable_Computer.pdf page jbig2 -s -p page-*.jpg jbig2topdf.py output > jb2.pdf - *+* Relatively small filesize - *+* I took the time to fix the page numbering - *+* I added metadata (title, date, subject, keywords) - *+* Color covers retained - *+* Has (preliminary) OCR - *-* Not as nice on the eyes as BKW’s original scan (Also, the image on page 8 is a tad funky.) - *-* No PDF Index (list of sections in the sidebar) - *-* No hyperlinks (Table of Contents, Index) - *-* OCR should be touched up by hand (see https://ScribeOCR.com/) ------------------------------ JBIG2 is inherently 1-bit, so the jbig2 encoder automatically thresholded the pages in a reasonable, but not perfect, manner using a Local Adaptive Threshold. LAT uses a sliding window to calculate a different threshold for each pixel based on the region around it. The strange light areas in what should be a large black area on page 8 are the kind of errors one sees from LAT, but it’s worth it as it is more likely to find faint and thin lines. For fun, I played with the LAT algorithm built into ImageMagick to see if I could make a 1-bit image that retains those thin glyphs of page 214: convert p214.jpg -lat 100x100-5% p214-lat.jpg You can see the results here: - Original page 214 scan <https://gist.githubusercontent.com/hackerb9/4b993d3e204a0eb0e46859a276b22fee/raw/x-p214.jpg> (2,375,826 bytes, grayscale JPEG) - Local adaptive threshold <https://gist.githubusercontent.com/hackerb9/4b993d3e204a0eb0e46859a276b22fee/raw/y-p214-lat100-5%2525.png> (149,696 bytes, black-and-white PNG) Note that the binary PNG file is much smaller at 6% of the original JPEG size, but compressing with JBIG2 <https://gist.github.com/hackerb9/4b993d3e204a0eb0e46859a276b22fee/raw/z-p214.jb2> can do even better at 1.5% (35,353 bytes)! —b9 On Tue, Jul 14, 2026 at 4:19 PM Brian K. White [email protected] <https://mailto:[email protected]> wrote: On 7/14/26 18:55, Brian K. White wrote: > > On 7/14/26 16:22, Brian K. White wrote: > >> On 7/14/26 16:08, Brian K. White wrote: > >>> On 7/12/26 20:46, Joshua O'Keefe wrote: > >>>> > >>>>>> On Jul 12, 2026, at 8:52 AM, Joshua O'Keefe > >>>>>> <[email protected]> wrote: > >>>>>>> It resulted in a file under a meg. > >>>>> > >>>>> Correction: "under a *gig*" > >>>> > >>>> My apologies to the list for continuing to reply to myself but it > >>>> might be helpful to post my first pass at making the file a little > >>>> more manageable: https://archive.org/details/trs-80-model-100- > >>>> portable- computer-ocr-compressed <https://archive.org/details/ > >>>> trs-80-model-100- portable-computer-ocr-compressed> > >>>> > >>>> If anyone finds issues, I'd love to hear about it. > >>> > >>> > >>> That is a great looking copy, still looks perfect while being half > >>> the size. > >>> > >> > >> Wait I sold you short. half? 1/3rd! > >> > > > > ...and looks like I missed some things still. > > pg 208/215 chr 226, the glyph is fine but the keystroke has an @ and the > > @ is half missing. > > > > Never mind! It's like that in the physical print! > > But that's another problem with highly optimized post-processed scans > too. Any defects look like a bad scan or bad post-processing. > > With an unadulterated and lossless version at least you can see that you > are looking at all there ever was, nothing destroyed by threshold levels > or compression artifacts. > > -- > bkw >
