Pixi.js: Create an SDF font handler

There are other things with fonts. For example, use R-G-B channels as different spritesheets to cover all asian symbols.

Hi @englercj , @ivanpopelyshev ,

I am currently busy with this since nothing changed since my last year request https://github.com/pixijs/pixi.js/issues/1679 .

So the plan is to create Mesh and pass point coordinates as usual point attributes + texture coordinates as uvs. Render this once on shader than cache.

Any suggestions on implementation?

Ivan, not sure I understood you correctly as for RGB. Is it intended to be a kind of compression to keep 3 times more data?

@englercj @ivanpopelyshev let me know your thoughts on this

https://github.com/PixelsCommander/pixi-sdf-text

Current priority is multiline rendering and max compatibility with regular Text.

PS @ivanpopelyshev figured out what you mean for RGB. Scheduled for next updates.

RGB - yes.

What's your email? I'll invite you in slack. Neve mind, found it.

Mark by @finscn

@englercj @ivanpopelyshev @PixelsCommander What is the current progress on this feature? If no one is on this recently, I'm willing to take the job.
I'm the author of msdf-bmfont-xml which works with the help of opentype.js and node-canvas. It runs well on Starling-Frameworks.
When I get my feet wet on Pixi.js recently, I found that msdf text is just not implemented so I just took some time extended the great plugin pixi-sdf-text to enable multi-channel SDF with no extra dependencies and some hack into BitmapText and Loader, below is my current progress:

stroke & dropshadow effect is implemented with no extra drawcall.
Also some fix in BitmapText layout algorithm (Current implements in 4.7 is a bit buggy, and bmfont baseline parameter is important but not used in BitmapText layout).

I've read the talks about v5 changed in architecture and shaders, so I'm not sure it's a good time trying to create a PR or just leave it in a standalone plug-ins.
Tell me what you think guys.

@soimy This is a great time to put in a PR to v5 (next branch). Thanks for volunteering.

Need some discussion on TTF/OTF parse module.
I'm thinking of the necessity of run-time true-type font parser in pixi core. This will add at least 60k+ load of parser code but the benefit of ttf resources are not seems to be equal. This feature should be treated as a devDependencies.

Tell me what u think.
BTW: Can anyone invite me to pixi's slack? slack id: [email protected]

If you need help with this, you can ping me.

I actually just wrote exactly this code for a web vector drawing tool I'm making. Unfortunately, I wrote everything in GWT, and I don't currently have the cycles to rewrite everything in pure JavaScript for Pixi (perhaps, when Google releases their J2CL Java to JS compiler next year, I can just recompile it for JS).

In my case, the architecture I used was to use Typr.js to parse truetype files at runtime. Then, as each character is displayed, I use a custom ttf renderer (a simple one is actually not much code) to create an SDF on the fly for just the character, and stick it into a cache. And then the SDFs are rendered onto the screen. It's all reasonably fast and code sizes aren't too bad, so I'm not sure if there's any need to precompute the SDF beforehand.

The main drawback is with font sizes. To do things properly, you need to parse the ttf font files yourself, but then you have to bundle a ttf font file into your game. TTF files are only 50KB or so for English-only fonts, but they can be several hundred KB for European fonts, and several MB for non-European fonts. So I'm not sure how practical this approach is for web/mobile games.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.