behdadMar 4

HarfBuzz 13.0.0 released with new experimental features: `hb-vector` for vector output of glyph outlines to SVG and `hb-raster` for rasterizing glyphs to A8 / BGRA32 images, among other features.

I would like to welcome our new contributors: Claude & Codex, without whom these new features would not have been possible.

https://github.com/harfbuzz/harfbuzz/releases/tag/13.0.0

Release 13.0.0 · harfbuzz/harfbuzz

New experimental drawing and rendering libraries: New public hb-vector API for vector output of glyph outlines. The only supported output format currently is SVG. The new API is available in a sep...

GitHub
Show threadgaytabaseMar 4
@behdad extremely disappointed to hear harfbuzz now includes AI contributions. will be replacing harfbuzz in all my software accordingly.
Show threadMax IorshMar 4
@dysfun @behdad
I understand your sentiment, but replacing with what? Uniscribe?
Show threadmcc
@iorsh @dysfun @behdad My preference at this point would be to go back to Harfbuzz 12, fork from there, and resume requiring contributors to agree to a DCO that affirms they did not use LLMs
Mar 4 at 11:36pmWeb
Show threadMax IorshMar 5
@mcc @dysfun @behdad
That's an interesting approach. I admit I'm a bit cynical here, as I myself just started to use it quite extensively after a long period of scepticism. But at least forking is somehow practical.
Show threadKhaled HosnyMar 5

@iorsh You approved FontForge PRs co-authored by Claude Code, are you going to fork FontForge as well?

@mcc @dysfun @behdad

Show threadMax IorshMar 5
@khaled
I said I understand @dysfun's sentiment, I didn't say I support it.
Show threadKhaled HosnyMar 5
@iorsh I misread you then. I was sincerely curious. @dysfun
Show threadJohannes LinkMar 5
@mcc @iorsh @dysfun @behdad Maybe we should agree on a common naming scheme and strategy for forking non-ai branches of projects. This way it would be easy to check if there’s a related non-ai project. In addition there should be a „nonai“ TLD so that domain-based package names are obvious as well.
Show threadAn Anarchist PigeonMar 5
@jlink @mcc @iorsh @dysfun @behdad AI bros would start falsely labelling their slop with it as soon as it caught on, because a lot of them are motivated by spite.
Show threadmccMar 5

@jlink @iorsh @dysfun One problem with this approach is it normalizes randomly generated code as the ordinary thing, and code written by humans as the exception. Wouldn't it make more sense to have big mandatory warning labels on anything created by the planet-boiling plagiarism machine?

I do agree there should be some kind of organized process for creating forks, though.

Show threadJohannes LinkMar 5
@mcc @iorsh @dysfun What can we control? I cannot force anyone to make warning labels, but I can choose the namespace I attach to something I fork.
Show threadmccMar 5

@jlink @iorsh @dysfun That's a good point, and don't let my comments dissuade you from doing a thing you think would be helpful.

I think the place to start is clear messages in contributor rules or DCOs banning agent contributions. I've got language for this in my own repos, but I don't think there's a standard/best practices text people could cut and paste. Of course, this isn't a quickly findable sign of quality, which is what you're seeking (contributor guidelines are in inconsistent places)