Mike Day wrote:
> Please note that the viewmat function took some finding.

In j901-for-iOS, to find/edit the script which defines a given verb
   where'viewmat'
+++ locales: z
    open'j/system/ios/ios.ijs'

Notice that it doesn't just give you the path, but generates a sentence to
open(=edit) the said path, for you to re-input.

A more direct way to edit the script of a given jword:
   edit'viewmat'

To locate all nouns or verbs containing a given string, e.g. 'viewmat'
   find'viewmat'

Additionally, there are several _z_ nouns containing the paths to key
system scripts:
   namez 'PATH_'
PATH_IOSUTILS ...
...
PATH_VIEWMAT

>  I find “files” and “import” really opaque

I sympathize. But you can get used to anything… :-\

iOS was designed to (safely) consume content, not to create it, much less
re-engineer it or rip it off. And it shows.
Files are only grudgingly supported. You're supposed to use Export/Import
to transfer documents between apps, and only apps that are supposed to work
together. I.e. not files, and not a file-based system like J.

>  As I’ve embedded those scripts in “~user/mysystem”, I hope they won’t be
overwritten when J701 in the AppStore is updated.

Did you mean j901?
J701 has been frozen, and I've begged Apple to keep it available in App
Store for comparison purposes.
Both j701 and j901 will run simultaneously and independently.
When J901 gets updated (real soon now) it ought to preserve the "On My
iPad" files. But I wouldn't trust it to. Best to use Files app to copy the
whole of the j/ folder to iCloud Drive for a personal backup, before the
update happens. It's automatic: the general user gets no warning.

BTW --  j901 can load scripts directly from iCloud Drive. Use (the badly
chosen) Import symbol.

Ian Clark

On Mon, 10 Oct 2022 at 21:06, Ian Clark <[email protected]> wrote:

> > can you try some 4-bit and 8-bit bmp images from other sources, and
> verify whether they can be displayed on upgraded iOS/Mac?
>
> Do you mean other J sources, or non-J?
>
>
> jqt904 distribution contains the following bitmaps:
>
>
> /Applications/j904/addons/graphics/fvj4/nearp4m.bmp
>
> /Applications/j904/addons/labs/labs/examples/data/isitbar8.bmp
>
> /Applications/j904/addons/labs/labs/examples/data/j.bmp
>
> /Applications/j904/addons/labs/labs/examples/data/jbox.bmp
>
> /Applications/j904/addons/labs/labs/examples/data/jbw.bmp
>
> /Applications/j904/addons/labs/labs/examples/data/stdtbar.bmp
>
> /Applications/j904/addons/labs/labs/examples/data/toolbar.bmp
>
> /Applications/j904/addons/labs/labs/examples/data/toucan.bmp
>
> /Applications/j904/addons/demos/wd/j.bmp
>
> /Applications/j904/addons/graphics/bmp/jbox.bmp
>
> /Applications/j904/addons/graphics/bmp/toucan.bmp
>
>
> All the above are treated as corrupt by the latest Monterey and iOS.
>
>
> How do I tell if the bitmap is "corrupt"? Just by observing whether the
> Finder icon is the thumbnail of the image, or a generic icon. If generic,
> Preview cannot open it (…for all the examples I've tried)
>
>
> I've made a folder of all the bitmaps on my Mac. As a general rule, if
> it's a J bitmap (written by J or shipped with J) Monterey+iOS treat it as
> corrupt. If it's not a J bitmap, Monterey+iOS display its icon as a
> thumbnail.
>
>
> I do have a small number of "corrupt" bitmaps which are non-J -- they are
> all 1bit, 4bits, 8bits per pixel.
>
> I have not found any bitmaps: 1bit, 4bits, 8bits per pixel which are NOT
> corrupt - but I would need to check a lot of bitmaps to be sure of that.
>
> I have not found any difference in behavior between Monterey and
> iOS/iPadOS.
>
>
>
>
>
> On Mon, 10 Oct 2022 at 02:29, bill lam <[email protected]> wrote:
>
>> Ian,  can you try some 4-bit and 8-bit bmp images from other sources, and
>> verify whether they can be displayed on upgraded iOS/Mac?
>> I want to make sure if there are any bugs in bmp addon on pixel bmp.
>>
>> On Mon, Oct 10, 2022 at 7:42 AM Ian Clark <[email protected]> wrote:
>>
>> > Thanks Bill.
>> >
>> > I've been able to use your updated graphics/bmp to alter j scripts
>> *only*
>> > in
>> > j901-for-iOS as it currently resides on App Store, and fix viewmat.
>> > Altering the jscripts is something the iPad owner can do, without the
>> need
>> > to update the app itself.
>> >
>> > Existing j901-for-iOS users who have upgraded to the latest iOS and
>> iPadOS
>> > will find the upgrade breaks viewmat.
>> > Workaround:
>> >
>> > 1) Use pacman to update addon: graphics/bmp in a Mac running j904
>> >
>> > 2) copy the folder: ~addons/graphics/bmp/ to your iCloud Drive (to make
>> it
>> > visible on your iPad)
>> >
>> > 3) On your iPad, launch j901 if it's not already launched. Go the Home
>> view
>> > if it is not already showing: ⌘T
>> >
>> > 4) Use the Files App to copy folder: bmp/ into: j901/j/addons/graphics/
>> > […replace]
>> >
>> > 5) In j901 Home view, enter
>> >    load 'graphics/bmp'
>> >
>> > 6) Edit or redefine existing viewmat_z_ to replace the line:
>> >    mat writebmp f
>> > with:
>> >    mat writebmp f ; 24
>> >
>> > An update to the App Store app is ready-to-go as soon as I've finished
>> > testing it. Viewmat will work, and the above workaround won't be
>> necessary.
>> >
>> >
>> > On Sun, 9 Oct 2022 at 04:59, bill lam <[email protected]> wrote:
>> >
>> > > I have made a minor fix to bmp addon to fix DIB header size info.
>> Please
>> > > get the update from Pacman.
>> > > Nevertheless mac still can not recognize the bmp file of your 2x2
>> sample
>> > .
>> > > The reason may be bmp addon trying to optimize the bmp file size using
>> > > pixel table whenever possible by default.
>> > > by forcing 24-bit non-pixel output, it produces a bmp that can be
>> display
>> > > on mac
>> > > data writebmp 24;~ jpath 'some.bmp'
>> > >
>> > > My conclusion is that mac dropped support 4-bit bmp format, but you
>> can
>> > > workaround it by forcing bmp addon to use 24-bit bmp.
>> > >
>> > >
>> > >
>> > > On Tue, Oct 4, 2022 at 9:24 AM Ian Clark <[email protected]>
>> wrote:
>> > >
>> > > > I don't know. I asked Apple on 22 Sep 2022 but they still haven't
>> > > replied.
>> > > >
>> > > > Here's the code I've used to generate a BMP which *does* work on
>> latest
>> > > > iPadOS and macOS.
>> > > > This is what I call: Apple-compliant. Strictly speaking it is
>> > > > Wikipedia-compliant.
>> > > >
>> > > > NB.48 - generate sample bitmap / Apple TSI, Thu 22 Sep 2022
>> > > >
>> > > > NB. https://en.wikipedia.org/wiki/BMP_file_format#Example_1
>> > > >
>> > > > 0 :0
>> > > >
>> > > > Fri 23 Sep 2022 03:15:45
>> > > >
>> > > > -
>> > > >
>> > > > Produces very small bitmap. BUT Apple compliant.
>> > > >
>> > > > As it stands, 2835 px/m is 2.835 px/mm
>> > > >
>> > > > But increasing the print resolution (*16) no apparent difference.
>> > > >
>> > > > (But px/inch has gone down to 72)
>> > > >
>> > > > If substituted for j/slate/vmat1.bmp, 2x2 colors shown, but fuzzy
>> > edges.
>> > > >
>> > > > )
>> > > >
>> > > > cocurrent 'base'
>> > > >
>> > > >
>> > > > hextable=: x4f 0 : 0
>> > > >
>> > > > 42 4D "BM" ID field (42h, 4Dh)
>> > > >
>> > > > 46 00 00 00 70 bytes (54+16) Size of the BMP file (54 bytes header
>> + 16
>> > > > bytes data)
>> > > >
>> > > > 00 00 Unused Application specific
>> > > >
>> > > > 00 00 Unused Application specific
>> > > >
>> > > > 36 00 00 00 54 bytes (14+40) Offset where the pixel array (bitmap
>> data)
>> > > can
>> > > > be found
>> > > >
>> > > > DIB Header
>> > > >
>> > > > 28 00 00 00 40 bytes Number of bytes in the DIB header (from this
>> > point)
>> > > >
>> > > > 02 00 00 00 2 pixels (left to right order) Width of the bitmap in
>> > pixels
>> > > >
>> > > > 02 00 00 00 2 pixels (bottom to top order) Height of the bitmap in
>> > > pixels.
>> > > > Positive for bottom to top pixel order.
>> > > >
>> > > > 01 00 1 plane Number of color planes being used
>> > > >
>> > > > 18 00 24 bits Number of bits per pixel
>> > > >
>> > > > 00 00 00 00 0 BI_RGB, no pixel array compression used
>> > > >
>> > > > 10 00 00 00 16 bytes Size of the raw bitmap data (including padding)
>> > > >
>> > > > 13 0B 00 00 2835 pixels/metre horizontal Print resolution of the
>> image,
>> > > 72
>> > > > DPI × 39.3701 inches per metre yields 2834.6472
>> > > >
>> > > > 13 0B 00 00 2835 pixels/metre vertical
>> > > >
>> > > > 00 00 00 00 0 colors Number of colors in the palette
>> > > >
>> > > > 00 00 00 00 0 important colors 0 means all colors are important
>> > > >
>> > > > Start of pixel array (bitmap data)
>> > > >
>> > > > 00 00 FF 0 0 255 Red, Pixel (0,1)
>> > > >
>> > > > FF FF FF 255 255 255 White, Pixel (1,1)
>> > > >
>> > > > 00 00 0 0 Padding for 4 byte alignment (could be a value other than
>> > zero)
>> > > >
>> > > > FF 00 00 255 0 0 Blue, Pixel (0,0)
>> > > >
>> > > > 00 FF 00 0 255 0 Green, Pixel (1,0)
>> > > >
>> > > > 00 00 0 0 Padding for 4 byte alignment (could be a value other than
>> > zero)
>> > > >
>> > > > )
>> > > >
>> > > >
>> > > > NB. reduce px/inch --> 1/16 [0B13]--> [00B1]
>> > > >
>> > > > NB. hextable=: x4f 0 : 0
>> > > >
>> > > > NB. 42 4D "BM" ID field (42h, 4Dh)
>> > > >
>> > > > NB. 46 00 00 00 70 bytes (54+16) Size of the BMP file (54 bytes
>> header
>> > +
>> > > 16
>> > > > bytes data)
>> > > >
>> > > > NB. 00 00 Unused Application specific
>> > > >
>> > > > NB. 00 00 Unused Application specific
>> > > >
>> > > > NB. 36 00 00 00 54 bytes (14+40) Offset where the pixel array
>> (bitmap
>> > > data)
>> > > > can be found
>> > > >
>> > > > NB. DIB Header
>> > > >
>> > > > NB. 28 00 00 00 40 bytes Number of bytes in the DIB header (from
>> this
>> > > > point)
>> > > >
>> > > > NB. 02 00 00 00 2 pixels (left to right order) Width of the bitmap
>> in
>> > > > pixels
>> > > >
>> > > > NB. 02 00 00 00 2 pixels (bottom to top order) Height of the bitmap
>> in
>> > > > pixels. Positive for bottom to top pixel order.
>> > > >
>> > > > NB. 01 00 1 plane Number of color planes being used
>> > > >
>> > > > NB. 18 00 24 bits Number of bits per pixel
>> > > >
>> > > > NB. 00 00 00 00 0 BI_RGB, no pixel array compression used
>> > > >
>> > > > NB. 10 00 00 00 16 bytes Size of the raw bitmap data (including
>> > padding)
>> > > >
>> > > > NB. 01 00 00 00 ?? pixels/metre horizontal Print resolution of the
>> > image,
>> > > > 72 DPI × 39.3701 inches per metre yields 2834.6472
>> > > >
>> > > > NB. 01 00 00 00 ?? pixels/metre vertical
>> > > >
>> > > > NB. 00 00 00 00 0 colors Number of colors in the palette
>> > > >
>> > > > NB. 00 00 00 00 0 important colors 0 means all colors are important
>> > > >
>> > > > NB. Start of pixel array (bitmap data)
>> > > >
>> > > > NB. 00 00 FF 0 0 255 Red, Pixel (0,1)
>> > > >
>> > > > NB. FF FF FF 255 255 255 White, Pixel (1,1)
>> > > >
>> > > > NB. 00 00 0 0 Padding for 4 byte alignment (could be a value other
>> than
>> > > > zero)
>> > > >
>> > > > NB. FF 00 00 255 0 0 Blue, Pixel (0,0)
>> > > >
>> > > > NB. 00 FF 00 0 255 0 Green, Pixel (1,0)
>> > > >
>> > > > NB. 00 00 0 0 Padding for 4 byte alignment (could be a value other
>> than
>> > > > zero)
>> > > >
>> > > > NB. )
>> > > >
>> > > >
>> > > > smoutput $ hextable
>> > > >
>> > > >
>> > > > process=: 3 : 0
>> > > >
>> > > > z=. ''
>> > > >
>> > > > for_line. y do.
>> > > >
>> > > > z=.z , SP, TAB taketo line
>> > > >
>> > > > end.
>> > > >
>> > > > ;dec each b4o deb z
>> > > >
>> > > > )
>> > > >
>> > > > smoutput process hextable
>> > > >
>> > > >
>> > > > contents=: a.{~ process hextable
>> > > >
>> > > >
>> > > > smoutput 'bytes written:' ; contents fwrite jpath '~/example1b.bmp'
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Tue, 4 Oct 2022 at 02:09, bill lam <[email protected]> wrote:
>> > > >
>> > > > > What's the spec of apple compliant bmp format?
>> > > > >
>> > > > > On Tue, Oct 4, 2022, 9:00 AM Ian Clark <[email protected]>
>> > wrote:
>> > > > >
>> > > > > > Following recent security updates to macOS and iPadOS, they now
>> > > refuse
>> > > > to
>> > > > > > display bitmaps generated by addon graphics/bmp, or any bitmaps
>> > > shipped
>> > > > > > with j904. For example:
>> > > > /Applications/j904/addons/graphics/bmp/toucan.bmp
>> > > > > >
>> > > > > > However, if I copy this BMP file to my iCloud Drive, I can
>> display
>> > it
>> > > > > okay
>> > > > > > on a pre-Monterey macOS. This applies to all BMPs in the latest
>> > > addons
>> > > > > > folder (I count 11 such files).
>> > > > > >
>> > > > > > Other image formats: .jpg, .png are not affected (not fully
>> > tested).
>> > > > > >
>> > > > > > BUT macOS and iPadOS do still display bitmaps. I've verified
>> this
>> > by
>> > > > > > generating one of the sample BMP files published in
>> > > > > > https://en.wikipedia.org/wiki/BMP_file_format
>> > > > > > I'm happy to post my code, but it's only noise at this stage.
>> The
>> > > point
>> > > > > is:
>> > > > > > Apple has not withdrawn support for BMP, but tightened its
>> checks
>> > for
>> > > > > > compliance with the spec.
>> > > > > >
>> > > > > > This has broken viewmat in j901-for-iOS.
>> > > > > >
>> > > > > > It would be good to fix addon: graphics/bmp to generate
>> > > Apple-compliant
>> > > > > > BMPs, and replace the bad BMPs in all addons shipped with j904.
>> > That
>> > > > > would
>> > > > > > allow users to fix viewmat in j901-for-iOS without having to
>> wait
>> > for
>> > > > the
>> > > > > > bug release. But I cannot find the bug in graphics/bmp.
>> > > > > >
>> > > > > > In an earlier thread, I promised to take the matter up with
>> Apple.
>> > I
>> > > > did,
>> > > > > > but their reply is overdue.
>> > > > > >
>> > > > > > I am aware that viewmat in jqt now uses PNG not BMP. I confirm
>> that
>> > > the
>> > > > > > latest version of graphics/viewmat generates correct PNGs which
>> > > display
>> > > > > > okay on iPadOS, using the Files app. But j901-for-iOS needs
>> Swift
>> > > > > > code-changes and a full re-install from App Store before it can
>> > > > correctly
>> > > > > > handle the resulting ~temp/viewmat.png which will replace
>> > > > ~temp/vmat.bmp
>> > > > > .
>> > > > > > Simple in principle but messy in practice. I haven't worked out
>> how
>> > > > best
>> > > > > to
>> > > > > > do it.
>> > > > > >
>> > > > > > Ian Clark
>> > > > > >
>> > > ----------------------------------------------------------------------
>> > > > > > For information about J forums see
>> > > http://www.jsoftware.com/forums.htm
>> > > > > >
>> > > > >
>> > ----------------------------------------------------------------------
>> > > > > For information about J forums see
>> > http://www.jsoftware.com/forums.htm
>> > > > >
>> > > >
>> ----------------------------------------------------------------------
>> > > > For information about J forums see
>> http://www.jsoftware.com/forums.htm
>> > > >
>> > > ----------------------------------------------------------------------
>> > > For information about J forums see
>> http://www.jsoftware.com/forums.htm
>> > >
>> > ----------------------------------------------------------------------
>> > For information about J forums see http://www.jsoftware.com/forums.htm
>> >
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to