It prevents squandered effort and speculative, unproductive wild goose chases by frustrated users seeking a solution.Īdobe has over 10,000 employees. It increases customer satisfaction since they receive quick feedback the software vendor is working on the problem, even if not fixed. This expedites symptom search by the user base, which reduces overall support burden to the manufacturer. Even if no fix exists, it succinctly describes the problem scope. The purpose of a KB article is to document a common problem, whether a fix exists or not. Since then I've learned that Apple (Final Cut, Aperture), Microsoft (Office), and Adobe (Lightroom, Photoshop, Illustrator) have ALL reworked software to better function with Retina displays. My first post on this (nearly two weeks ago) was prior to researching this a lot further. It's kind of hard to write a KB article on a fix when there isn't one yet. It should state the problem symptoms, cause (if known), any workarounds, and the current investigative status. There should be a knowledgebase article written by an Adobe Support Engineer which is the first item returned by a Google query on these symptoms. This is a serious problem and I have no idea how people who use large PDF files for professional work can endure this. You can easily stack up commands where Adobe Reader keeps trying to process them long after removing your hands from the keyboard. Problem replication scenario: Successive page down/up operations via fn down arrow or fn up arrow are very slow. I am not using a Retina display, but a 27" 2012 i7 iMac 16GB. Tried changing to "none" - no difference seen. Smooth Text is set to "For Laptop/LCD screens". No difference seen.Īdobe Reader\Preferences\Page Display\Resolution is set to "use system setting: 108 pixels/inch". Tried changing to software rendering in case it's an OpenGL or GPU device driver bug. Additional: Tried using OpenGL 1.4 as preferred renderer in Adobe Reader\Preferences\3D
0 Comments
Leave a Reply. |