commit 42f4ff374b3ba05c9e35e1682f49b3601b7a21ee
parent 9b657a99a613ff192509fb82020a9ab8e354aa62
Author: lumidify <nobody@lumidify.org>
Date: Sat, 28 Mar 2020 19:50:09 +0100
*Possibly* make one little part work with vertical scripts
Diffstat:
M | text-hb.c | | | 41 | +++++++++++++---------------------------- |
1 file changed, 13 insertions(+), 28 deletions(-)
diff --git a/text-hb.c b/text-hb.c
@@ -314,7 +314,6 @@ ltk_get_font(LtkTextManager *tm, char *path)
/* FIXME: allow to either use fribidi for basic shaping and don't use harfbuzz then,
or just use harfbuzz (then fribidi doesn't need to do any shaping) */
-/* FIXME: take baseline into account; save script in LtkTextSegment */
LtkTextLine *
ltk_create_text_line(LtkTextManager *tm, char *text, uint16_t fontid, uint16_t size)
{
@@ -355,20 +354,8 @@ 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]);
- /*
- 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.
- */
+ // FIXME: handle inherited and common scripts at beginning of string
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;
@@ -420,6 +407,10 @@ ltk_create_text_line(LtkTextManager *tm, char *text, uint16_t fontid, uint16_t s
tl->y_min = tl->x_min = INT_MAX;
tl->w = tl->h = 0;
while (ts) {
+ if (HB_DIRECTION_IS_HORIZONTAL(ts->dir) != is_hor) {
+ fprintf(stderr, "WARNING: mixed horizontal/vertical text is not supported; ignoring\n");
+ continue;
+ }
if (is_hor) {
if (tl->y_max < ts->y_max) {
tl->y_max = ts->y_max;
@@ -506,10 +497,7 @@ ltk_create_text_segment(LtkTextManager *tm, uint32_t *text, unsigned int len, ui
hb_direction_t dir = hb_script_get_horizontal_direction(script);
hb_buffer_set_direction(buf, dir);
hb_buffer_set_script(buf, script);
- //hb_buffer_set_direction(buf, HB_DIRECTION_LTR);
- //hb_buffer_set_flags(buf, HB_BUFFER_FLAG_BOT | HB_BUFFER_FLAG_EOT);
hb_buffer_add_codepoints(buf, ts->str, len, 0, len);
- //hb_buffer_guess_segment_properties(buf);
hb_shape(font->hb, buf, NULL, 0);
ts->dir = hb_buffer_get_direction(buf);
ginf = hb_buffer_get_glyph_infos(buf, &text_len);
@@ -550,10 +538,14 @@ ltk_create_text_segment(LtkTextManager *tm, uint32_t *text, unsigned int len, ui
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;
+ /* FIXME: THIS PROBABLY DOESN'T REALLY WORK */
+ if (HB_DIRECTION_IS_HORIZONTAL(dir)) {
+ x2_abs = x1_abs + glyph->x_advance;
+ y2_abs = y1_abs + glyph->info->h;
+ } else {
+ x2_abs = x1_abs + glyph->info->w;
+ 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;
@@ -563,15 +555,8 @@ ltk_create_text_segment(LtkTextManager *tm, uint32_t *text, unsigned int len, ui
x_abs += glyph->x_advance;
y_abs -= glyph->y_advance;
}
- /* FIXME: what was this supposed to do?
- I think it was supposed to be the start drawing position, but why would this not be 0?
- I'm guessing it had something to do with the fact that I need to calculate where the
- actual top left corner of the glyph is since harfbuzz gives me the origin - maybe I
- should just store that position directly in LtkGlyph? Is there any need to advance, etc.
- later on after I've positioned the glyphs? Well, I guess I'll figure that out eventually... */
ts->start_x = -x_min;
ts->start_y = -y_min;
- // FIXME: need to somehow save advance so spaces aren't lost
ts->w = x_max - x_min;
ts->h = y_max - y_min;
ts->x_min = x_min;