yeslogic / fontconfig-rs Goto Github PK

I feel it would be nice to hide the CStr's from the API here:

pub fn add_string(&mut self, name: &CStr, val: &CStr)

and have a type for the different kinds of key values,
which could then be safely converted internally to an FcPattern.

I am imagining a safe type something like

pub enum PatternKeyValue =
    Family: &str,
    Style: &str,
    :
    Lang: &str,
    Charset: u32,
    :
    Variable: bool;
    :

Any thoughts?

It looks like fontconfig-sys/src/lib.rs is licensed under Apache-2.0 or MIT but the Cargo.toml file only lists MIT. I guess it should read "Apache-2.0 OR MIT" in Cargo.toml?

Could you also add the Apache license text to fontconfig-sys as the license header talks about it?

This was noticed during the Fedora package review in https://bugzilla.redhat.com/show_bug.cgi?id=2141070

Thanks!

in some case, one font has many family name of each lang. I need get non-english FAMILY name, but use Pattern.get_string(FC_FULLNAME.as_cstr()), only one name will generate.

wldash uses this lib and is broken on aarch64 because of this lib: kennylevinsen/wldash#42

It seems you have fixes, but they're not released. Can you tag and push a new release for crates.io users?

Thanks.

relates to lapce/lapce#810

error: failed to run custom build command for `yeslogic-fontconfig-sys v3.0.1`

Caused by:
  process didn't exit successfully: `/home/user/projects/lapce/target/debug/build/yeslogic-fontconfig-sys-b0dccc281127be06/build-script-build` (exit status: 101)

The Pattern::font_match(&mut self) -> Pattern method borrows a Pattern and returns a owned Pattern making it very difficult to work with.

          let mut pat = Pattern::new(&fc);
          pat.add_string(FC_FAMILY.as_cstr(), &c_str);
          let pattern = pat.font_match();
                        ---------------- `pat` is borrowed here

/         return pattern;
|__________^ returns a value referencing data owned by the current function

I think it would be better if the old Pattern was moved like pub fn font_match(mut self) -> Pattern<'fc>.

I'm trying to cross compile my application from x86-64 Linux to aarch64-unknown-linux-gnu to build it for my Pinephone and I am stumbling over Slint's dependency on fontconfig. I tried using an ARM64 container to cross compile, but using emulation with QEMU requires 2 hours to build! Slint currently uses the unsafe servo-fontconfig crate, so I opened an issue for that, but I think it would be better to improve this crate and switch Slint to using this.

The servo-fontconfig crate falls back to statically linking a vendored copy of libfontconfig if pkgconfig does not find it. This is problematic for two reasons. Most importantly, using a different copy of fontconfig than the system doesn't work as desired. Also, fontconfig requires a lot of C dependencies that need to be linked, which makes it difficult to get the vendored copy to build:

moire on  main [$!] is 📦 v0.1.0 via 🦀 v1.58.1
❯ pkg-config fontconfig --static --libs
-lfontconfig -lfreetype -lz -lbz2 -lpng16 -lm -lm -lz -lharfbuzz -lm -lglib-2.0 -lm -lpcre -lsysprof-capture-4 -pthread -lgraphite2 -lbrotlidec -lbrotlicommon -lxml2 -lz -llzma -lm

A solution to this would be using the dlib to let the user of the library either directly link fontconfig at build time or use dlopen to load it at runtime and remove the build time dependency. I recently helped implement this for the Rust JACK bindings and it makes cross compiling really easy. The Rust Wayland bindings use dlib as well and the X11 bindings have a similar option to use dlopen with the x11-dl crate.

According to RUSTSEC-2023-0020 the const-cstr crate is abandoned and has soundness issues. It also performs a redundant null check every time a const_cstr is converted to a cstr, i'm not sure if the optimiser is smart enough to optimise away said check. The soundness issues seem pretty theoretical but still it seems like it would be a good idea to move away from said crate.

The cstr crate is able to construct real const cstrs with compile time checking, but unfortunately doing so requires at least rustc 1.64, i'm not sure what your MSRV policy is and whether that is appropriate. Alternatively you could use the unsafe function from_bytes_with_nul_unchecked directly which has been const since rustc 1.59.

Hi, there!

I recently used plotters in my project and I want to compile the project to x86_64-unknown-linux-musl on ubuntu20.04, then I met the error below

failed to run custom build command for `yeslogic-fontconfig-sys v3.2.0`

...
...pkg-config not configured for cross-compilation...
...

the fontconfig has been installed before compilation, but I can't find fontconfig-devel or fontconfig-dev on ubuntu.

May be someone can give me some tips?

Thanks!

Pattern::print dereferences the user accessible raw pointer Pattern::pat.

This is unsound because a use could change Pattern::pat without unsafe code and call Pattern::print to cause UB.

Requires the const_cstr_unchecked feature.

Hi, fedora use the source from crates.io to make package. it seem that the license is not include in the source of crates.io.

Having the file include in the crate source would ease packaging to not have to make a copy from github manually.

Hi there,

I have recently identified a lib name conflict between this crate and https://github.com/servo/rust-fontconfig,

I opened a thread here https://users.rust-lang.org/t/dependencies-links-resolver-conflict/87801/4
to illustrate a cohabitation incompatibilities between 2 major crates in their domain.

In my opinion, the solution of less effort would be to synchronize with the other lib to rename one or the other and remove the conflict.

What do you think of that solution ?

Resolving this conflict can improve a lot the Rust crates ecosystem, so I have opened a similar issue on the servo/rust-fontconfig repo
=> servo/rust-fontconfig#44
Open to discussion :)
Kind regards