C interface about fontdue HOT 6 CLOSED

I've never written a C interface in rust, and I'm unsure of the complexities involved with retro-fitting the library to support such an endeavor. I'm not sure I want to have to maintain a C interface as well. I'm open to the discussion though.

from fontdue.

Generally it's not too complex, and involves wrapping trait functions around in C style: struct_type.trait_method in Rust-land becomes lib_struct_type_trait_method(target). It's more boilerplate than retrofitting or design work. As mentioned, I'm happy to give it a shot--if anything comes of it, I'll set up a different repository with the possibility of eventually combining later, if you'd like.

from fontdue.

Alright, did a little work on this and it's been pretty straightforward so far. You can keep up to date/see what's involved at the project repo.

from fontdue.

Have run into an issue with struct privacy: part of writing a C interface is writing C-compatible structs which can be converted to and from library-side structs. This has been largely doable, since most of the private type info is in types that allocate and hence are probably best represented as opaque Box pointers.

The CharacterData struct is a container for a private bits: u8, but there's no way to read that information and no way to construct a CharacterData from a bits value. This means as far as I can tell it's functionally impossible to copy a CharacterData into a C-compatible version, which means I can't implement interface components involving CharacterData.

There are a couple of solutions that I can see, all of them library-side, if you wouldn't mind considering. Everything but the layout module is already working C-side, and I'd really love to be able to continue with the interface project, especially when the blockage is something so simple.

1. Make bits public. This would make creating CharacterData structs from bits instead of via ::classify doable, and it'd make the field readable.
2. Wrap that functionality with CharacterData::from_raw_bits and CharacterData.raw_bits() functions. This'd maintain the current API and privacy setup while allowing the interface to convert between C-compatible and Rust-side types.
3. I wouldn't mind merging the C interface with the main repo and maintaining it if you're interested. This way interface-side code could be in submodules, gated behind a compile feature, and would have full internal access and be able to robustly represent stuff C-side.

Addendum: have discussed with another person about this and it looks like it is possible to make a flat opaque type based on a transmutation of the original struct data (+ the private bit field), which means progressing with the interface is possible irrespective of action on your part. Would still like to hear your thoughts on the issue though!

from fontdue.

I've worked around this issue via a flattened opaque type using transmute, so I'll close it.

The complete C interface can be found here.

from fontdue.

Sorry I haven't replied sooner, real work has been eating my at home programming energy.

In general, I'm apprehensive to make internal state public because that's committing to supporting implementation details. That being said, this bitfield is kind of unnecessary and can probably be replaced with a couple of booleans. I'm fine if you want to submit a PR to replace the bitfield with a couple of public boolean fields for what's currently encoded.

If you plan on submitting a PR, please comment on #113 first. There's a license change in progress to a less restrictive triple license model.

from fontdue.