Techwriter 8.90/RISC OS 5.20

Techwriter fails to open a docx file with the error message ‘Could not open file XXX/docx because JPEG format is not supported by this version of the SpriteExtend module.’

It works fine in 5.16

Has SpriteExtend been changed recently? It doesn’t look like it, but perhaps I’m looking in the wrong place.

No problems with TW 9.00 and RISC OS 5.20 on xM. I try my docx with a jpeg inside.

It may be the particular document, other docs were fine.

Try this if you want.
One line text, a picture and a table.
If you set the filetype to zip, you can open the DOCX-files via SparkFS and you can open the jpeg outside. It is placed in the Media-folder of the DOCX.

More complicated.

In 5.16 and with TechWriter 8.90 on my Iyonix:
After start up I note that:

 Alias$@RunType_AE6 is set to ..Apps.!Writer+.!Run
and
 Alias$@RunType_A7E is set to ..Apps.!TechWrite.!Run

So I can load doc (AE6) and docx (A7E) files (so long as TechWriter is running or I load a docx file first). Before upgrading to 5.20 I did not get this problem. The app !Writer+ in Apps (now broken by a change in !Boot for 520 which loads a ‘bugfixed’ Shared C Library) was previously harmless. Going back to the old version of !Boot, I find !Writer+ works fine under 5.16. Now I am quite puzzled.

In 5.20 after start up the system variables above are the same. However opening a docx file with an image (which worked in 5.16) fails with a ‘this version of SpriteExtend can’t handle the JPEG’. The version of SpriteExtend is 1.21 (19-Jan-2010) under 5.16 and 1.51 (10-Aug-2013) under 5.20. Therefore something has been broken in SpriteExtend? Perhaps under the new terminology this is also a ‘bugfix’?

List of modules under 5.16 compared between old Boot and new Boot:

Comparing files zxold.txt and ZXNEW.TXT
..... zxold.txt
   17:  Desktop         2.70 (18 Jan 2010)
   18:  C Library       5.56 (28 Nov 2009)
   19:  NVidia          0.32 (19 Jan 2010)
..... ZXNEW.TXT
   17:  Desktop         2.70 (18 Jan 2010)
   18:  C Library       5.77 (24 Mar 2013)
   19:  NVidia          0.32 (19 Jan 2010)
..... zxold.txt
  124:  CDFSFiler       2.47 (12 Aug 2004)
  125:  VProtect        4.04 (07 Dec 2002)
  126:  Deep Key Buffer 2.06 (23-Jul-2003) © Cerilica 1999-2003
  127:  DrawPool        1.00 (25 Nov 2002) RISC OS 5 Draw sprites
  128:  PaintPool       1.00 (25 Nov 2002) RISC OS 5 Paint sprites
  129:  WimpPool        1.10 (14 Mar 2003) RISC OS 5 Wimp sprite pool
  130:  WindowTools     1.10 (25 Feb 2003) RISC OS 5 window furniture
  131:  Aemulor Pro     2.32 (07 Oct 2005) © Adrian Lees, 2002-5
..... ZXNEW.TXT
  124:  CDFSFiler       2.47 (12 Aug 2004)
  125:  Deep Key Buffer 2.06 (23-Jul-2003) © Cerilica 1999-2003
  126:  Aemulor Pro     2.32 (07 Oct 2005) © Adrian Lees, 2002-5
..... zxold.txt
  133:  ShareFS         3.52 (01 Jul 2004) Access+
  134:  SCSIdriver      2.06 (25 Oct 2009)
  135:  RTSupport       0.05 (22 Oct 2009)
  136:  SCSISoftUSB     0.11 (22 Oct 2009)
  137:  SCSIFS          1.17 (14 Jul 2009)
  138:  SCSIFiler       1.17 (05 Mar 2005)
  139:  HotClickX       2.05 (28 Jan 2003) © Christina West & Nick Roberts
  140:  ABCLibrary      4.15 (06 Jun 2004)
  141:  Obey support    0.04 (13 Nov 2002)
..... ZXNEW.TXT
  128:  ShareFS         3.52 (01 Jul 2004) Access+
  129:  HotClickX       2.05 (28 Jan 2003) © Christina West & Nick Roberts
  130:  ABCLibrary      4.14 (29 Nov 2002)
  131:  Obey support    0.04 (13 Nov 2002)
.....

So if I was following the ROOL upgrade checklist for 520 I would stop after trying the new !Boot directory under 5.16 and say ‘cannot proceed further – the update to the Shared C Library does not work correctly with !Writer+’.

So anyone who has upgraded to 520 on the Iyonix has not followed the instructions.

Has SpriteExtend been changed recently?

Yes. From the version number, there have been 30 changes since 2010.

However the JPEG problem was evident in RISC OS 5.18 (SpriteExtend 1.47 (03-Oct-2011)) so the problem is between versions 1.21 and 1.47. That was (probably) one of the reasons I stuck with 5.16 on the Iyonix rather than go to 5.18.

BTW. I haven’t looked but I was, how can I put this, “rather disappointed” when ROL added code to SpriteExtend to ignore any ‘next’ sprite offset that was negative. I do hope no such barbarism has been committed on this version.

Note that not only was the restriction not originally present in the OS_SpriteOp interface, it was only imposed on those commands implemented inside SpriteExtend, and no others.

It was… irritating.

However the JPEG problem was evident in RISC OS 5.18 (SpriteExtend 1.47 (03-Oct-2011)) so the problem is between versions 1.21 and 1.47. That was (probably) one of the reasons I stuck with 5.16 on the Iyonix rather than go to 5.18.

JPEGs with interlacing set give the not supported error from the current version of SpriteExtend.
You could try loading an interlaced JPEG in Draw with 5.16. That would confirm if these are the type of JPEGs giving the problem.

Chris H.
bq. 140: ABCLibrary 4.15 (06 Jun 2004) <———-
141: Obey support 0.04 (13 Nov 2002)
….. ZXNEW.TXT
130: ABCLibrary 4.14 (29 Nov 2002) <———-

Any of your problem apps require ABCLib?
v4.15 is downloadable from Paul Vigays module database links

Any of your problem apps require ABCLib?

I don’t think so…

v4.15 is downloadable from Paul Vigays module database links

… but I had 4.15 in my 5.16 boot so I’ll put that in the new boot. Shouldn’t the 520 HardDisc4 be updated to have the later ABCLib?

I have found two test version from TW (8.91) and EW (8.84) in my E-Mail archive. Martin send this to try it on my ARMini Prototype.
I try this on my Pandora with 5.20 and my docx. It works. ABCLib is not loaded. SharedCLib is 5.77, SpriteExtend 1.51. Jpegtrans to old?
I wanted try this on RPCEmu but 5.20 not run on it in a short time. It looks like it needs bigger changes.

I have found two test version from TW (8.91) and EW (8.84) in my E-Mail archive. Martin send this to try it on my ARMini Prototype.

Both Techwriter and EasiWriter are working as they are supposed to.
There are just certain types of JPEG that SpriteExtend doesn’t support. Allegedly there may be one type that previously loaded with the version of SpriteExtend (1.21?) that was in RISC OS 5.16.
Without an example it is difficult to tell. I’ve tested interlaced JPEGs back to 1.24 of SpriteExtend which was also not supported by this version.

That’s why I have my test file online. See above. I do not know Chris Halls files. Possible that he has a special problem. This is also the reason why I pointed out that the docx-files are Zip-files and so you can open and edit it individually. Some errors come from an unpredictable direction.

The image file
(http://www.svrsig.org/images/image1.jpeg) gives an error ‘JFIF file format not understood’ under both 5.20 and 5.16 (using !PhotoDesk) so that is probably the culprit. Under 5.16 TechWriter 8.90 loads a docx file containing it but under 5.20 it says ‘this version of SpriteExtend can’t handle the JPEG’. Dragging the same jpeg file to TechWriter causes this same error on 5.20 but not on 5.16. Hope this helps

First short test on my Pandora: !DPIngscan (Imagemaster) und !Variations can handle the jpeg.
My Techwriter ignore your jpeg in a Docx. If I import this jpeg … SpriteExtend error.
If I load the jpeg from the Docx with !Variations and save it unchanged, Techwriter can open the Docx.

(http://www.svrsig.org/images/image1.jpeg) gives an error ‘JFIF file format not understood’ under both 5.20 and 5.16.

Your example jpeg also has interlace set so that confirms the problem.

I’ve raised ticket #349. It’s an enhancement request to add support for JPEGs with interlace to SpriteExtend.

If I load the jpeg from the Docx with !Variations and save it unchanged, Techwriter can open the Docx.

It looks like resaving the JPEG must be removing the interlace. That’s why it then subsequently loads.

It’s an enhancement request to add support for JPEGs with interlace to SpriteExtend.

To add it back in, you mean. It was OK in an earlier version. Many thanks for raising the bug item.