Ok, this is partly since think my last experiment with pixel colour testing was coming across issues trying to determine colours of pixels on an uploaded image files, based on the coordinates, etc., so, in this experiment, I have now added on to generating the images from scratch, programmatically, with the idea being that I can then be pretty sure what the colour of each and every pixel should be - to a certain extent, due to edges of shapes, overlay, etc. etc. Either way, on this page, it will let you select 4 guidelines relating to the image to then be generated - dimensions, background colour, foreground colour, and the shape to make use of, ranging from choices of a diagonal line from either top left to bottom right, or bottom left to top right, or a filled in circle shape, in the middle of the image file, with a diameter of roundabout 5 pixels less than total image width/height: http://www.blindza.co.za/gd/index.php When you then hit enter on the form submission button, it will in fact leave that page there, and pop up two separate pages - one of them being the output/generated image, displaying in a browser window, and the second page that also pops up will be another form of experimental page, where I am then generating/rendering an HTML table, with the same number of cells as the actual image has pixels, and with each table cell containing a period character, but, rendering as it's colour style, the colour of the matching pixel on the image file itself. In other words, if I navigate to that table (some screen readers might ignore it as a form of layout table, instead of a data table) using jaws now, and then move down to like 5th row, in the 5th column, I can then use the jaws key + number row 5, and it will tell me something along the lines of grey/white on white if I am then sort of hovering over/near something that should be rendering as a pretty much white/grey pixel on a darker background colour - jaws will pretty much always tell me 'on white' since it's working with it's virtual buffer version of page, but anyway - or something like that. I have also told this table to render as a table with a border width of 0 pixels itself, and with a font-size of 3pt, with the idea being that sighted guys might be able to sort of compare it to the generated image which will pop up in the other window, but, my guess is it will render like a sort of pixelated/granular/old-dotmatrix-style-rendition of the image as such...<smile> Maybe just now I'll try out turning on full screen display mode in internet explorer, and try comparing the vOICe rendition of the grid window with the vOICe rendition of the image file itself, but, suppose should also first make sure both parts of output are rendering how I want them to - some people already tested just the image file rendition for me, and it seemed to be doing what I told it to...<smile> Lastly, if there are too many issues with me opening both of the output windows in popup/new windows, using target="_blank" and javascript, maybe I'll switch it over to both parts rendering in one window that gets accessed directly, in the same initial window frame, but, part of the reason for handling these in separate windows is that I need the one rendering the image file to actually generate the image binary/file itself, and the grid output page is literally pausing 1 second, before execution, and then loading an instance of that image file into an object to then go determine the colour of each pixel, etc. The source of all these pages is here as well, if interested: https://dl.dropbox.com/u/13327195/gd.zip Stay well Jacob Kruger Blind Biker Skype: BlindZA '...fate had broken his body, but not his spirit...' -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
