Thanks very much Neil. Much appreciated.
I am unfortunately out of the office for the night, so I can't get access to the files or DPS, but I will share the folio first thing in the AM.
In the meantime though my team and I started doing some testing, as we were really concerned that the imagery in our app was what was causing the issues.
As I mentioned earlier, we had swapped much of the imagery in our app for .jpgs that are rendered at the correct pixel dimensions they appear at in the app.
We tried quickly swapping out a few of the higher res, and larger file size images for these smaller, compressed .jpgs After running the folio through DPS it seemed to impact file size very little (only dropped the file size a couple of hundred kb) - I am guessing this is due to what you were saying about DPS automatically resizing most images to 108ppi etc.
Dropping to a single orientation definitely had a major impact on the file size. (822Mb for dual vs. 540Mb for single)
Unfortunately the dual orientation is something we have been locked in to by our client.
for this particular app the client is very picky about the image quality and they have made it a requirement that the app support retina display.
Our initial tests running a 1024x768 file and upscaling on the newer iPad didn't have the best results, as the image compression and upscaling left our pixel imagery looking less than optimal.
I finally managed to find this: http://blogs.adobe.com/digitalpublishing/files/2012/03/DPS_iPad3_bestpractice.pdf
This PDF has a section on file size, and describes using a 1024x768 with images at 144ppi folio for both retina and non-retina display
Would starting with a 1024x768 file and then building a retina folio with those files drop our file size?? or would DPS scale the images up for retina and then result in a similar file size?
