PDF reader

[cjbaker]

Hello. I'm trying to find a PDF viewer that works in System 6 or 7, preferably on a 4MB 68000 machine (Plus or SE). I've tried various versions of Acrobat Reader from 1.0 up through 4; the older ones display unhelpful errors when trying to load any of my PDFs, and the newer ones require an '020. MacGhostView 3.2, the only version I can find, seems to require 8MB of memory. Does anyone know of a program that works well? My PDFs are a few pages of black and white text, with a couple of graphs and diagrams. Would be nice to use my classic Mac as a reader!

It could be that these memory limitations don't really allow PDF rendering. In order to get an idea of how much memory a PDF renderer might require, I tried running an open source viewer called MuPDF under valgrind's "massif" tool in Linux. MuPDF is described as a very lightweight PDF library. The total memory usage seems to range from 6 to 8 MB. I'm not sure if anything might be done to reduce MuPDF's requirements, for example rendering to B&W without antialiasing rather than greyscale, and drawing with QuickDraw rather than whatever MuPDF is using in this X Windows version. They also have OpenGL and MS Windows front-ends, so it seems fairly portable. In any case, it seems to me that memory requirements are at least in the right ballpark for running on one of these machines.

Thanks! -Craig

 

[MOS8_030]

Howdy!

The errors you get when trying to view PDF's are likely because the PDF's were made with later versions of Acrobat (or other app) and aren't compatible with the earlier Acrobat Reader program.

The only way I could see it being practical to use your 4mb Mac to view PDF's would be to convert, if possible, your PDF files to make them compatible with the old versions of Acrobat.

Which would require running a later, full version of Acrobat on another computer.

But even then you may still have issues with memory limitations.

You can run a "slimmed" down version of OS 6/7 and pick up a few extra K of memory but that's about it.

 

[cjbaker]

Thanks for the idea, I'll see if I can convert them to an earlier version. Another idea I had was to convert them to a big bitmap, maybe I can find a program that is convenient for scrolling and zooming around one.

 

[cjbaker]

I've made a few efforts with downgraded PDFs, none successful. I figure I'll note them here in case anyone else goes down this path.

Acrobat Reader 1.0 is the only version that seems to run on these machines. Version 2.0 requires an '020. PDFs come in different versions; it seems that the usual version today is 1.4, but Acrobat Reader 1.0 uses PDF version 1.0.

The ghostscript package on Ubuntu has a program called ps2pdf which can convert a Postscript file to PDF versions 1.2, 1.3, and 1.4 . I converted my test PDF through PS and then to version 1.2 with ps2pdf, and Acrobat Reader 1.0 gives the same error as with the original document: "An error occurred while processing page resources. (19)" It does display the correct number of pages (six), all blank, and repeats the error if I scroll around. This is in Mini vMac with System 7.5.5, by the way. Note that this downgraded copy of the PDF displays fine in modern viewers (Preview.app).

I tried converting the PS to PDF using Acrobat Distiller 2.1 in MacOS 8. It seems to read and process the Postscript file, but then says the output is empty, and does not output a PDF. No idea which PDF version this might output if I could get it to work. Maybe I could find Distiller 1.0 but I assume it would be even more picky about the PS input.

Anyway, I'm giving up for the moment. I'll try rasterizing them to B&W PICTs, and see if I can find an image viewer with scrolling and zooming that work well enough to function as a reader.

 

[dcr]

According to the "Read Me" I have for Adobe Acrobat™ Distiller™ 1.0.2, it says the PostScript file needs to be a valid PostScript file.  It says to make sure the file will print to a PostScript printer and prefers it to be a Level 2 PostScript printer.  The second thing the "Read Me" says is that the fonts used in the PostScript file must be either included in the file or otherwise available to Distiller.

PostScript 3 was released in 1997, so if the PS file uses PostScript 3, that may cause problems for earlier versions of Acrobat Distiller.  Acrobat Distiller 3 came out in 1997, so I would imagine version 2.x and earlier would probably not support PostScript 3.

So if either the fonts aren't available or the PostScript files use PostScript 3, that may be causing problems in trying to downgrade them to earlier PDF versions.

 

[cjbaker]

Thanks for the tips, dcr. I tried converting my PDF to Level 1 PostScript using `pdf2ps -dLanguageLevel=1`, also a part of the ghostscript package. I managed to find a copy of Acrobat Distiller 1.0 and ran it in OS 8 (it requires an '020). I get this error in Distiller's log: %%[ Error: ioerror; OffendingCommand: image; ErrorInfo: DCTEncodeFilter Premature close before EOI ]%% and no PDF is produced.

At least this points me in a direction for troubleshooting. I might have to take a look directly at the PostScript source, and see if I can remove or modify any image commands. The document doesn't really have any obvious rasterized images, it is just text and graphs.

 

[techknight]

yeap it all goes back to scripting language/syntax advancements over the years. 

If I am not mistaken, PDF is based on PS so the language needed to render the document has advanced over the years so it has to be backported. 

If there still were willing developers it would probably be easier to take a modern PDF/PS engine and just backport/compile for the older OS. 

But this also means coding around libraries that it could be dependent on that dont exist, and then of course the C syntax itself has changed as well, it too would have to be back-ported to earlier C compilers. 

Unless there is a modern version of GCC that could handle early macs which I think there is a project here that does this. Then its just a matter of going through all the required libraries/dependencies and coding around it, and then converting graphics calls back to old QuickDraw calls.  

 

[PowerPup]

My guess is you're probably thinking about the Retro68 project for GCC: https://github.com/autc04/Retro68

The MuPDF library would be a potential candidate for porting to classic Mac OS, it is written in "portable C" (no external dependencies and modular components.) https://mupdf.com/

Ack, if only I could focus on classic Mac programming projects after graduating this May, instead of needing to find a Software Engineering job.

There's just too many cool ideas:

• Update MacSSH with modern encryption library/algorithms
  
• Modern PDF viewer that will run on Mac OS 6/7
  
• Develop an Open Source replacement for Stuffit using newer/modern compression algorithms. (Personal project/idea.)
  

 

[techknight]

I think MacSSH for me is the most important right now. I use the terminal to get into my Server, and Pis all the time for all sorts of things so it would be cool to use a vintage mac to do this as well, Put it to use. 

PDFs I could care less honestly but it would be sort of cool to backport something. 

with MuPDF you would still need to write the Mac specific UI code/toolbox stuff, as well as the QD code for rendering/displaying the PDF. 

 

[cjbaker]

Yes, I've been trying to get MuPDF to compile in Retro68. If I can get it going, I'll post it to Github. First I'll do it without any graphical output, just to see the memory usage and feasibility of getting it compiled. MuPDF has an example of outputting to a sort of ASCII image (like ASCII art) with no graphical front end, which should be a good way to try things out. I notice that MuPDF has a "store" where objects are allocated, and the maximum memory used by the store can be set beforehand, at the expense of rendering time. Maybe it will tolerate being squeezed down to fit on these systems. It is also touted as a very quick and efficient renderer.

 

[techknight]

I think honestly for rendering full color brochure like PDFs were gonna need at minimum an 040 with lots of RAM, or even a PPC. For forms, or text based stuff, or even black and white image scans to PDF it might be ok. 

All PDFs that I own are just datasheets to electronic parts, thats about it, that and schematics. 

As far as MuPDF, if you can compile it as a library itself as well as assigning its class and get it to work, its possible to bring it into CodeWarrior and write the UI in it, and use the MuPDF as a library. Who knows, whatever works. When compiling an App as a library you'll have to expose certain subroutines by making them public, and then using the INTERN C declaration so you can actually "get" to them. 

 

[cjbaker]

Most of the PDFs I use are just text and some graphs. It seems that MuPDF's memory usage is fairly light and adaptable, but that's my main remaining concern. I'm using Retro68 with the GNU toolchain, rather than CodeWarrior.

 

[cjbaker]

After lots and lots of fiddling, I was finally able to get MuPDF to compile with Retro68 and successfully (I think) render a PDF to an ASCII table (a 153x198 PPM) in Mini vMac with System 6.0.8. Once I get something useful or interesting working, I'll post it to Github and start a thread in "Hacks & Development". It seems to render a fairly complex black and white page with just 1MB of memory. The running time, however, might be way too slow. I've done everything I can to optimize the memory footprint, so maybe I can dial some of that back and get faster rendering instead. MuPDF also seems to have a notion of 1-bit indexed color table rendering, which would match our 1-bit screens, while it is currently rendered in RGB color, which must add some overhead. I'll find out more about that when I start trying to implement a QuickDraw renderer. I won't exclude the possibility of rendering with color QuickDraw some day.

Among the stumbling blocks were Retro68's use of HOpenDF for opening files, which I think might only work in System 7; I switched it to HOpen and it works fine (I'll probably report this on Retro68's Github page once I'm sure of what's going on). The use of the super-modern GCC 7.2.0 in Retro68 was ironically also a problem, since some of MuPDF's 3rd party dependencies required some modifications in order to compile. The biggest problem was that it was crashing on every run. I added lots of debugging printouts and played with MacsBug a bunch, and had almost given up and assumed that it was running out of memory. This morning finally figured out that if I compiled it with MuPDF's NO_ICC flag (disabling color profiles) it would run without crashing. An otherwise identical compilation on 64-bit x86 (Linux) doesn't have this problem, so it's a bug somewhere, maybe even in MuPDF with this atypical toolchain build.

I've been trying to get my SE fired up for testing, but it's going to have to wait until I go dig out my Power Mac 7500 in order to make some floppies. The SE's 20MB Rodime drive was suffering from stiction, but this excellent blog post on the HD20 showed me how to take off the circuit board, un-stick and lubricate it. Now it's spinning, but doesn't boot...once I can make a floppy I'll find out what's going on. For now vMac with its "all-out" mode is pretty convenient for testing, but eventually I'll run and hopefully use it on the "real thing".

 

[techknight]

Awesome you got it working! 

Operation and performance is exactly as I expected. your going to need a good 040 or PPC if you want to view full color photo quality PDFs with any decent rendering/scroll speed.

Text based/black and white based PDFs should be ok with an 020 or better. Maybe simple color such as a product brief. 

bare bones 68000 might be a struggle. 

As far as crashing on the color profiles, its probably a driver call or something that just simply doesnt exist, or one of the 3rd party libraries.