"Digital typesetting" can go take a running jump
-
God I hate it. It took me ages to go from this: Render before fix[^] Which was wrong, to this Render after fix[^] Still not perfect. The red rectangle is the result of "measuring" the space the text will occupy. It works great for some fonts, but certain Truetype fonts still aren't quite perfect. It's frustrating the heck out of me. Why does it have to be such a pain? Between ascent, descent, baseline, line height, line advance, and individual glyph offsets and dimensions it's like CSS for text. WTH? X| This code... my god, it's full of corner cases! but it works pretty well at this point. Excerpt just so you understand how nasty it is.
uint16\_t em\_width = 0; uint16\_t x\_ext = 0, y\_ext = 0; uint16\_t x = 0,y=0; uint32\_t cp=0, cp\_next=0; size\_t advlen = len; size\_t advlen\_next = 0; const uint16\_t lineadv = this->line\_advance(); gfx\_result res = encoding.to\_utf32(sz,&cp,&advlen); if(res!=gfx\_result::success) { return res; } sz+=advlen; len-=advlen; if(\*sz) { advlen\_next = len; res = encoding.to\_utf32(sz,&cp\_next,&advlen\_next); if(res!=gfx\_result::success) { return res; } sz+=advlen\_next; len-=advlen\_next; y\_ext = lineadv; } else { out\_area->width = 0; out\_area->height = 0; return gfx\_result::success; } font\_glyph\_info em\_gi; uint16\_t xo, cw; bool cached; int tail; while(1) { font\_glyph\_info gi; switch(cp) { case '\\t': if(em\_width==0) { cached = false; if(cache!=nullptr) { if(gfx\_result::success==cache->find('M',0,&em\_gi)) { cached = true; } } if(!cached) {
-
God I hate it. It took me ages to go from this: Render before fix[^] Which was wrong, to this Render after fix[^] Still not perfect. The red rectangle is the result of "measuring" the space the text will occupy. It works great for some fonts, but certain Truetype fonts still aren't quite perfect. It's frustrating the heck out of me. Why does it have to be such a pain? Between ascent, descent, baseline, line height, line advance, and individual glyph offsets and dimensions it's like CSS for text. WTH? X| This code... my god, it's full of corner cases! but it works pretty well at this point. Excerpt just so you understand how nasty it is.
uint16\_t em\_width = 0; uint16\_t x\_ext = 0, y\_ext = 0; uint16\_t x = 0,y=0; uint32\_t cp=0, cp\_next=0; size\_t advlen = len; size\_t advlen\_next = 0; const uint16\_t lineadv = this->line\_advance(); gfx\_result res = encoding.to\_utf32(sz,&cp,&advlen); if(res!=gfx\_result::success) { return res; } sz+=advlen; len-=advlen; if(\*sz) { advlen\_next = len; res = encoding.to\_utf32(sz,&cp\_next,&advlen\_next); if(res!=gfx\_result::success) { return res; } sz+=advlen\_next; len-=advlen\_next; y\_ext = lineadv; } else { out\_area->width = 0; out\_area->height = 0; return gfx\_result::success; } font\_glyph\_info em\_gi; uint16\_t xo, cw; bool cached; int tail; while(1) { font\_glyph\_info gi; switch(cp) { case '\\t': if(em\_width==0) { cached = false; if(cache!=nullptr) { if(gfx\_result::success==cache->find('M',0,&em\_gi)) { cached = true; } } if(!cached) {
Perhaps Sanskrit would be simpler.
-
Perhaps Sanskrit would be simpler.
It probably would be. I think it's effectively monospaced.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
God I hate it. It took me ages to go from this: Render before fix[^] Which was wrong, to this Render after fix[^] Still not perfect. The red rectangle is the result of "measuring" the space the text will occupy. It works great for some fonts, but certain Truetype fonts still aren't quite perfect. It's frustrating the heck out of me. Why does it have to be such a pain? Between ascent, descent, baseline, line height, line advance, and individual glyph offsets and dimensions it's like CSS for text. WTH? X| This code... my god, it's full of corner cases! but it works pretty well at this point. Excerpt just so you understand how nasty it is.
uint16\_t em\_width = 0; uint16\_t x\_ext = 0, y\_ext = 0; uint16\_t x = 0,y=0; uint32\_t cp=0, cp\_next=0; size\_t advlen = len; size\_t advlen\_next = 0; const uint16\_t lineadv = this->line\_advance(); gfx\_result res = encoding.to\_utf32(sz,&cp,&advlen); if(res!=gfx\_result::success) { return res; } sz+=advlen; len-=advlen; if(\*sz) { advlen\_next = len; res = encoding.to\_utf32(sz,&cp\_next,&advlen\_next); if(res!=gfx\_result::success) { return res; } sz+=advlen\_next; len-=advlen\_next; y\_ext = lineadv; } else { out\_area->width = 0; out\_area->height = 0; return gfx\_result::success; } font\_glyph\_info em\_gi; uint16\_t xo, cw; bool cached; int tail; while(1) { font\_glyph\_info gi; switch(cp) { case '\\t': if(em\_width==0) { cached = false; if(cache!=nullptr) { if(gfx\_result::success==cache->find('M',0,&em\_gi)) { cached = true; } } if(!cached) {
You keep pointing out how you are working on a memory-constrained, embedded system so why in the wide world of sports are you supporting TrueType fonts? JUST SAY NO!
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
You keep pointing out how you are working on a memory-constrained, embedded system so why in the wide world of sports are you supporting TrueType fonts? JUST SAY NO!
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
For many reasons. A) It can be smaller to load a 30KB TTF font like "Telegrama" over at fontsquirrel.com than it would be to render it all out to anti-aliased alpha transparency maps with the requisite kerning tables. Particularly if you need it in several sizes B) I work with design teams that produce content in a particular style and want it replicated as closely as possible. It's fast for me to just embed a proper TTF from somewhere like fontsquirrel - or even one they give me rather than having to try to prune and create a specific VLW fontset C) Although this isn't as true of my professional projects, my hobby projects often target multiple pieces of hardware with different display resolutions. TTF scales. Fixed raster fonts do not. And I *have* had to do this professionally a few times when we hadn't finalized the hardware yet. D) ARM CPUs have pretty decent floating point, and can handle my TTF and SVG rendering with relative ease. The ESP32 struggles a bit, but it's more of a hobbyist chip anyway. Edit: I should add that even then it's very usable in many situations and I employ it several of my hobby projects.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix