I noticed this bug in NSTextField already back last year but I procrastinated until I saw it the second time in the second Mac app I am building. I did have a workaround for the bug, so it was not that pressing.
But I guess we should consider it our duty as Mac developers to make sure that Apple knows about bugs for this platform. So finally here’s my Radar for it. rdar://13006140
That was an easy Radar for me to file. It’s not a bug, but it is bugging me nevertheless.
I am disturbed by the disparity between the NSShadowAttributeName attribute (which can only hold a single NSShadow) and CSS where you can have multiple shadows. Because NSHTMLWriter simply copies these to the CSS style of a span it should be quite easy to to also let NSHTMLWriter take an array.
It’s not a very important feature to have, but hey … it would give me some peace of mind. đ
Filed as Radar#12908144.
While researching the root cause for the UITextView line-height bug I also found another difference between attributed strings rendered via CoreText and UITextView. The latter ignores font kerning.
UITextView uses Webkit for displaying attributed strings. Unfortunately Kerning is disabled on Webkit views unless you specify a certain CSS style.
If you look at the AV characters you can see how the version with Kerning enabled has the AV seem at a more natural distance while the lower line has an uncomfortably wide distance between them.
In the Radar (which I filed under #12889869) I argue that when setting text on UITextView via setAttributedString we developers expect for Kerning to be on by default since this is the way that is closest to how CoreText renders it.
Read more
I’m working on making DTCoreText iOS 6 compatible and when implementing line heights I found this problem. Naturally I filed a radar.
This is one of many shortcomings of UIKit’s support for attributed strings. A workaround for this was described as having to omit font attributes from the attributed string. So you can either have multiple fonts and unchanging line height or only the font you set on the font property of UITextView.
Other people are having the same problem, as outlined by this question on StackOverflow.
Filed as rdar://12863734
That’s certainly a mouth full. We stumbled on this weirdness when working on PDF Importing for our iCatalog Editor. I am filing this as a Mac bug at the same time as communicating with DTS to see if they can offer a workaround for this problem.
The problem appears if a PDF is using a CMYK color blending space on a page for transparency blending. That causes this effect. Left side is how the PDF comes out on Mac, right side how it looks correctly on iOS (Simulator/Device). Also if you view the PDF in Preview or Pixelmator it looks weird, only in Adobe’s tools do they look correct.
If the behavior were the same on Mac and iOS then I would have thought to be Adobe using some weird special extension, but since the output is correct on iOS we think that this must actually be a bug. Maybe the Mac version of Quartz PDF rendering tries to do something smart since it is aware of color calibration but doing so messes up the colors.
Hot on the heels of my research into the responder chain comes this bug report. Nikita Korchagin deserves the main credit for mentioning this first to me.
Turns out that Apple broke the responder chain as it used to work on Mac and non-storyboard apps. I’m filing this as a bug report to find out if this indeed a bug or an “undocumented feature”. rdar://12402078
Update Oct 5th: Apple closed this as suplicate of rdar://12395544
This is one of those rare jewels of a bug that will cost you days to figure out if you encounter it in the context of a large app. It makes you doubt our own sanity until you come to the painful conclusion that the problem indeed resides in Apple’s code, not yours.
In this special case we had a couple of rare circumstances that worked together to form a scenario where CGRectMakeWithDictionaryRepresentation partially fails to reconstitute a CGRect from a dictionary. This function is literally ancient, it exists since iOS 2 and Mac OS 10.5. This makes it even more implausible that nobody has stumbled across this before us.
In the project where we first saw the problem these where the steps that led to this bug’s discovery:
What’s even funnier is that some such modified values can still be read, but then the function fails internally and the remaining values don’t get parsed, i.e. stay zero.
From what I have seen researching this bug looks like certain floating point numbers cannot be represented on iOS. The normal parsing functions are able to round to the closest value that can be represented in 32-bit floats, whereas CGRectMakeWithDictionaryRepresentation fails to do so. The first value that cannot be exactly represented is truncated, all following values turn out to be Zero.
This was filed as rdar://12358120 and on OpenRadar.
It is understandable to have this ominous “Natural Scrolling” setting for trackpads. And that there is a separate such setting for mice. But I don’t understand why Apple would like these two settings, because somebody working on a laptop might want to use the normal way to scroll with his mouse’s scroll while while using the “natural” setting for his trackpad.
Filed as Radar #12236447 and cross-posted on OpenRadar.
Updated March 6th, 2013: “Works as Intended”
I got an AppleTV for our office and brought over my old Sharp TV which is able to display 720p well enough to be used as a presentation display via AirPlay. When I tried to use AirPlay to display the desktop of a MacMini server I discovered this bug.
The workaround at the moment is to use the AirParrot software which has no problems displaying the desktop. I filed it as rdar://12167290 Â and mirrored it on OpenRadar.
Update Nov 7th: Apple closed the bug report as a duplicate of rdar://11782381.
Here’s another thing that I had discussed with an Apple engineer at WWDC. UIWebView at present does let you easily modify the user-agent header field that it sends to the server. We found this functionality sorely lacking when we needed to change the user-agent in iCatalog. There are some scenarios where the server-side browser-detection fails and you want to override the user agent for example with one to pretend the web view is desktop Safari.
This feature request was filed as rdar://11767306 Â and on OpenRadar.
License:
