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 >
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=: dfh&> cut ; <@(12&{.);._2 [ 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) ) smoutput hextable contents=: a.{~ hextable smoutput 'bytes written:' ; contents fwrite jpath '~/example1b.bmp' require 'bmp' echo s1=: 256 256 256&#.@|."1 (2 2 3$255 0 0 0 255 0 0 0 255 255 255 255) s1 writebmp 24;~jpath '~/bmp24bit.bmp' echo a. i. fread '~/bmp24bit.bmp' echo hextable -: a. i. fread '~/bmp24bit.bmp' s1 writebmp jpath '~/bmp4bit.bmp' echo a. i. fread '~/bmp4bit.bmp'
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
