Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Road to Pure Rust #321

Closed
mitchmindtree opened this issue Feb 21, 2015 · 22 comments · Fixed by #710

Comments

@mitchmindtree
Copy link
Member

commented Feb 21, 2015

Requiring users to compile / install C libraries is a real pity. It would be amazing if Conrod required nothing more than

[dependencies]
conrod = "*"

I think we still have two dependencies that require having C libraries installed on the user's system:

  • SDL2

This is only used for the example, but should be easily replaced by glutin :) #312 Conrod is now backend agnostic and all examples now use glutin.

  • FreeType

This one may be trickier to handle. Is anyone aware of any purely rust font-rendering? Now replaced with rusttype!

@bvssvni

This comment has been minimized.

Copy link
Member

commented Feb 21, 2015

Text is basically vector shapes, and Valve has a paper on that http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

@jhasse

This comment has been minimized.

Copy link
Member

commented Jun 7, 2015

@bvssvni The paper is only about rendering vector shapes, not about loading font files, which is also a big part of FreeType's job.

I don't think FreeType can ever be replaced. It should rather just ship with Rust (on Windows / OS X) so that users don't need to install it.

@viperscape

This comment has been minimized.

Copy link

commented Jun 8, 2015

svg has a font and text spec. I was actually looking into this, but realized how complex svg is, even "tiny" spec. So I've been wondering about an xsd parser, to parse the data structure in to rust. Any ways, svg might be an alternative to consider

@viperscape

This comment has been minimized.

Copy link

commented Jun 8, 2015

@bstrie

This comment has been minimized.

Copy link

commented Jun 10, 2015

Could a cargo-feature be used to completely disable the need for freetype? For example, many of the examples in the piston-examples repo don't need freetype for anything, but you still must manually install it in order to compile the examples, which is quite annoying.

@bstrie

This comment has been minimized.

Copy link

commented Jun 10, 2015

It should rather just ship with Rust (on Windows / OS X) so that users don't need to install it.

@jhasse, are you suggesting that the Rust developers should ship freetype binaries in the standard Rust distributions? Because that seems very out of scope for the Rust project.

@jhasse

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

@bstrie

This comment has been minimized.

Copy link

commented Jun 11, 2015

Rust is a general-purpose systems programming language and freetype is a library for font rendering. It's not Rust's responsibility to provide a font rendering library on platforms where freetype does not exist.

@jhasse

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

It's already shipping a few MinGW libraries though, but you're right: It shouldn't ship by default.

Doesn't the freetype-sys cargo package handle the installation now automatically?

@bstrie

This comment has been minimized.

Copy link

commented Jun 11, 2015

They're actually in the process of moving away from MinGW and onto the native toolchain. It seems like the same approach should be taken here: surely Windows and OS X provide some native libraries for font rendering?

@jhasse

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

Not everyone agrees with that though.

FreeType is a well tested library and it's open source. Why waste days of reimplementing it and get vendor locked on Windows and OS X? What are the benefits when cargo already solves the installation issue?

@bstrie

This comment has been minimized.

Copy link

commented Jun 11, 2015

Does cargo solve the installation issue? I've never seen a cargo build that fetches binary blobs before.

I'm not saying that we need to get vendor locked. I'm saying that Windows and OS X must already provide some mechanisms for font rendering, so we could just use #[cfg] to select the proper implementation at compile-time. Presumably this would be a crate of its own. This way we could leverage freetype on the platforms where it's natively available while avoiding the need to install a third-party binary on the platforms where it's not.

@jhasse

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

Let's say Microsoft decides to interpret some part of the ttf file format standard in its own way, then those files would only work on the Windows implementation of conrod, thus: vendor locked.

Also the implementations will certainly differ, resulting in platform specific bugs.

@bstrie

This comment has been minimized.

Copy link

commented Jun 11, 2015

If you don't want to bind to the platform-native APIs, then you'll need to implement some minimal font renderer in Rust. You likely don't need the full flexibility of freetype, so the scope is at least somewhat reduced.

You might still think that we should just be shipping freetype, but remember that the whole point of this bug is to consider a future where we don't need to ship third-party C libraries. :P

@bvssvni

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

Some time in the future, there could be a pure Rust alternative to FreeType with meta rules for human readable formats and binary formats, which will make it possible to read most formats or create your own. This could be combined with back-ends for font renderers, such that you can apply special effects etc.

@bvssvni

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

Conrod does not depend on FreeType, but it uses piston-graphics who needs a graphics back-end, and this back-end might depend on FreeType, which is the case with opengl_graphics. It is possible to write a custom graphics back-end that uses a texture alias for fonts, or it could do something else.

@jhasse

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

Just tested on Windows: It's true, cargo doesn't automatically download freetype :(

Btw: Julia is solving this issue by providing a package for installing dependencies on Windows: https://github.com/JuliaLang/WinRPM.jl
I'm using it in my FreeType wrapper for Julia: https://github.com/jhasse/FreeType.jl/blob/master/deps/build.jl

@bstrie Yes, and I'm arguing for WONTFIX ;)

@bvssvni Since nearly all fonts are shipping as ttf or otf files, it would be a real pity if conrod couldn't use them.

@DavidWilliams81

This comment has been minimized.

Copy link

commented Jun 11, 2015

Hi guys, I'm just watching Piston idly from the sidelines (hope to try it out soon) but just wanted to make sure you were aware of stb_truetype.h. It's much lighter (and more basic) than free type, but is a public-domain single-header C library for loading truetype fonts. Perhaps it can be ported to Rust and/or integrated in your toolchain.

Just a thought, probably not practical ;-)

@bvssvni

This comment has been minimized.

Copy link
Member

commented Jun 11, 2015

@DavidWilliams81

This comment has been minimized.

Copy link

commented Jun 11, 2015

@bvssvni No problem, the whole stb repo is nice for C programmers so maybe there's some other useful snippets for you.

@daogangtang

This comment has been minimized.

Copy link

commented Feb 16, 2016

RustType is the rust replacement to freetype.

@mitchmindtree

This comment has been minimized.

Copy link
Member Author

commented Feb 16, 2016

@daogangtang thanks, I've opened up an issue to track the change towards rusttype at #695.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.