Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift at Apple: Migrating the TrueType hinting interpreter

swift.org

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#131

Post by airstrike »

stasomatic wrote: post #129
kibwen wrote: post #125

Earlier quoted context omitted.

I can assure you that Rust will never have a ++ operator. Not only is it semantically bizarre, it's entirely unnecessary in a language where iteration is overwhelmingly performed via iterators rather than via manually incrementing array indices.

Is that a bullet point in the Rust manifesto? :) In any case, ++ has taken another meaning outside of operator loading and such some. The “Rust” branding, to this rando, implies corrosion, oxidation, decay, regardless of the true origin of the name. Swift is “quick”, Java is “caffeine”, Rust is something I need kerosene for.

Rust isn't named after what you think it is, but after fungi.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#132

Post by AndriyKunitsyn »

dcrazy wrote: post #124
AndriyKunitsyn wrote: post #115

Earlier quoted context omitted.

I’m not your child, and that’s false, it’s literally one key to change in the settings. That allows you to select the exact scaling factor, not macos’s “more text”/“less text”.

Have you ever tried to write HiDPI-aware Win32 code? I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps. Mac OS X 10.4 tried the same thing (Quartz2D scaling) and it was so damn difficult that they threw it out and went for simple 1x/2x/3x auto-scaling. Even 3x was a challenge because of pixel alignment.

Well, you were talking about testing, development of DPI-aware apps is another thing. It requires the developers to be, well, DPI-aware, but I don't think there are particular obstacles to that in winapi itself.

>Have you ever tried to write HiDPI-aware Win32 code?

I haven't. I don't think there's any reason to, I'm more of a wxwidgets fan. I don't think even Microsoft makes applications in raw WinAPI.

>I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.

The default behaviour of a DPI-unaware app in Windows is to scale everything by the scale factor. Which - yes, looks completely awful and blurry, but that's not what you describe.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#133

Post by AndriyKunitsyn »

mschuster91 wrote: post #81
AndriyKunitsyn wrote: post #67

Earlier quoted context omitted.

What kind of windows programs are these? HiDPI is more than a decade old. A desktop application, no matter what OS it is, should always be tested with different scaling factors.

Ham radio software, both open-source and commercial, is a big thing, and so is many an in-house development in many businesses.

Any particular program? GNU Radio seems perfectly fine.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#134

Post by steve1977 »

geon wrote: post #116
ahartmetz wrote: post #97

Earlier quoted context omitted.

Lower DPI is quite okay with good font rendering (FreeType, slight hinting, subpixel rendering). I have both kinds of devices.

I get kind of nostalgic when I see Verdana on 1024x768 in winxp/2k.

ClearType was/is a nifty technology. I remember I had a HP Jornada PocketPC that came preloaded with The Time Machine to show off ClearType.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#135

Post by leecommamichael »

KolmogorovComp wrote: post #88

> Operations like filter and map allocate memory, but that allocation is only necessary if the value escapes. The Swift standard library provides .lazy.map and .lazy.filter, but they don’t work in every case. For logic that only iterates over the filter or map, it’s much more efficient to loop with continue (or use for … in … where) and transform elements into local variables as necessary. It does feel like a compile…

It isn't. You'd need full lifetime analysis as part of the compiler to even decide whether you _could_ skip the allocation, and even then it's 100% up to the circumstance and actual lifetime of the data to say whether it can be, e.g. stack-allocated to avoid placing it somewhere less localized.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#136

Post by stasomatic »

steveklabnik wrote: post #130
stasomatic wrote: post #129

Earlier quoted context omitted.

Is that a bullet point in the Rust manifesto? :) In any case, ++ has taken another meaning outside of operator loading and such some. The “Rust” branding, to this rando, implies corrosion, oxidation, decay, regardless of the true origin of the name. Swift is “quick”, Java is “caffeine”, Rust is something I need kerosene for.

Yes, it is pretty universally agreed upon that a ++ operator in Rust doesn’t make any sense. += 1 is barely longer, not special cased, and does not make users memorize odd precedence rules.

It doesn’t matter, I was speaking in terms of branding. There is ++ in C, but C is not C++.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#137

Post by steveklabnik »

stasomatic wrote: post #136
steveklabnik wrote: post #130

Earlier quoted context omitted.

Yes, it is pretty universally agreed upon that a ++ operator in Rust doesn’t make any sense. += 1 is barely longer, not special cased, and does not make users memorize odd precedence rules.

It doesn’t matter, I was speaking in terms of branding. There is ++ in C, but C is not C++.

Right, but the whole reason C++ is named C++ is because ++ is a valid operator in C. Without the operator in Rust, making the brand of a successor based on a feature from an entirely different language doesn't make any sense.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#138

Post by WalterGR »

raphlinus wrote: post #126
WalterGR wrote: post #77

Earlier quoted context omitted.

> high performance text Just strings or rendering strings? If the latter, who are the other members of the club?

Yeah, probably should have made a more substantive comment. I'm mostly thinking of the trio of Skrifa, Harfrust, and Parley, but there is other open source Rust work that qualifies as well. There's also, very relevantly, the DWriteCore work from Microsoft. My understanding is that there's been some talk of open sourcing that, but it's still proprietary. There are other things that count as high performance text in me…

Thanks.

Skrifa - Skia in Rust. https://github.com/googlefonts/fontations/tree/main/skrifa , https://developer.chrome.com/blog/memory-safety-fonts

Harfrust - HarfBuzz in Rust. https://github.com/harfbuzz/harfrust , https://github.com/googlefonts/oxidize

Parley - text layout in Rust. https://github.com/linebender/parley

DWriteCore - the Windows App SDK implementation of DirectWrite. https://learn.microsoft.com/en-us/windows/win32/directwrite/...

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#139

Post by numist »

yyyk wrote: post #90

"we used a fuzzer to minimize a corpus of 10 million PDF files down to 4,200 without any loss of code coverage" Did they need a fuzzer for that? They could've render them all and see what's exercised?

We did "render them all and see what's exercised" by using libFuzzer's -merge=1 option. No new PDFs were generated during corpus minimization.
Post reply on HN