ROOL Forum: Recent posts

Sun, 09 Aug 2026 13:50:34 +0000

It's not quite as simple as that. On looking at it further, pdfimages simply generates the images exactly as they were stored in the file. But pdftocairo generates the JPEG files for a particular resolution, defaulting to 150 dpi. That ought to be fine for on-screen display, but some scans are saved as a high resolution with a very small page size — and can become unreadable unless the resolution is increased (it's a parameter).

I've developed a command-line program in Python which "de-browns" pages using the same approach as the existing DeBrown, but using pdftocairo to do the conversions. I have it running on the Pinebook Pro under Linux, and I'm hopeful it will run under RISC OS.. It uses Python's glob.glob() to expand wildcards and doesn't require any Python libraries that aren't part of the standard installation.

By default it uses a resolution of 300 in generating the JPEGs, and leaves the first and last pages unchanged. You can optionally specify a different resolution, to have the first or last page treated, or to produce pages with the "colours" inverted.

Sun, 09 Aug 2026 10:07:44 +0000

So IIUC having DeBrown use the KPDFUtil approach means it could cope with the wider range of original page-file types? If so, is that an easy fix for the problem?

Yes, the files in question render OK with MuView.

Sun, 09 Aug 2026 00:48:02 +0000

I’m cancelling this; I don’t really have anything useful to do for it, so I’ll work something out for a few weeks time.

Sat, 08 Aug 2026 17:24:22 +0000

Kevin: That's very helpful. It is much faster than using pdfimages and forcing the generation of PNGs (you can't force JPEG generation). And it avoids "odd" file types such as JPEG2000 and the "JBig" files (.jb2e) which magazines archived on archive.org often have.

Sat, 08 Aug 2026 16:03:34 +0000

I never really felt that Locate was a good fit for the Select protocol, although I’m happy to be corrected by actual users on that front. That’s why the new “I’m a search tool that can supply you with a search dialogue” approach seemed to have some advantages.

Do remember that the Select protocol wasn’t intended to be the be-all-and-end-all of integrations, it was just to allow existing clients (which would use FilerAction protocols) to be proxied and allowed to function entirely transparently. There’s really no reason why things couldn’t be done other ways at all – the intent was that the existing users got benefits without having to be updated, and that there was no lock in to a particular client or way of working. This is vital in any OS development – it allows other developers to work with the system in an extensible way, and allows users to choose what type of tooling they wish to use, whilst never prescribing that things should be a particular way.

Sat, 08 Aug 2026 14:48:18 +0000

It appears to return the number of visible characters output, excluding the terminator. So this sounds like the correct way to interpret the value.

That would make sense if it guarantees always to terminate the string, even when it's too long for the buffer. I'd forgotten that might be how it might work: I was thinking it might write stuff right up to the end of the buffer without terminating.

Sat, 08 Aug 2026 14:41:04 +0000

I never really felt that Locate was a good fit for the Select protocol, although I'm happy to be corrected by actual users on that front. That's why the new "I'm a search tool that can supply you with a search dialogue" approach seemed to have some advantages.

You undoubtedly know better than me. It's over twenty years since I last used Select except for very brief tests of particular issues in software.

Sat, 08 Aug 2026 13:39:38 +0000

WAKEFIELD RISC OS COMPUTER CLUB

Meeting on Wednesday 12th August starting at 7.45pm

Martin Eastwood

Martin intends to cover the following things he has been working on.

A15 Emulator for RISC OS

The A15 Emulator is aimed at running RISC OS on (or emulating) systems based around the Cortex-A15 processor. The A15 generation of ARM cores offered a substantial step up in performance over earlier designs that RISC OS originally targeted. This project explores bringing the operating system and its software to that class of hardware, whether through native support or emulation, while trying to preserve the classic RISC OS experience as far as possible.

It’s part of the wider effort to give RISC OS a path onto more capable modern ARM platforms.

Sprite and Draw Viewers for Mac and Windows

Alongside the emulator work are two practical utility applications: a Sprite viewer and a Draw viewer, available for both macOS and Windows. RISC OS has its own long-standing native formats – Sprites for bitmaps and Draw files for vector graphics. These are still commonly used in the RISC OS community, but they aren’t natively supported on other platforms. The viewers were created to bridge that gap. They let you open, inspect and work with these files on modern Mac and Windows machines without needing a full RISC OS environment running. They’re deliberately focused tools rather than full editors – simple, useful utilities for anyone who still deals with RISC OS graphics assets.

Kinetic Box – Risc PC Native Emulator with 64MB Graphics Card

Kinetic Box (also known as Virtual Kinetic Box) is a ready-to-run emulator of an Acorn Risc PC fitted with a Kinetic processor card. Built on the excellent RPCEmu foundation, it presents a fully configured Kinetic Risc PC running a modern RISC OS distribution. Key features include:

• Substantial memory configurations (up to 384 MB, combining motherboard and on-card Kinetic SDRAM)
• A dedicated 64 MB graphics card (KineticGraphics) that lifts the old VIDC20 limitations
• High-resolution desktops – including ultrawide and 4K modes in millions of colours
• Hardware-accelerated 2D operations (scrolling, fills, window movement)
• Fast JPEG rendering
• Native networking and ShareFS/Access support
• Versions for Apple Silicon Macs (with Metal acceleration and a native AArch64 JIT) and Windows

The result is a fast, modern way to run a Kinetic-class Risc PC with capabilities that go well beyond what the original hardware could manage – especially in the graphics department

This ‘virtual’ meeting is open to all, and will take place using the Zoom conferencing service using our regular meeting credentials. Zoom invitations will be sent out ahead of the meeting, but only to those who email info2026@wrocc.org.uk to request one. If you would like to be part of the meeting (and don’t already have the link from a previous meeting or receive an invite in the next 24 hours as a member of WROCC), please RSVP — at the latest by the end of Tuesday 11th August (GMT). We usually email the links out on the morning of the meeting.

If you haven’t used Zoom before, we suggest that before Wednesday you try to join the Zoom test meeting at https://zoom.us/test on the device that you intend to use, in order to check that your system works OK. You will not require a Zoom account to take part.

Past Meetings

Videos of previous meetings can be found in our links to past meetings at https://www.wrocc.org.uk/meetings or see our YouTube channel: https://www.youtube.com/@wrocc-riscos

WROCC Membership

Annual membership of WROCC is available for those living near and far at 10.00ukp per year.

Members receive:

• A PDF newsletter with all the latest news and articles.

• Entry to meetings.

• Access to the WROCC Internet Discussion List.

For further information, please email info2026@wrocc.org.uk or visit the Club’s website at https://www.wrocc.org.uk/

Sat, 08 Aug 2026 13:34:21 +0000

This Sunday – 9th August, at 1pm UK time – I’m doing some more live coding. This time I’m going to try cleaning some things up and making sure that stuff’s working. It’s been a really exhausting few weeks so – like last time – I’m just going to wing it!

Come along if you like – https://youtube.com/live/DIHiBshKcbU?feature=share – or you can always watch the video afterwards at the same address.

For anyone who hasn’t seen these live coding sessions, this where I share my screen for about 3 hours and code some RISC OS component, whilst talking about what I’m doing, what I’m thinking, and answering questions on the chat.

Fri, 07 Aug 2026 18:27:51 +0000

What I did with KPFUtil is for PDF to JPEG is use pdftocairo with the -jpeg option which saves it as a jpeg.

Fri, 07 Aug 2026 17:09:29 +0000

These are not PPM files—they are JPEG2000 files (.jp2). There is a RISC OS filetype allocated for these (&A65) but I’m not aware of any RO program that can handle them

ImageMagick and Imageview on RISC OS have supported jp2 files since at least 2013.

MuView will also load them and also the cbz file.