RiScript and RO5.18 upwards

[Jim Lesurf]

I've recently upgraded my Iyonix to RO5.18 from 5.16 and started also
migrating my work to an ARMiniX. I have also upgraded my versions of TW and
AW to the current versions.

Overall, the results are good. But I've hit one snag.

I now find that any attempt to use RiScript fails. When I try to load
either a PS or PDF file I get an hourglass for some time, then a freeze.

I get the same problem on the ARminiX.

I've experimented with reverting to the older version of TW to create new
PS files, that also fails to work with RiScript. So I'm suspecting that
there is a problem with running RiScript on 5.18 upward.

Anyone know more about this or how it might be fixable?

I use RiScript because it gives me results which are better for my purposes
than !PDF or GhostScript. So this is something of a problem.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

[Paul Sprangers]

In article <5343e95...@audiomisc.co.uk>,

Jim Lesurf <no...@audiomisc.co.uk> wrote:

> So I'm suspecting that there is a problem with running RiScript on 5.18
> upward.

Indeed, there is - and not only with RiScript. A number of applications
needed a modification in order to work under RISC OS 18 and on. RiScript is
among them, but unfortunately the authors have abandoned support years ago.
TracerPro is another one. Although it's still officially supported (by Paul
Reuvers from X-AT), I'm still waiting for an update.

Kind regards,
Paul Sprangers

[Jim Lesurf]

So can you/someone explain the cause?

I first hit the problem on my ARMiniX. But checking and finding the problem
also on the Iyonix I realised this isn't due to a change in hardware. So
what is the specific change in the OS that is the cause? Is it not
essentially a bug in the OS that needs the fix rather than the apps it
causes to fail?

[Martin Wuerthner]

Jim Lesurf <no...@audiomisc.co.uk> wrote:

> In article <5343f2b...@sprie.nl>, Paul Sprangers <Pa...@sprie.nl>
> wrote:
> > In article <5343e95...@audiomisc.co.uk>, Jim Lesurf
> > <no...@audiomisc.co.uk> wrote:
>
> > > So I'm suspecting that there is a problem with running RiScript on
> > > 5.18 upward.
>
> > Indeed, there is - and not only with RiScript. A number of applications
> > needed a modification in order to work under RISC OS 18 and on. RiScript
> > is among them, but unfortunately the authors have abandoned support
> > years ago. TracerPro is another one. Although it's still officially
> > supported (by Paul Reuvers from X-AT), I'm still waiting for an update.
>
> So can you/someone explain the cause?
>
> I first hit the problem on my ARMiniX. But checking and finding the
> problem also on the Iyonix I realised this isn't due to a change in
> hardware. So what is the specific change in the OS that is the cause? Is
> it not essentially a bug in the OS that needs the fix rather than the apps
> it causes to fail?

Probably not. This situation has arisen many times before. The most likely
cause of application failures is some application bug that went unnoticed
due to a bug in the OS. Then, when the OS bug gets fixed, suddenly the
application bug comes to light.

For instance, EasiWriter suddenly stopped working when a new version of CLib
was released in 2006 that included a bug fix for a rarely used special case
of a very common library routine. The parameters EasiWriter used only worked
with the broken version of the routine.

Similarly, the Spr2PNG command-line program broke at some stage because
another exotic case of a related CLib routine was fixed.

In both cases, the application bug had been there all along, but it was a
genuine bug fix that stopped both programs in their tracks. No problem for
programs that are still being developed or for which source code is
available, but difficult to fix in closed source legacy software.

--
Martin Wuerthner MW Software http://www.mw-software.com/

------- RISC OS Software for Design, Printing and Publishing --------

[Jim Lesurf]

In article <mpro.mm0sts009o...@mw-software.com>, Martin

Wuerthner <spam...@mw-software.com> wrote:
> Jim Lesurf <no...@audiomisc.co.uk> wrote:

> > In article <5343f2b...@sprie.nl>, Paul Sprangers <Pa...@sprie.nl>
> > wrote:

> >
> > So can you/someone explain the cause?
> >
> > I first hit the problem on my ARMiniX. But checking and finding the
> > problem also on the Iyonix I realised this isn't due to a change in
> > hardware. So what is the specific change in the OS that is the cause?
> > Is it not essentially a bug in the OS that needs the fix rather than
> > the apps it causes to fail?

> Probably not. This situation has arisen many times before. The most
> likely cause of application failures is some application bug that went
> unnoticed due to a bug in the OS. Then, when the OS bug gets fixed,
> suddenly the application bug comes to light.

OK. However: How do we go beyond "probably not" as an opinion/judgement
and determine the actual reason, though? I appreciate that you are
probably correct, but: How do we tell which is *actually* the
cause - OS or apps (plural) - unless someone working on them checks?

BTW I'm pleased to say that ArtWorks *does* render the PDFs I've created
in the past (except the ones I've 'locked' to prevent editing). Which
is great news - and something of a relief for me. So if the RiScript
problem endures what I will now focus on is trying to ensure I can
continue to generate PDFs with the text as font-definition embedded
text as I have until now.

[Jim Lesurf]

On 29 Apr, no...@audiomisc.co.uk wrote:
> In article <mpro.mm0sts009o...@mw-software.com>, Martin
> Wuerthner <spam...@mw-software.com> wrote:
> > Jim Lesurf <no...@audiomisc.co.uk> wrote:


> BTW I'm pleased to say that ArtWorks *does* render the PDFs I've created
> in the past (except the ones I've 'locked' to prevent editing). Which is
> great news - and something of a relief for me.

Oops! Just checked some of my old lectures as PDFs. Various parts of the
maths goes missing when viewed with ArtWorks. e.g. greek. vanishes. So not
as good as RiScript. :-/

Should I ask about this on the TW or AW list?

[Martin Wuerthner]

Jim Lesurf <no...@audiomisc.co.uk> wrote:

> On 29 Apr, no...@audiomisc.co.uk wrote:
> > In article <mpro.mm0sts009o...@mw-software.com>, Martin
> > Wuerthner <spam...@mw-software.com> wrote:
> > > Jim Lesurf <no...@audiomisc.co.uk> wrote:
>
>
> > BTW I'm pleased to say that ArtWorks *does* render the PDFs I've created
> > in the past (except the ones I've 'locked' to prevent editing). Which is
> > great news - and something of a relief for me.
>
> Oops! Just checked some of my old lectures as PDFs. Various parts of the
> maths goes missing when viewed with ArtWorks. e.g. greek. vanishes. So not
> as good as RiScript. :-/

No, ArtWorks is not a PDF viewer. ArtWorks completely ignores embedded
fonts, and for the time being, ignores even pretty much all font
information. The idea is to get foreign content into ArtWorks for editing.

> Should I ask about this on the TW or AW list?

This would be a topic for the AW list. PS/PDF files exported from TechWriter
contain a perfect visual representation of the document.

[Martin Wuerthner]

Jim Lesurf <no...@audiomisc.co.uk> wrote:

> In article <mpro.mm0sts009o...@mw-software.com>, Martin
> Wuerthner <spam...@mw-software.com> wrote:
> > Jim Lesurf <no...@audiomisc.co.uk> wrote:
>
> > > In article <5343f2b...@sprie.nl>, Paul Sprangers <Pa...@sprie.nl>
> > > wrote:

> > > So can you/someone explain the cause?
> > >
> > > I first hit the problem on my ARMiniX. But checking and finding the
> > > problem also on the Iyonix I realised this isn't due to a change in
> > > hardware. So what is the specific change in the OS that is the cause?
> > > Is it not essentially a bug in the OS that needs the fix rather than
> > > the apps it causes to fail?
>
> > Probably not. This situation has arisen many times before. The most
> > likely cause of application failures is some application bug that went
> > unnoticed due to a bug in the OS. Then, when the OS bug gets fixed,
> > suddenly the application bug comes to light.
>
> OK. However: How do we go beyond "probably not" as an opinion/judgement
> and determine the actual reason, though? I appreciate that you are
> probably correct, but: How do we tell which is *actually* the cause - OS
> or apps (plural) - unless someone working on them checks?

Only the authors of the application in question are in a position to check
this easily. If they have no interest in their product any more you are
probably stuck.

> BTW I'm pleased to say that ArtWorks *does* render the PDFs I've created
> in the past (except the ones I've 'locked' to prevent editing). Which is
> great news - and something of a relief for me. So if the RiScript problem
> endures what I will now focus on is trying to ensure I can continue to
> generate PDFs with the text as font-definition embedded text as I have
> until now.

Ghostscript creates perfect PDFs with the text as font-definition embedded
text, so you do not need RiScript for that anyway. Basically, your problem
is the PostScript generated by the PostScript 2 driver, not the PDF
conversion tool. RiScript knows about the PS2 driver output and uses some
special tricks to produce improved PDF output.

I propose a better approach: Instead of using the poor PS2 driver and trying
to recover some of the lost quality in the PDF conversion stage using an
obsolete RISC OS specific tool, use the PS3 driver to generate decent PS to
begin with. Then, use Ghostscript on any platform to create decent PDF
output.

Apart from better fonts this gives you a huge amount of other improvements,
in particular much improved sprite output.

Oh, and you can use TechWriter's save as PDF option with PS3 as well, so
this is much more convenient than any other method for PDF creation. Plus,
that method gives you more improvements over manual PDF generation because
TechWriter creates enhanced PDF including an automatically generated
document outline and working links.

[cfe...@freeremoveuk.com.invalid]

In message <mpro.mm0sts009o...@mw-software.com>

Martin Wuerthner <spam...@mw-software.com> wrote:

> Jim Lesurf <no...@audiomisc.co.uk> wrote:

>> In article <5343f2b...@sprie.nl>, Paul Sprangers <Pa...@sprie.nl>
>> wrote:
>>> In article <5343e95...@audiomisc.co.uk>, Jim Lesurf
>>> <no...@audiomisc.co.uk> wrote:
>>

<snip>

> Similarly, the Spr2PNG command-line program broke at some stage because
> another exotic case of a related CLib routine was fixed.

> In both cases, the application bug had been there all along, but it was a
> genuine bug fix that stopped both programs in their tracks. No problem for
> programs that are still being developed or for which source code is
> available, but difficult to fix in closed source legacy software.

One option that seemed to work with !DeskEdit - was to use the 'PD' if
that is the correct term - 'SharedCLib' that can be softloaded on RO5.


--
Colin Ferris Cornwall UK

[Jim Lesurf]

In article <c5ae1a445...@cferris.freeuk.com>,

Erm.. That makes me want to check:

I'm still using !DeskEdit4 on my Iyonix (now RO5.18) and have started using
it on my new ARMiniX (RO5.19). So far it seems to work fine. Does it also
have a problem with RO 5.18 upwards? If so, I've not encountered it yet. Or
am I totally misunderstanding your comments?

[Jim Lesurf]

In article <mpro.mm12nq00h9...@mw-software.com>, Martin

Wuerthner <spam...@mw-software.com> wrote:
> Jim Lesurf <no...@audiomisc.co.uk> wrote:

> > In article <mpro.mm0sts009o...@mw-software.com>, Martin
> > Wuerthner <spam...@mw-software.com> wrote:
> > > Jim Lesurf <no...@audiomisc.co.uk> wrote:

> >
> > OK. However: How do we go beyond "probably not" as an
> > opinion/judgement and determine the actual reason, though? I
> > appreciate that you are probably correct, but: How do we tell which
> > is *actually* the cause - OS or apps (plural) - unless someone working
> > on them checks?

> Only the authors of the application in question are in a position to
> check this easily. If they have no interest in their product any more
> you are probably stuck.

But would not the authors of the OS be able to determine what changes they
made to the OS have caused the problem to occur with 5.18 upwards but not
for earlier versions? They presumably know what changes they made.

[snip]

> I propose a better approach: Instead of using the poor PS2 driver and
> trying to recover some of the lost quality in the PDF conversion stage
> using an obsolete RISC OS specific tool, use the PS3 driver to generate
> decent PS to begin with. Then, use Ghostscript on any platform to create
> decent PDF output.

OK. That makes sense. I'll go down that route. :-)

I'll try this time to send a cheque fairly soon. Not delay for ages like I
did before upgrading TW/AW.

> Apart from better fonts this gives you a huge amount of other
> improvements, in particular much improved sprite output.

> Oh, and you can use TechWriter's save as PDF option with PS3 as well, so
> this is much more convenient than any other method for PDF creation.
> Plus, that method gives you more improvements over manual PDF generation
> because TechWriter creates enhanced PDF including an automatically
> generated document outline and working links.

OK. :-)

[Martin Wuerthner]

Jim Lesurf <no...@audiomisc.co.uk> wrote:

> In article <mpro.mm12nq00h9...@mw-software.com>, Martin
> Wuerthner <spam...@mw-software.com> wrote:
> > Jim Lesurf <no...@audiomisc.co.uk> wrote:
>
> > > In article <mpro.mm0sts009o...@mw-software.com>, Martin
> > > Wuerthner <spam...@mw-software.com> wrote:
> > > > Jim Lesurf <no...@audiomisc.co.uk> wrote:
>
> > >
> > > OK. However: How do we go beyond "probably not" as an
> > > opinion/judgement and determine the actual reason, though? I
> > > appreciate that you are probably correct, but: How do we tell which
> > > is *actually* the cause - OS or apps (plural) - unless someone working
> > > on them checks?
>
> > Only the authors of the application in question are in a position to
> > check this easily. If they have no interest in their product any more
> > you are probably stuck.
>
> But would not the authors of the OS be able to determine what changes they
> made to the OS have caused the problem to occur with 5.18 upwards but not
> for earlier versions? They presumably know what changes they made.

Yes, but there may be hundreds of OS changes, and you can only find out
which one is responsible for the application problem if you have a rough
idea what the problem in the application is. And even if one could find out,
which is highly unlikely without knowing the innards of the application, you
would not gain much from knowing because someone would still have to fix the
application in the end. Unless of course the OS change in question was
incorrect in which case the OS could be fixed, but that is not the most
likely scenario.

[Jim Lesurf]

In article <mpro.mm2m1o007v...@mw-software.com>, Martin

Wuerthner <spam...@mw-software.com> wrote:
> Jim Lesurf <no...@audiomisc.co.uk> wrote:

> >
> > But would not the authors of the OS be able to determine what changes
> > they made to the OS have caused the problem to occur with 5.18 upwards
> > but not for earlier versions? They presumably know what changes they
> > made.

> Yes, but there may be hundreds of OS changes, and you can only find out
> which one is responsible for the application problem if you have a rough
> idea what the problem in the application is. And even if one could find
> out, which is highly unlikely without knowing the innards of the
> application, you would not gain much from knowing because someone would
> still have to fix the application in the end. Unless of course the OS
> change in question was incorrect in which case the OS could be fixed,
> but that is not the most likely scenario.

Understood. Although the concern is that if people just assume it isn't
likely, they won't look. So fail to find what might actually *be* a bug in
the OS.

I've just written the order and cheque for PS3 by the way. Did this rather
more quickly than I got around to ordering the TW/AW upgrades! So *some*
good has come out of this. :-)

Someone has now suggested I try the 'SD version' of Clib. However I know
nothing about this at present or how it may differ from the standard
version. I'll see if I can find out more or experiment whilst waiting for
the PS3 driver.

It is a shame that the source code for RiScript isn't openly available.
Might be useful for more that just fixing this problem.

[Theo Markettos]

Jim Lesurf <no...@audiomisc.co.uk> wrote:
> It is a shame that the source code for RiScript isn't openly available.
> Might be useful for more that just fixing this problem.

Why not try asking?
http://riscript.nl/
jeroen dot medema at philips dot com

Theo

[Jim Lesurf]

In article <nHv*+ff...@news.chiark.greenend.org.uk>,

OK, no harm in asking. :-)

[Jim Lesurf]

In article <53451b0...@audiomisc.co.uk>, Jim Lesurf

<no...@audiomisc.co.uk> wrote:
> In article <nHv*+ff...@news.chiark.greenend.org.uk>, Theo Markettos
> <theom...@chiark.greenend.org.uk> wrote:
> > Jim Lesurf <no...@audiomisc.co.uk> wrote:
> > > It is a shame that the source code for RiScript isn't openly
> > > available. Might be useful for more that just fixing this problem.

> > Why not try asking? http://riscript.nl/ jeroen dot medema at philips
> > dot com

> OK, no harm in asking. :-)

I've now sent an email asking about either getting the problem fixed, or -
if the authors have lost interest - in making RiScript open source so
others may be able to look at this.