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

Use a real text layout engine #11

Open
azsn opened this issue Oct 3, 2020 · 8 comments
Open

Use a real text layout engine #11

azsn opened this issue Oct 3, 2020 · 8 comments

Comments

@azsn
Copy link
Owner

azsn commented Oct 3, 2020

Pango seems like it could work. It might be able to replace the FreeType dependency for font loading too, I'm not sure. HarfBuzz is probably not sufficient on its own because it just does shaping -- no line breaks, bidirectional text, justification, etc.

I'm thinking this should look like a class or some functions which take in some text with formatting (e.g. Pango markup) and returns an array of rectangles specifying the location where each glyph should be placed. (The rectangles could then be converted to triangle verts and sent off to the graphics card.)

@azsn
Copy link
Owner Author

azsn commented Oct 4, 2020

@discapes If you're still looking for something to do on this project, perhaps it could be interesting to look into this issue. No obligation, of course! Just if you're interested :)

I used Pango once a while back but I've forgotten most of how it works. It does require glib though, which is bloaty. That might be a problem...

@discapes
Copy link
Contributor

discapes commented Oct 4, 2020

Based on 'What Harfbuzz doesn't do' , maybe ICU would be a good option. I don't think making a markup parser would be hard..

@khaledhosny
Copy link

ICU is still lower level and requires quite a bit of plumbing and still won't handle things like matching fonts and font fallback. Pango is still a better option if one is looking for something that just works.

@azsn
Copy link
Owner Author

azsn commented Oct 4, 2020

Thanks @khaledhosny , good to know. I haven't used ICU so I can't confirm, but as someone who once tried to write a widget toolkit I can confirm that text rendering and handling is a nightmare, so I'd prefer to err on the side of something that "just works" haha.

@discapes
Copy link
Contributor

discapes commented Oct 4, 2020

So unless anyone has any alternatives, we would accept Pango and just deal with GLib?

@azsn
Copy link
Owner Author

azsn commented Oct 4, 2020

Yeah, I think that's fine. If we separate components effectively then it should be possible to swap out which layout backend is used in the future. For example, Core Text on Mac or DirectWrite on Windows.

@azsn
Copy link
Owner Author

azsn commented Oct 24, 2020

@discapes Hey, did you start working on this at all? No problem if not, I just want to make sure I don't duplicate work. If you haven't, I'm going to start looking into pulling out the basic layout code from gllabel.cpp into its own section/file (e.g. text_to_verts()-kinda thing) probably with a built in "basic layout" (what I already have, proof-of-concept style) and an optional Pango layout (e.g. perhaps with #define GLLABEL_USE_PANGO)

@discapes
Copy link
Contributor

Nah, I haven't. I'll go check out the progress later if I'm not busy..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants