search

jtsiomb / libdrawtext

Simple library for fast anti-aliased text rendering in OpenGL
GNU Lesser General Public License v3.0
85 stars 13 forks source link

Selectively skipping glyphs #6

Open nigels-com opened 7 years ago

nigels-com commented 7 years ago

It seems like if I hand-edited the comment header of the .glyphmap file I could selectively delete specific glyphs from the range, such as those not available in that particular font. But I'd also need to go delete the pixels or I'd reduce the utilisation of the texture memory.

Say in this case I just wanted the arrows. I could exact each pair as a range, and then write a script to combine them back into a new .glyphmap file?

Do you feel like this is a job for libdrawtext or something wrapped on top of it?

linux-biolinum_s96_r25a0-25cf

jtsiomb commented 7 years ago

Hmmm, this needs a bit more thought. Currently glyphmaps are represented as contiguous unicode ranges, so there's no provision for skipping specific characters.

I see three ways to go about doing this:

  1. Write an external tool which rearranges the glyphmap, skipping unwanted glyphs and making the image smaller in the process. The removed glyphs would have to be maintained in the metrics comments, but possibly mapped to a zero-area quad in the image.

  2. Modify the internal glyphmap structure in libdrawtext to keep a list of disjoint ranges instead of a single range, and modify the glyphmap generation code to skip over the missing parts of the range list. This is a bit of a duplication of functionality though, because the dtx_font structure is really a list of glyphmaps, which is the same thing but more flexible, because each glyphmap can be different ranges of the same font, but also different sizes too.

  3. Which brings me to the "correct" way to do this I think: allow concatenation of multiple glyphmaps onto a single image file, and introduce the ability to export and import a whole dtx_font from such a multi-glyphmap image. Half-way there and maybe equivalent but simpler to implement would be to introduce a dtx_add_font_glyphmap function to "add" more glyphmaps to an existing dtx_font, by loading multiple of the current single-glyphmap images. That would of course mean keeping a bunch of images on disk for each of the sub-range, which might be inconvenient.

I'll have to think about this, and I'm certainly open to suggestions. I think the first part of point 3 above is the proper way to do this.