Good day folks.

I use Harriet's SideDiff for a number of things, and particularly for
displaying differences in Textfiles.

Are there any apps on the RISC OS scene that can do the same operation on
say... Two Imp Publisher documents?

Thanks
Dave

--

Dave Triffid

In message <5a6c423da5dave@triffid.co.uk>
Dave <dave@triffid.co.uk> wrote:

> Good day folks.

> I use Harriet's SideDiff for a number of things, and particularly for
> displaying differences in Textfiles.

> Are there any apps on the RISC OS scene that can do the same operation on
> say... Two Imp Publisher documents?

> Thanks
> Dave

I use !Diff (with DDE)

--
Jean-Michel

In message <5a6c423da5dave@triffid.co.uk>
Dave <dave@triffid.co.uk> wrote:

> Are there any apps on the RISC OS scene that can do the same operation on
> say... Two Imp Publisher documents?

How about using Impression's File->Save text story (^F3), with 'With text
styles' not ticked, to save temporary text only versions of the two
documents? SideDiff should report the differences as usual, though you'd
need to do the savings for each story in the files that you want to
compare.

--
Bernard

On 25 Jan 2023 as I do recall,
Dave wrote:

> I use Harriet's SideDiff for a number of things, and particularly for
> displaying differences in Textfiles.
>
> Are there any apps on the RISC OS scene that can do the same operation on
> say... Two Imp Publisher documents?

Impression documents are binary files (albeit with some plain text
embedded in them, like old-format Microsoft Word documents).

The best you could manage would be to do a direct byte-by-byte
comparison and get the app to list the first point at which the files
differ at a binary level, which won't necessarily give you much useful
information (e.g. it won't tell you that you applied Style 1 as opposed
to Style 2 at that point).

And it will be difficult to differentiate between the addition of a few
digits of the file which then results in none of the following
(identical) content matching on a byte-by-byte comparison level, and a
big chunk of change. I did at one point have a native RISC OS app which
did its best to compare binary files in a meaningful way, but I can't
remember what it was called or which past computer it was on - I can't
find it on my A500 hard disc image, which is where most of my
programming tools were. And it would almost certainly be written in C
and useless on modern hardware with recompiling from source.

As has been said, your best bet is to export the document content as
plain text and then do a comparison -- although SideDiff won't be
terribly helpful, because it's based on software that was intended to
compare short lines of program text, not long paragraphs, so all it will
be able to highlight is that fact that two paragraphs differ in some way
at some point.

--
Harriet Bazley == Loyaulte me lie ==

Flying is the art of throwing yourself at the ground... and missing.

On 25 Jan 2023 as I do recall,
Harriet Bazley wrote:

[snip]

> I did at one point have a native RISC OS app which did its best to
> compare binary files in a meaningful way, but I can't remember what it
> was called or which past computer it was on - I can't find it on my
> A500 hard disc image, which is where most of my programming tools
> were. And it would almost certainly be written in C and useless on
> modern hardware with recompiling from source.
>
>

Oh, I just found it (I'd filed the program under BASIC tools on the
A5000 rather than general or text utilities). It's Martin Avison's
!Compare, which offers - according to the Help file -

<Byte> Basic byte-for-byte comparison
<Word> Basic word-for-word comparison
<Line> Line-by-Line for minor text changes

<Block> Identifies text blocks added/deleted
<BASIC> for BASIC program comparison
<Code> for Assembler code comparison

And attempting to run it on my current ARMX6 causes a crash, although
unexpectedly it's a "Bad sprite reason code" error rather than any of
the other possibilities! I seem to vaguely remember that the app had a
fullscreen display...

I tried it with Aemulor and got a nasty crash ("error in file comparison
utility", which is more the sort of error message I was expecting) which
left me stuck outside the desktop when I tried to Continue from the
error box. So it would presumably take some serious work to patch the
binary !RunImage into usability.

--
Harriet Bazley == Loyaulte me lie ==

One man tells a falsehood, a hundred repeat it as true.

In article <c4454a6c5a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:
> So it would presumably take some serious work to patch the
> binary !RunImage into usability.

Martin is still very active in RISC OS, so if he hasn't got an
updated version, I am sure he would try to help.

Having just checked his web site, the latest version of Compare is v.
0.32 (23 Jun 2014).

--
Chris Johnson

In article <5a6c5764c8chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:
> Martin is still very active in RISC OS, so if he hasn't got an
> updated version, I am sure he would try to help.

Certainly would!

> Having just checked his web site, the latest version of Compare is
> v. 0.32 (23 Jun 2014).

If that does not fix the problems, please let me know directly.

Martin

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

On 25 Jan 2023 as I do recall,
News wrote:

> In article <c4454a6c5a.harriet@bazleyfamily.co.uk>,
> Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:
> > So it would presumably take some serious work to patch the
> > binary !RunImage into usability.
>
> Martin is still very active in RISC OS, so if he hasn't got an
> updated version, I am sure he would try to help.
>
> Having just checked his web site, the latest version of Compare is v.
> 0.32 (23 Jun 2014).
>
Ah - which specifically mentions that it "Fixed SpriteOp error with
RO5.21"....

http://www.avisoft.force9.co.uk/Compare.htm

--
Harriet Bazley == Loyaulte me lie ==

Even a cabbage may look at a king.

On 25 Jan 2023 as I do recall,
Harriet Bazley wrote:

> On 25 Jan 2023 as I do recall,
> News wrote:

[snip]
> > Having just checked his web site, the latest version of Compare is v.
> > 0.32 (23 Jun 2014).
> >
> Ah - which specifically mentions that it "Fixed SpriteOp error with
> RO5.21"....
>
> http://www.avisoft.force9.co.uk/Compare.htm
>
In my defence, I did do a cursory Web search for "Martin Avison
Compare", but none of the results seemed to be anything to do with RISC
OS, so I assumed that if he really was the Martin Avison of
"angelgroups" then he had gone on to higher and more financially
rewarding things...!

I made a few minor changes to an Impression file (I edited
the contents of one line and deleted a paragraph altogether), then used
Compare to examine them against one another. As expected the
direct byte/line comparisons are not terribly helpful, throwing up 33
differences in files of only 127 and 128 'lines' long respectively.
Although since these are not ASCII files a new 'line' is presumably
anywhere that a linefeed character happens to occur randomly in the
binary data....

The 'Block' mode does much better, identifying ten differences in six
different 'blocks' within the files with large chunks of unchanged data
between them. The first change appears to be the actual filename (which
I had no idea Impression embedded within the document!), and I can't
guess at the second one, although it occurs alongside plaintext strings
such as 'A4' and 'Landscap' so probably has something to do with the
formatting/layout of the file, even though I didn't actively change
that. The third block is just two characters that differ within a chunk
of pure binary data and could represent anything.

The fourth block reflects the actual edit I made to the file, altering
FEB/MARCH to OCTOBER/NOVEMBER, which shows up quite clearly. The fifth
block is more unknown binary data, and the sixth block reports the text
which is present in the first file but was deleted from the second.

The output file is still quite difficult to read, because it is full of
non-ASCII characters between and surrounding the legible text - that is
just what raw Impression files look like, I'm afraid, and why I really
can't cut and paste the output here, because goodness knows what nntp
protocols would do to it in transit - and because as a result StrongED
defaults to loading it into binary Dump mode, so you need to be
sufficiently a power user to be able to force the display back into
BaseMode in order to be able to read it as intended.

I can't say that I'd recommend this as a means of detecting changes
between Impression files for a casual user, but if you are happy poking
around raw chunks of data and have some idea of what edits you made then
you *can* identify the basic differences between the two versions of a
document by this method. It probably isn't what Fay is looking for,
however. :-(

--
Harriet Bazley == Loyaulte me lie ==

St George for England - St Pancras for Scotland

In article <bfba636c5a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:
[Snippy] Some interesting stuff.

> I can't say that I'd recommend this as a means of detecting changes
> between Impression files for a casual user, but if you are happy poking
> around raw chunks of data and have some idea of what edits you made then
> you *can* identify the basic differences between the two versions of a
> document by this method. It probably isn't what Fay is looking for,
> however. :-(

You are correct, she's reasonably computerate, but only from the keyboard
side of the business.

Thanks for the thoughts and tests. Appreciated.

Dave OHB. :-)

--

Dave Triffid