Impression-X Newsletter

Newsletter number 3 has been issued

According to the newsletter Virtual Risc PC doesn’t support Dynamic Areas…

https://drive.google.com/file/d/1lXsWFxgQIccGQfaUYAbmyXScC6BpfpUv/view?usp=sharing

Dynamic Areas are available on RISC OS 3.5 and later, though I note that it’s the two RiscPCs that don’t work. It’s possible that the dynamic area addresses offered clash in a way that Impression cannot use them.

PS: Please, somebody fix the newsletter title. It is really irksome. Either centre it, or fiddle with the inter-character spacing so it looks balanced on the page, and not clutching into the left side of its box.

Wow. What a convoluted way to handle an image. I guess the enormous wodge of assembler means it is simpler to stick a JPEG into an ArtWorks file rather than finding ways to make the software cater for JPEGs natively…

According to the newsletter Virtual Risc PC doesn’t support Dynamic Areas…

I did not say that. I said that Impression-X running under VRPC does not use the dynamic areas that VRPC provides (and therefore stores images in application memory) and that this is something to do with magic numbers. The programme counter was 26 bit but the address space could be switched between 26bit and 32bit.

Edited to add: Publisher Plus 5.13 on my VRPC has a line in the obey file !Run that says:

Set Impression$NoDynamicAreas 1

It was possible in Impression Publisher, I am told, to turn on the use of dynamic areas on VRPC/Risc PC but the results were not good. Remember at the time machines were only just starting to have more than 4Mbytes (1994, with Risc PC). By September 1995 a Risc PC 700 cost £2000 and had 10Mbytes of RAM. Only in its last year of development under Computer Concepts did Impression acquire StrongARM compatability. Only quite late on in 1996 was Impression fixed to handle machines with more than 20Mbytes of application memory where its application slot might be bigger than 20Mbytes. Development stopped in December 1996. It was 18 years before the next version was available.

What a convoluted way to handle an image.

JPEGs were only introduced in 1992, three years after Impression was first released and Impression simply converted them to a sprite before loading them – it had convertors for most image formats. I think that the ready availability of an ArtWorks viewer might have had something to do with it. Remember it had to work in a machine with as little total RAM space as 1Mbyte or 2Mbytes. It also offered object linking and embedding (OLE) to any image editor that chose to support the protocol. If you think that is convoluted, you want to see how it did spell checking and a thesaurus with what memory was left over in a 1Mbyte machine (and therefore did the same on all machines).

Please, somebody fix the newsletter title. It is really irksome. Either centre it, or

Noone else has spotted this, including myself. I’ll bung a space in there. Or perhaps centre it properly. Or perhaps move it impercepibly right a little bit in each subsequent issue.

and that this is something to do with magic numbers

Yeah…you did explain that. <shrug>

On JPEGs: There’s clearly some sort of image type tagging (for telling apart Sprites, ArtWorks, and Draw). Given that JPEG support was built into RISC OS 3.6 (and a softloadable SpriteExtend for 3.5), it seems strange that Impression wasn’t updated to be able to store/render JPEG natively on machines that support it.

This, by the way, is what Ovation does. Not Pro, the first version, also introduced before JPEGs were a thing.

Noone else has spotted this, including myself.

Here’s how it appears on my phone, using Adobe Reader:

Or perhaps move it impercepibly right a little bit in each subsequent issue.

This. :-) :-) :-)

That’s exactly how it appears on Firefox and on Acrobat Reader too. Moreover, I don’t think that the heading should touch the upper border. It makes it look even more unbalanced. Hopefully, these are editors issues and not the result of an Impression algorithm.

It appears the way it does did because I was too lazy to do more than tweak the font size so that it nearly fitted in the box. Adding 4 points above paragraph and centring the text does improve it.

According to the newsletter Virtual Risc PC doesn’t support Dynamic Areas…

I did not say that. I said that Impression-X running under VRPC does not use the dynamic areas that VRPC provides…

Ah right, sorry misunderstood what was written. Got it now. Does this mean Impression-X is not going to be very usable on VRPC ?
I have been considering buying into Impression-X, as much to keep current and supporting things as anything. But as I only use Virtual Risc OS, there may be no point.
I can still run the old version after all

You have a fair point, in terms of VRPC. But it is perfectly usable as I use it myself under VRPC most of the time.

However I find that using JPEGs Impression-X has the advantage that they occupy only their file size whereas in Publisher they are converted to a sprite unless you package them in an ArtWorks file before import. Impression-X does this automatically.

I think the way to phrase the DA situation of VRPC is more a case of “you’re no worse off than you were before”. For correct/stable operation on RiscPC hardware, it was strongly advised to turn off DAs (hence the Impression$NoDynamicAreas variable that Chris mentioned above). That’s been standard advice since 25+ years AFAIK, and certainly how my RiscPCs were configured. So no plus or minus for ImpX.

The JPEG loader, however, is a significant win for ImpX. With Publisher, there were multiple problems with JPEG handling. First, it would convert (crudely) to sprite (many times the file/memory size). The original convertor was, I think, first programmed with 256 colours in mind, although higher colour depth is available. But, the big problem is in the print engine. CC-era Publisher (Plus) do not seem to do full 32bpp colour handling through the print engine to paper. As a result, these JPEGs look awful when printed to paper, with very poor colours (I suspect that everything is converted to 256 colours for printing, but could be wrong). They also suffer the same fate when generating PDFs.

By using the new JPEG loader, they are retained as JPEGs throughout, reducing RAM usage considerably, but more significantly ensuring unmolested printing. This gives better prints not only to PDF (where the object is preserved as an untouched JPEG), but also through postscript printing, and also through to photo-real printing via UniPrint etc.

Now, in the interest of fairness, it is possible to work around this with other RISC OS applications used in tow with CC-era Publisher, but ImpX does it all seemlessly.

Thanks for the imp PDF.

Does the new version use the 32bit ABI module?