-
Notifications
You must be signed in to change notification settings - Fork 14
Make it possible to make Haskell bindings for C libraries that depend on freetype #3
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
base: cabalization
Are you sure you want to change the base?
Conversation
The adaptation of the cjk auto-hinter module to blue stringsets in 2013-08-25 had three severe bugs. Mea culpa. 1. Contrary to the latin auto-hinter, characters for reference and overshoot values of a blue zone are specified separately. Due to the screwed-up change it didn't work at all. 2. A boolean comparison was erroneously replaced with a cast, causing invalid results with the `^' operator later on. The visual artifact caused by this problem is the topic of the bug report. 3. Two flag values were inverted, causing incorrect assignment of reference and overshoot values. * src/autofit/afblue.dat: Fix CJK bluestrings, introducing a new syntax to have both reference and overshoot characters in a single string. This is error dagit#1. Add extensive comments. * src/autofit/afblue.hin (AF_BLUE_PROPERTY_CJK_FILL): Removed, no longer used. (AF_BLUE_PROPERTY_CJK_TOP, AF_BLUE_PROPERTY_CJK_HORIZ): Fix values. This is error dagit#3. * src/autofit/afblue.c, src/autofit/afblue.h: Regenerated. * src/autofit/afcjk.c (af_cjk_metrics_init_blues): Correct error dagit#1. Use character `|' to separate characters for reference and overshoot values. Improve tracing messages, synchronizing them with the latin auto-hinter. (af_cjk_hints_compute_blue_edges): Fix value of `is_top_right_blue'. This is error dagit#2. (af_cjk_align_linked_edge): Add tracing message. * src/autofit/afcjk.h (AF_CJK_IS_FILLED_BLUE): Removed, no longer used.
75a6023
to
b6b3f82
Compare
Is this PR addressing any issues in particular that you'd like to see merged back into master? (If you're just working with a fork it might be good to close it) |
Honestly, I never really looked at it. In part because it's huge, but also because I'm not sure the right way to handle this. My priority has always been that I want the binding to build easily and naturally everywhere. Peaker brings up a good point though that if you're already linking in freetype, that the way we do it sort of gets in the way because you endup with the library twice. At any rate, it seems like a good idea? |
If the idea is to use pkg-config to look for local installations of the C library to avoid the bundled library, we can add that. I think that the original pull request may have evolved, but the original branch lived on. It's fine for forks to exist, but IMO a PR should be a reasonable way to add changes back into the main branch. |
Is it possible to do that and have windows continue to "just work"? I don't want people to be required to setup pkg-config on windows. |
Yea it should be pretty straightforward to place everything behind a cabal flag that defaults to building the included source. It seems like there's a whole lot more in here apart from that though. |
There seems to have been a mix-up with more commit added to the branch used for the PR, I now pushed just the change @Peaker seems to intend to offer. (didn't yet verify it builds because the context I found this is where the package doesn't build for me on at the moment on an arm mac) |
Add the install-includes needed so that one can make bindings for C libraries that depend on freetype. Otherwise, to make these bindings you have to copy the entire freetype2 C headers into your own bindings' package.
In particular, I am making bindings for freetype-gl so I can use the library with OpenGL portably. (FTGL doesn't build on Windows, at least not easily).