<div dir="ltr"><div>Now makes sense. Thanks Khaled.</div><div><br></div><div>So maybe we should handle or accept some callback for that or doing that at least when GDEF/lcar info is available for the glyph? I mean, anything to improve here?<br></div><div><br></div><div>I guess playing with such details of hb_buffer with considering the original text, just like Kashida justification, will be harder to get for clients (the reason ligature carets API is not used AFAICS, in addition to not being that popular on the fonts itself) so providing some lightweight and unofficial wrapper at least, lcar with dividing fallback, can make sense I guess.</div><div><br></div><div>Thanks<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 15, 2018 at 2:30 AM Khaled Hosny <<a href="mailto:dr.khaled.hosny@gmail.com">dr.khaled.hosny@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Dec 14, 2018 at 07:00:43PM +0330, Ebrahim Byagowi wrote:<br>
> Hey there, just occurred to me this [hopefully not deeply incorrect] why<br>
> harfbuzz itself doesn't handle ligature carets, distributing the ligature<br>
> cluster advance with ignorable clusters followed by using GDEF/lcar info,<br>
> with falling back to equal dividing?<br>
<br>
The current API does not allow for such fallback as it takes in glyph<br>
index only, but you need text string of the ligature. You will also need<br>
to do grapheme clusters segmentation which (IIRC) HarfBuzz does not<br>
currently fully handle.<br>
<br>
Regards,<br>
Khaled<br>
</blockquote></div>