Questions about feature support now vs. future vs. never

[wez]

What is the status/are your plans for:

• Anti-aliasing (greyscale and/or subpixel)?
• Fonts that embed PNG images, such as Noto Color Emoji
• Fonts that embed SVG, such as Twemoji Colr

[mooman219]

All planned, no status.

Fontdue does exact coverage, so grayscale is in there. Subpixel AA is planned, and relatively easy to add. I haven't settled on a design yet for exposing it, and one consideration I still need to think about is making sure the API is clear about how to blend subpixel AA'd glyphs, since it's easy to mess up.

Once a good rgb API is in there, then it should be easy to expose png (google spec), svg (microsoft spec), and COLR support (the firefox spec). The challenge here is a no-std parser on PNGs.

Also I'm on holidays rn and a wow expansion came out :)

[wez]

Also I'm on holidays rn and a wow expansion came out :)

It's important to take care of yourself! :-)

[bschwind]

The challenge here is a no-std parser on PNGs.

Do you have any plans on how you'll approach this? I could take a crack at it if it's something important to fontdue and you don't have a lot of time for it.

[mooman219]

I think the most time effective way to do this is to work with an existing png parser to see if you can PR a no-std patch, or fork it in general. PNGs are kinda involved.

[bschwind]

@mooman219 one more set of questions: Do you need streaming support? How about animated PNGs? Anything outside of just basic image metadata (width/height, bit depth, etc.) and the RGB data itself?

[mooman219]

No streaming or animated support should be necessary, but I admit I'm not the most well read here at this time. If you ever see an animated font, it's usually done through variation tables and not in actual animated pngs.

[bschwind]

Okay! If we just need something basic that can grab the RGBA data from a PNG in a no_std environment then I think I can write that. It seemed easier than retrofitting an existing library. I'll update you when I have something, but also let me know if you find an existing library that does what you need.

[bschwind]

@mooman219 I have the beginnings of a no_std PNG decoder here:

https://github.com/bschwind/png-decoder

I'm in the middle of the implementation so it's not usable yet, but figured I'd post it for now because I'm going to be traveling soon. I'm currently handling the "defiltering" of Adam7-interlaced data. It's all pretty naively implemented at the moment, and hopefully Adam7 isn't even used in emoji fonts but there's no reason it couldn't be, so I need to support it.

Also, am I using no_std in the right way? I haven't made a no_std library before, is it okay to depend on the alloc crate? I'll obviously have to remove the println! statements.

[bschwind]

@mooman219 I have something workable for PNG decoding:

https://github.com/bschwind/png-decoder
https://crates.io/crates/png-decoder

Let me know what you think, it should be fairly feature complete in terms of decoding what is necessary for any PNGs found in fonts.

[samyak-jain]

@mooman219 In light of the crate @bschwind has made, what would be the work necessary to add PNG support to fontdue?

[mooman219]

I usually just hack something together with the only goal being fast at raster time and then iterate on the actual usability of the API until complaints from the crowd die down.

I think I'd probably just make two rasterize functions, one for greyscale and one for full color, and give the color function an optional choice for RGB subpixel positioning. This would require being able to scale and convert a png into greyscale.

[yisibl]

Don’t forget that there is also the COLRv1 font. After Chrome supports it, this font format may become very popular because it supports variable fonts and gradients.