User Profile

I'm trying to render a UIView to PDF, while maintaining text elements as actual text and not rasterizing them. I'm using TextKit 2 backed UITextView and NSTextLayoutManager to provide the contents. However, no matter what I do, UITextView gets rasterized into a bitmap. Here's the basic code: let renderer = UIGraphicsPDFRenderer(bounds: pageRect, format: format) let data = renderer.pdfData { (context) in for page in self.pageViews { context.beginPage() let cgContext = context.cgContext page.layer.render(in: cgContext) } } A page view usually contains one UITextView, which uses somewhat advanced layout, so unfortunately I can't just toss it into a single NSAttributedString and draw into a CoreText context. There's a hack to get UILabels to render themselves as non-rasterized text, and if I understand correctly, it works by just actually drawing them on the current context. Interestingly, when providing UILabel view via NSTextAttachmentViewProvider to a text view using TextKit 2, the UILabels inside a text view won't get rasterized. In the image below, the paragraph is a bitmap, while the heading is real text. This hinted that the actual text fragments are the ones that get rasterized when drawing, not the whole view, and I was right. I can enumerate the text fragments and draw them directly on the context, which makes them remain as text rather than become a bitmap: page.textView?.textLayoutManager?.enumerateTextLayoutFragments(from: location, options: [.ensuresLayout, .estimatesSize, .ensuresExtraLineFragment], using: { fragment in let frame = fragment.layoutFragmentFrame fragment.draw(at: frame.origin, in: cgContext) return true }) This causes other issues, because layout coordinates will be all over the place and not confined to the text view itself (and even more so for my custom NSTextLayoutFragment class). I can get around this, but my text attachments won't get drawn this way either, but display a skewed placeholder icon: I can render them correctly on the context manually: if fragment.textAttachmentViewProviders.count > 0 { if let view = fragment.textAttachmentViewProviders.first?.view { view.layer.render(in: cgContext) return true } } This renders them at 0, 0 though. Edit: Changing bounds or frame for view/layer has no effect. I'm wondering if there is a way to make UITextView and NSTextLayoutManager to draw their contents this way automatically, so the fragments would remain as text in the PDF, rather than become a bitmap? It seems weird that the text view doesn't do this by default like it does on macOS, especially as it appears to be entirely possible. Or, if that's not possible, what's the correct way of drawing my text attachments when enumerating NSTextLayoutFragments?

I'm getting random crashes in a background thread in my document-based app. NSDocument(NSDocumentSaving) causes EXC_BAD_ACCESS (SIGSEGV) / KERN_INVALID_ADDRESS Thread 10 Crashed:: Dispatch queue: com.apple.root.default-qos 0 libobjc.A.dylib 0x00007fff2020581d objc_msgSend + 29 1 com.apple.AppKit 0x00007fff237b1909 __85-[NSDocument(NSDocumentSaving) _saveToURL:ofType:forSaveOperation:completionHandler:]_block_invoke_4.860 + 245 2 libdispatch.dylib 0x00007fff201bc623 _dispatch_call_block_and_release + 12 3 libdispatch.dylib 0x00007fff201bd806 _dispatch_client_callout + 8 4 libdispatch.dylib 0x00007fff201bfe37 _dispatch_queue_override_invoke + 775 5 libdispatch.dylib 0x00007fff201cc818 _dispatch_root_queue_drain + 326 6 libdispatch.dylib 0x00007fff201ccf70 _dispatch_worker_thread2 + 92 7 libsystem_pthread.dylib 0x00007fff20364417 _pthread_wqthread + 244 8 libsystem_pthread.dylib 0x00007fff2036342f start_wqthread + 15 I'm wondering how I could start debugging the issue, and need some help with deciphering the crash log. Am I correct, that based on the error log, the NSDocument which is being saved does exist? In that case, it would be just some other variable which has disappeared somewhere, meaning either the NSURL or completionHandler? Or is the whole NSDocument a corpse at this point? The crash occurs very randomly, so it's pretty hard to reproduce reliably. EDIT: I found a GitHub issue with the exact same problem. Their research points to this being a race condition, which occurs when asynchronous autosave is in progress and an edit to NSDocument is being performed. However, if I disallow asynchronous autosaves (canAsynchronouslyWriteToURL), drafts don't seem to get saved at all. Is there anything I can do to prevent the asynchronous race condition?