1. Take the files and figure out what to do with them so they can be read. This isn't a hard problem.
2. Ask everyone affected to email you the photo or a new photo of the documents. We'll just take it on trust that you do so honestly because there's no way you would've seen this coming.
That's not what happened at all. The college board admitted their fault and are letting students take the test again. Even without that, they mentioned in their FAQ that JPEGs and PNGs are the only file types acceptable and even sent out a tweet (which should have been an email) a week before especially for iPhone users to let them know how to take pictures as JPEGs.
I agree with the people blaming the board for not having a standard image input field that lets the OS know when to convert images to JPEG but that is their only fault and I wouldn't have thought of that as a bug deal if not for this issue. While I'm all for open source media formats replacing what we have, HEIC certainly isn't big enough to be considered as among standard input options. Also, isn't Apple themselves infamous for not supporting certain formats throughout their devices?
Emails, tweets, texts are no excuse for broken products. The iPhone is the best selling model in the United States. It is on College Board to support its default image format.
Good product design is owning your users' success. It is not sending people workaround emails.
The bare minimum would have to be to do a warning before every single AP test about this and giving students a few minutes to change their default image format. Sending a tweet (!!!) out does not count as doing any work.
This is a failure. An abysmal failure.
Perhaps Apple should make it easier or automatic to convert into a format that's universally usable.
Bet the same thing would have happened with webp images too.
JPG and PNG are like the FAT32 format of images. Always accepted, everywhere.
Further down this thread you’ll see that the board have messed up and they aren’t accepting images they should due to poor implementation.
“ oefrha 1 hour ago [–]
Tried a standard input tag with the proper accept attribute <input type="file" accept="image/jpeg,image/png" /> Selected a HEIC file from Photos in Safari, the selected image was automatically converted to JPEG”
That said, come on College Board. Fix your crap. What a stupid bug.
Since the user didn't specify a format, and the website didn't specify a format, the iPhone needs to guess something. Seems to me it should guess the format that's most likely to work, not the one only a tiny number of devices support.
"Give me the underlying data, just as it is. You may or may not understand what it is, but I'm asking you to pretend that you don't, because I definitely don't understand what it is. I'm acting as a courier on behalf of a recipient who wants whatever you give me. All they told me was to get it from you. Please don't try to guess why they want it, or to prepare it for them in some way. Their motivations are beyond our understanding. They just want it. They want what you have, the way you currently have it. Do as little to it as possible, because anything you do may be counter-productive to their unknowable designs."
This is, for one thing, the use-case of file-sharing websites. If you upload something to e.g. MEGA, or WeTransfer, you're doing that in order for something further to happen to it on the other side. The other side may or may not have wanted the file in its original format, but that question is up to them, not up to the sender. The job of a "dumb pipe" file-transfer service, is to take what it's given, and losslessly pass it on to the recipient, so that further steps can happen. And, as such, it's also a responsibility of a file-transfer service to ask the User-Agent to also send the file on to it losslessly, because in this case the User-Agent is also acting as part of the "dumb pipe" transfer process.
Let me put it this way: if my photos were not saving correctly, and someone at Apple asked me to file a Radar ticket and attach such a mis-encoded photo to the ticket... how would the Radar web-app express the intent of "I want the stupid mis-encoded file that you-the-device are using to store what you think is a Photos photo"? Well, our legacy convention is that it would express that intent through `accept="⋆/⋆"`. (Or a lack of an `accept` header at all.)
Note that this is different from an `accept` attribute like "image/⋆". In that case, we know something—we know that the recipient we're acting as courier has the intent to use the uploaded file as an image—so both the mis-encoded file, and maybe HEIC files, are probably bad candidates. One should be filtered out as an upload candidate; the other should maybe be transcoded (just like a RAW camera file would be.)