PDF reader

I’m acutely conscious that RISC OS could do with a better PDF reader, in terms of speed, ability to render most documents (without using the slow bitmap mode) and robustness. Is that within the scope of a ROOL bounty or are ‘applications’ outside scope?
What would be the best approach – enhancing what we have or something new?

Is that within the scope of a ROOL bounty or are ‘applications’ outside scope?

It feels outside the scope to me, but might fall into ROD’s area.

What would be the best approach – enhancing what we have or something new?

What we have currently builds on a renderer from another platform, and that seems like the way forward. The key point, as with AcornSSL, is making sure that it uses the vanilla code as much as possible to simplify the inclusion of updates from the upstream project.

Which version are you using John?
I think the latest is here

I have been using this alpha version for a while. Now I have two files which lock up the entire ARMX6 when I
try to open them. Not even ctrl-break will unlock it, needing power off.
They do open, very slowly, using !ghostview 0/01 alpha 2013 from Chris Gransden.
If anyone wants a copy of the files for testing, please ask.

If anyone wants a copy of the files for testing, please ask.

I am interested. pittdj at pittdj dot co dot uk

I’m acutely conscious that RISC OS could do with a better PDF reader

Not mentioned so far is MuView 0.02

I think the latest is here

That points to !PDFtest 3.03.1.25alpha 8

There is a later vfp build !PDFtest 3.03.1.25alpha 9

If anyone wants a copy of the files for testing

I have seen the two files now and, unexpectedly, they both open properly on the Titanium with the latest OS5.27 (27-Jan-20) with !PDF 3.02.1.24.1 (4 Mar 2017), !PDFtest 3.03.1.25alpha 8 (20 May 2013) and !PDFtest 3.03.1.25alpha 9 (22 Aug 2015).

I’ve just been having a bit of grief with !PDF and !PDFtest.

!PDF, when printing a document out, puts out one or two black pixels in the 10th pixel of a row or two, but not always the same row(s). The document is all white around the pixels in question. The black pixels are visible in the strip data presented to the printer dumper. OK, it doesn’t conclusively tie the defect to !PDF rather than the printer driver, but…

!PDFtest, I’ve tried two versions: one just locks the machine, requiring Alt-Break to escape. The latest VFP version just doesn’t even appear in the Task Manager or on the icon bar. Raspberry Pi, RO 5.29 (15-Feb-22).