Displaying a PDF

I would like to see a PDF display program for RISC OS that could show pages even-odd (i.e. with page 2 to the left of page 3 etc.) and would allow a user-defined side window containing clickable links Section 1, Section 2 etc that would bring up the appropriate page pair. That would allow a standard PDF file to be displayed and for the user to book mark his favourite pages.

Some further thoughts. If there was a SYS call similar to DrawFile_Render (PDF_Render) that took arguments page number, address of PDF in memory (or filename of PDF), scale, x,y coordinates and clipping rectangle, I would write the application myself.

Hooeey. PDF rendering is not trivial. Here are the font formats you have to support for a start:

• Type0
• Type1
• Multiple Master
• Type3 (requires full Postscript interpreter)
• TrueType/OpenType/Type42
• CIDFontType0 (Type1 CID multibyte, eg Unicode/JIS/etc)
• CIDFontType2 (TT CID multibyte, eg Unicode/JIS/etc)

address of PDF in memory

Nope. The PDF describing the PDF standard is 53MB. A significant change I made to the most widely used RIP on the planet was to support PDFs larger than 2GB (which was a clever trick considering the size of PDF and Postscript integers). You do not load PDFs into RAM in general, they are designed not to require that.

Then you need graphics primitives that support the Adobe transparency model and all the blend modes.

Plus you need JPEG (inc. CMYK), and TIFF (inc. CCITT) image support. Then you require an ICC colour management system.

Or… you could use ghostscript to render a page to a sprite and then load that. ;-)

Just as an aside to this, it would be nice if our only djvu viewer, could be tarted up a bit. :-)

The only reason I ask is that there is a !PDF application that does render PDFs already written. Not perfect as it does not handle enbedded fonts just makes hopeful guesses at the font required. I am also only talking about PDFs created under RISC OS.

There’s no reason why a well written PDF should be anything like that size if it uses vector graphic images and black and white images of a resolution designed for screen viewing.

Or… you could use ghostscript to render a page to a sprite and then load that. ;-)

I suspect that this is not straightforward, otherwise why the smiley?

a well written PDF should be anything like that size if it uses vector graphic images and black and white images of a resolution designed for screen viewing.

Because PDFs designed for screen viewing look lame when printed to anything more capable than a mid-90s era LaserJet?
I would always prefer a larger PDF that prints well to a smaller one that looks good on screen, because a larger one that prints well will also look good on screen. The same cannot be said in reverse…

our only djvu viewer,

You mean MuView? I suspect there is something screwy with my system as it renders only blank pages (unless there are pictures, it does those okay), and annoyingly there’s no indication of why.
Plus, on a Pi2 it takes around half a minute to render each page. For something relatively simple like epub, it’s unacceptable.

If there was a SYS call similar to DrawFile_Render (PDF_Render) …

An alternative solution occurs to me. Import the PDF to ArtWorks and then individually export each page as a Draw file. This has to be done individually as ArtWorks cannot export the whole file, page by page, renumbering the files as it goes.

You mean MuView?

No, I meant James Peacock’s !DjVu.
I’ve not come across MuView: where can I find it?

Ok, I’ve found it: though it only runs on ROS5.2×.

DjVu is effectively dead now.

DjVu is effectively dead

The Internet Archive, I think, still uses it. It would be a shame were it to disappear; it can produce much smaller file sizes than pdf.

The IA announced some years ago that they would no longer be accepting submissions in the format.