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

Reply via email to