Looks like this for me in Reader; (45% zoom to fit 1 page on screen for screenshot) I'd say it's pretty much the same
http://www.allegro.cc/files/attachment/596426
http://www.allegro.cc/files/attachment/596427

It won't open in KPDF at all, but the new kpdf (Okular) gives me:

http://www.allegro.cc/files/attachment/596428

http://www.allegro.cc/files/attachment/596429

Same as the reference picture too, FoxitReader, but I don't see the lagging scrolling.

Thanks to everyone for testing!

That's peculiar. Does KPDF dump anything helpful to stderr or indeed to anywhere else helpful? I'll try to get a Linux VM going and check this out

Also odd that the first page has a grey background. Though I'm not explicitly setting paper colour (or ink colour), so I'll look into that.

I think I'm just paying the price for using Type 3 fonts. As you may or may not be aware, Adobe defined two interesting types of Postscript font, Type 1 and Type 3. Type 3 is pretty much just providing a Postscript description of each glyph, which is really easy and convenient and is what I'm doing. Type 1 uses a subset of Postscript and an optimised renderer but was originally meant to be proprietary so the main part is encrypted and everything is much more strict. When TrueType came along Adobe abandoned the idea of keeping Type 1 fonts to themselves, but they just did that by releasing the encryption codes. So there'd be another layer of complexity to implementing Type 1 fonts, and with the very limited verification tools available to me it's not something I felt was likely to work first time.

That and the fact that each one of my dots is a separate Postscript path probably kill the rendering speed - each dot has to be tokenised separately and the pixel form can't be cached, though if it isn't caching Type 3 glyphs then I'm not optimistic that there's any part of the Postscript path with caching enabled.

I think my plan is just to do as much as I can with Type 3 (in speed and filesize terms) and then call it a day, as it achieves all of the main functionality goals and I'll bet nobody ever uses the "print to PDF" feature anyway.

EDIT:
Well, I'm at work now and Acrobat Reader makes a surprisingly good job of the whole thing. Even copy and paste mostly works; I guess it's assuming something close to ASCII, which is not too far off the characters actually encoded in that file.

EDIT2:
On that line of thought, this PDF file is encoded as pure ASCII if anybody is that interested to see what they can look like inside before various compression filters are applied.

Oh, good tip! I guess I'll grab a KDE4 distro. OS X's Preview.app dumps some helpful few things onto the console when I've made sufficiently large an error that it can't really figure out how to display much at all, but otherwise isn't proving to be a particularly helpful diagnostic tool.

Cool, I'll keep that in mind when I look into it this evening. I might try hopping on the "KDE for OS X" betas before actually grabbing a whole Linux distro.

Re: my problem, it seems that ligatures are defined by the font encoding, i.e. the same place where I should be saying how my internal codes map to unicode but currently am not. I guess the default encoding on your platform expects some of the common ligatures such as 'fi' and, obviously, doesn't find them.

EDIT: much improved PDF attached. My attempts to download the beta OS X port of KDE 4 and the kdegraphics package is being thwarted because kde.org only provides torrents and there are currently 0 peers offering me kdegraphics. Though I did manage to get most of the prereqs.

EDIT2: my previous edit was the subject of a misupload, a fixed file is now attached.

Oh, yeah, I changed the paper size from [the printable area on] US legal to [the printable area on] A4 so that I could print the thing slightly more realistically. Another change is that the emphasised double width font should be visually correct now.

Can't imagine what I've got wrong in the bfrange. It's been pointed out to me on another forum that I've typod the %%EOF marker (to just %EOF), which is probably what's leading to the KDF & KGhostscript's refusal to do anything all. The first place a PDF reader looks in a PDF is right at the end, so having an incorrect marker there means that my PDF trivially isn't valid. I guess many of the readers are just scanning backwards for the first useful token rather than bothering to explicitly check for the %%EOF.

Right. Please try the latest attachment.

It has been tested against:

• Mac OS X v10.5's Preview.app

• Acrobat Reader 8 for Windows

• Foxit Reader 2.3

• the ABC Amber PDF validator

• the Multivalent PDF validator

Re: my comments earlier, those validators are literally just validators; they return either valid or invalid and nothing else particularly helpful.

Works for me in Evince, KPDF and KGhostView. Incidentally, the page rendering speed is very slow... not sure if that's to be expected given custom glyphs.

Ok, works in kpdf just fine (I might have loaded the wrong file last time I tested, seems konqueror saved this one, and probably the last one with _s instead of spaces which the first copy used). And okular prints a ton of these still:
Error: Could not parse ligature component "Font118656" of "Font118656_255" in parseCharName

Hmmm. I really can't find anything in the PDF spec to explain this - I guess I must be failing to grasp some concept or another.

I always go to ridiculous efforts with my emulator. Based on the best information I have available, there's not a single deliberate compromise in there; bus contention is correct, all display data is collected at exactly the right time (most emulators just sort of do an instantaneous fetch of all the data on one scanline at the end of the scanline, and round all palette changes to that position), floppy disks are emulated internally as a sequence of magnetic polarity changes on the platter (actually because that's the only way to fully support one of the disk image formats I support) and tapes are similarly decomposed to audio waves and then those are interpretted (though that's partly because I used to support direct audio in, and in any case there are many different ways to encode the same tape and I don't think it should be the capture program's duty to guess how an emulator might like it formatted), interrupts are tested and occur for exactly the correct periods, etc, etc.

I have a relatively unique design in that the CPU is subservient to the thing actually managing the emulator and can be paused at any point, even mid-opcode.

Counterintuitively, mine is also a very speedy emulator because being rigorous allows it to take a very broad overview of how the machine is being used and apply processing optimisations accordingly.

I have supported a simple FX-80 control code to RTF filter for a while, but that was really only good for mimicking some elements of text formatting (and its not very accurate at that - things like back spaces and reverse line feeds have to be ignored). Recently someone requested a sufficiently accurate emulator to test their screen dump routines, so I just sort of set lofty aims from there. Anything less than actually emulating the print head is just a hack and won't necessarily work with all software.

Looks decent in Sumatra PDF.