Hello!
Preface:
I'm trying to create a attributed string from an html text with bold marks (<B>) using the initialiser for NSMutableAttributedString with the html document type.
The issue: However, whenever the font is system font of size lower than 18, the constructed attributed string does not contain the bold attribute. I've tried a different font (Helvetica) and it worked normally.
Code:
let font = NSFont.systemFont(ofSize: 15)
let color = NSColor.textColor
let rgbColor = color.usingColorSpace(.deviceRGB) ?? NSColor(deviceRed: 0.0, green: 0.0, blue: 0.0, alpha: 1.0)
let cssColor = String(format: "rgba(%.0f, %.0f, %.0f, %0.2f)", rgbColor.redComponent * 255.0, rgbColor.greenComponent * 255.0, rgbColor.blueComponent * 255.0, rgbColor.alphaComponent)
let htmlString = "<html><head><title></title><style type='text/css'>" +
"body { font-family: '\(font.fontName)';" +
" font-size: \(font.pointSize)px;" +
" color: \(cssColor); }" +
"</style></head><body>I am not bold. <B>I am bold</B></body><html>"
print(htmlString)
guard let data = htmlString.data(using: .utf8, allowLossyConversion: false) else { return }
let string = try! NSMutableAttributedString(data: data, options: [NSAttributedString.DocumentReadingOptionKey.documentType: NSAttributedString.DocumentType.html], documentAttributes: nil)
print(string.description)
The resulting output from this code snippet is:
I am not bold. I am bold{
NSColor = "sRGB IEC61966-2.1 colorspace 1 1 1 1";
NSFont = "\".AppleSystemUIFont 15.00 pt. P [] (0x7fdb01705370) fobj=0x7fdb01705370, spc=3.98\"";
...
NSStrokeColor = "sRGB IEC61966-2.1 colorspace 1 1 1 1";
NSStrokeWidth = 0;
}
However if I increase the font size to 18 or change the font it works as expected:
I am not bold. {
NSColor = "sRGB IEC61966-2.1 colorspace 1 1 1 1";
NSFont = "\".AppleSystemUIFont 18.00 pt. P [] (0x7facfac1d7f0) fobj=0x7facfac1d7f0, spc=4.56\"";
...
}I am bold{
NSColor = "sRGB IEC61966-2.1 colorspace 1 1 1 1";
NSFont = "\".SFNS-Regular_wdth_opsz120000_GRAD_wght2BC0000 18.00 pt. P [] (0x7facf9f049c0) fobj=0x7facf9f049c0, spc=4.15\"";
...
}
Helvetica 15 works:
I am not bold. {
NSColor = "sRGB IEC61966-2.1 colorspace 1 1 1 1";
NSFont = "\"Helvetica 15.00 pt. P [] (0x7fd883c28850) fobj=0x7fd883b1c310, spc=4.17\"";
...
}I am bold{
NSColor = "sRGB IEC61966-2.1 colorspace 1 1 1 1";
NSFont = "\"Helvetica-Bold 15.00 pt. P [] (0x7fd883c28850) fobj=0x7fd883b1f320, spc=4.17\"";
...
}
Is there a way to fix this issue by changing some parameters or is this a fool's errand and I should try to write my own parser that would apply these attributes?
Post
Replies
Boosts
Views
Activity
Hello!
After submitting two OSSystemExtensionRequest (let's say Endpoint and Network extensions), when the user allows only one (endpoint) extension, we receive request: didFinishWithResult callback for both manager delegates. This leads us to falsely believe that both our extensions are allowed.
We tried to prevent this by using propertiesRequestForExtension where our (network) delegate will ask for properties, check if the given extension is enabled and then finish if it's ok. If it's not enabled, however, we receive no second callback when the user allows the other extension.
We thought that we would need to submit another OSSystemExtensionRequest for the extension that wasn't allowed to receive a callback when it finally is. However, the second and all other consecutive requests immediately finish and we receive request: didFinishWithResult even when the user does not allow the second extension.
Example:
Endpoint and Network managers submit OSSystemExtensionRequest
User only allows Endpoint extension
Endpoint manager checks the properties, finds out it's enabled and finishes
Network manager checks the properties, finds out it's disabled
Network manager sends another OSSystemExtensionRequest
Network manager immediately receives request: didFinishWithResult
Network manager checks the properties, finds out it's disabled
....
This loop ends when the user finally allows the network extension, when the manager finds out that it's enabled. Is there something we are missing? Shouldn't another OSSystemExtensionRequest finish with requestNeedsUserApproval. How should we go about this issue?
Many thanks, Denis
Hello!
Is it possible to add location permissions to a macOS system extension?
We have a network firewall system extension that also considers WIFI connections in its rules. With the release of Sonoma, interface information is only accessible while having location permissions, which we are having trouble asking for.
We have the entitlements, the usage description, but the authorizationStatus of CLLocationManager stays at .notDetermined and no window for location permission pops up after calling requestAlwaysAuthorization().
What we need is to get the SSID of the network that the interface is connected, its security and encryption type. If the permission is not possible, is there a workaround?
Cheers
Hello!
As a foreword, our issue is not on any version prior to macOS Sequoia.
While testing our content filter on Sequoia, we found out that localhost traffic/flows were not being forwarded to the filter for evaluation. When setting up our default settings, we apply these rules that would forward loopback traffic to our filter:
let ipv4localhost = NWHostEndpoint(hostname: "127.0.0.1", port: "0")
let ipv4localhostRule = NENetworkRule(remoteNetwork: ipv4localhost, remotePrefix: 0, localNetwork: ipv4localhost, localPrefix: 0, protocol: .any, direction: .any)
let ipv6localhost = NWHostEndpoint(hostname: "::1", port: "0")
let ipv6localhostRule = NENetworkRule(remoteNetwork: ipv6localhost, remotePrefix: 0, localNetwork: ipv6localhost, localPrefix: 0, protocol: .any, direction: .any)
let filterSettings = NEFilterSettings(rules: [NEFilterRule(networkRule: ipv4localhostRule, action: .filterData), NEFilterRule(networkRule: ipv6localhostRule, action: .filterData)], defaultAction: .filterData)
We found out that these initialisers are deprecated in Sequoia https://developer.apple.com/documentation/networkextension/nenetworkrule/3143646-init and are replaced by https://developer.apple.com/documentation/networkextension/nenetworkrule/4365499-init.
After replacing the deprecated calls, we do indeed see loopback traffic in the filter again.
Our question is, is this intentional? Will deprecation of these methods mean that the "old" code will not work with macOS Sequoia anymore, or is it a bug?
I'm asking this as it will force us to upgrade our builder nodes to be able to compile the new code, however as everything is still in beta there is a higher risk of problems that could accompany this.
Thanks in advance, I wish you a nice day.