Jan 22, 2013
There are apparently a great many views on Mac that don’t behave properly if you enable layer-backing. I recently reported a bug in drawing NSTextField backgrounds together with layer-backing, now here is a bug I found in NSBox.
Filed as rdar://13059657
Jan 14, 2013
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
Dec 19, 2012
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.
Dec 16, 2012
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.
Dec 12, 2012
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
Dec 03, 2012
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.
Sep 30, 2012
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
Sep 24, 2012
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:
- Create a CGRect that is not an integer
- Write a dictionary from iOS simulator which contains a dictionary encoding this CGRect
- Open this dictionary in Xcode’s property list editor
- Upon saving some of the least significant digits change in the “real” items
- This new dictionary can no longer be parsed on iOS
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.
Sep 05, 2012
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”