commit 9b657a99a613ff192509fb82020a9ab8e354aa62
parent bb37974073b00337f90fe044b91240ef893ff374
Author: lumidify <nobody@lumidify.org>
Date: Thu, 19 Mar 2020 11:49:58 +0100
Hey, the spaces are back!
Diffstat:
| M | text-hb.c | | | 32 | +++++++++++++++++++++++++++----- |
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/text-hb.c b/text-hb.c
@@ -355,8 +355,20 @@ ltk_create_text_line(LtkTextManager *tm, char *text, uint16_t fontid, uint16_t s
for (int p = 0; p < ulen; p++) {
gid = stbtt_FindGlyphIndex(&font->info, vis_str[p]);
cur_script = hb_unicode_script(ufuncs, vis_str[p]);
- //if (!gid || (last_script != cur_script && cur_script != HB_SCRIPT_INHERITED && cur_script != HB_SCRIPT_COMMON)) {
- if (!gid || (last_script != cur_script && cur_script != HB_SCRIPT_INHERITED && cur_script)) {
+ /*
+ Okay, so get this: If I don't ignore HB_SCRIPT_COMMON (as in the lower line), "I'm a button" is split into
+ individual characters (I guess because apostrophe and space are common characters). However, it all seems
+ to display at least decently. If I do ignore HB_SCRIPT_COMMON, it should technically work better since the
+ normal text is kept in one piece. But alas, it is not so! Because spaces don't cause the text to be split
+ anymore, the "blablabla " in the mixed script text is kept together (with the space at the end), which
+ *for some bizarre reason* causes HarfBuzz to display it RTL as "albalbalb". WHAT IS HAPPENING HERE?
+
+ Update: Yeah, I was just being stupid - I was passing cur_script instead of last_script to
+ ltk_create_text_segment, so that was messing it up...
+ I have to leave that comment there for at least one commit, though.
+ */
+ if (!gid || (last_script != cur_script && cur_script != HB_SCRIPT_INHERITED && cur_script != HB_SCRIPT_COMMON)) {
+ //if (!gid || (last_script != cur_script && cur_script != HB_SCRIPT_INHERITED && cur_script)) {
/* This is extremely efficient... */
FcPattern *pat = FcPatternDuplicate(tm->fcpattern);
FcPattern *match;
@@ -377,7 +389,7 @@ ltk_create_text_line(LtkTextManager *tm, char *text, uint16_t fontid, uint16_t s
FcPatternDestroy(match);
FcPatternDestroy(pat);
- new_ts = ltk_create_text_segment(tm, vis_str + start_pos, p - start_pos, last_font_id, size, cur_script);
+ new_ts = ltk_create_text_segment(tm, vis_str + start_pos, p - start_pos, last_font_id, size, last_script);
// FIXME: error
if (!new_ts) continue;
new_ts->next = NULL;
@@ -389,7 +401,7 @@ ltk_create_text_line(LtkTextManager *tm, char *text, uint16_t fontid, uint16_t s
last_script = cur_script;
}
}
- new_ts = ltk_create_text_segment(tm, vis_str + start_pos, ulen - start_pos, cur_font_id, size, cur_script);
+ new_ts = ltk_create_text_segment(tm, vis_str + start_pos, ulen - start_pos, cur_font_id, size, last_script);
// FIXME: error if new_ts null
new_ts->next = NULL;
if (!tl->start_segment) tl->start_segment = new_ts;
@@ -530,8 +542,18 @@ ltk_create_text_segment(LtkTextManager *tm, uint32_t *text, unsigned int len, ui
/* Calculate position in order to determine full size of text segment */
x1_abs = x_abs + glyph->info->xoff + glyph->x_offset;
y1_abs = y_abs + glyph->info->yoff - glyph->y_offset;
- x2_abs = x1_abs + glyph->info->w;
+ /* Okay, wait, so should I check if the script is horizontal, and then add
+ x_advance instead of glyph->info->w? It seems that the glyph width is
+ usually smaller than x_advance, and spaces etc. are completely lost
+ because their glyph width is 0. I have to distinguish between horizontal
+ and vertical scripts, though because to calculate the maximum y position
+ for horizontal scripts, I still need to use the glyph height since
+ y_advance doesn't really do much there. I dunno, at least *something*
+ works now... */
+ //x2_abs = x1_abs + glyph->info->w;
y2_abs = y1_abs + glyph->info->h;
+ x2_abs = x1_abs + glyph->x_advance;
+ //y2_abs = y1_abs - glyph->y_advance;
glyph->x_abs = x1_abs;
glyph->y_abs = y1_abs;
if (x1_abs < x_min) x_min = x1_abs;
