>
> This should also include locale/language, as it affects feature selection
> process.
Is that what hb_buffer_set_language is supposed to be for? I'm currently
not calling that at all. I wasn't sure what it did, and setting it didn't
seem to make any difference to the output.
On Windows it
I've continued to investigate this, and it seems to be related to my call
to hb_font_set_scale. The value I was passing was a float multiplier for
the font (you can see it being used in my first email) - I've tried
changing that to use the up-scaled value that we give to FT_Set_Transform,
however
I've just grabbed a version with the new flags API, but I'm finding that I
can't actually use hb_ft_font_get_load_flags and hb_ft_font_get_face in my
custom funcs, as they fail the font->destroy != (hb_destroy_func_t)
_hb_ft_font_destroy test since I'm using a sub-font with a different
destroy
Using the parent font worked fine. I always forget I can do that :)
-Jamie.
On 12 October 2015 at 14:30, Jamie Dale <jamiedale88+harfb...@gmail.com>
wrote:
> I've just grabbed a version with the new flags API, but I'm finding that I
> can't actually use hb_ft_font_ge
fined by C
applications.
In hindsight I should have mentioned this before, however I'd always
assumed HarfBuzz was a C library due to the way its API is designed, but
the templates in the OT font code proves otherwise :)
-Jamie.
On 5 October 2015 at 19:58, Jamie Dale <jamiedale88+harfb...@gmail.com>
Just tested this and it worked fine. Thanks :)
On 3 October 2015 at 13:20, Behdad Esfahbod <behdad.esfah...@gmail.com>
wrote:
> On 15-10-02 10:00 PM, Jamie Dale wrote:
> > That's similar to what I originally had, so I'm fine with something like
> that.
> > My only
Hmm, that's possible...
All the values we give to our font renderer from FreeType and HarfBuzz are
pre-converted into pixel space. For our old font rendering code, this meant
that the glyph metrics and kerning would have been converted into pixel
space separately before being summed together to
It was the truncation, good call :)
I've changed it to round when converting from 26.6 to pixel space, and
that's fixed the remaining issues I was seeing.
Thanks,
Jamie.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
Hey all,
We allow rich-text as part of our text layout system, and I've noticed that
I sometimes get different output when shaping sub-sections of text (for the
different rich-text styles) when compared to shaping the full text.
The screenshot below is text shaped by a single call to hb_shape:
m_features, 0);
>
>
>
> Regards,
> Konstantin
>
> 2015-10-05 23:32 GMT+04:00 Jamie Dale <jamiedale88+harfb...@gmail.com>:
>
>> Hey all,
>>
>> In our application we have two text shaping backends; a simple "kerning
>> only" implementati
remainder of the advance comes from the advance.x value on the FT_GlyphSlot
for the glyph, such that:
TotalAdvance = Kerning + GlyphSlotAdvanceX;
-Jamie.
On 5 October 2015 at 20:49, Nikolay Sivov <bungleh...@gmail.com> wrote:
> On 05.10.2015 22:32, Jamie Dale wrote:
>
>>
&
Hey all,
In our application we have two text shaping backends; a simple "kerning
only" implementation using our existing font rendering code (fast, but
can't handle complex languages), and a HarfBuzz based implementation for
when we need to support complex languages (although ideally the
HarfBuzz
Hey,
I'm not sure if this is correct place to post/discuss feature requests...
hopefully it is.
Our project makes use of a custom memory allocator, and we like to ensure
that our third-party libraries are using this where possible, as our
allocator can offer significantly better performance, and
free
> > #endif
> >
> > You'd then replace calls to malloc, calloc, realloc, and free from within
> > HarfBuzz to use hb_malloc, hb_calloc, hb_realloc, and hb_free.
> >
> > This is basically the code I already have, except I
> > redefined malloc, calloc, realloc, and
malloc, calloc
, realloc, and free rather than create the hb_* variants, as I didn't want
to change too much HarfBuzz code.
Thoughts?
On 31 August 2015 at 22:17, Jamie Dale <jamiedale88+harfb...@gmail.com>
wrote:
> Hey,
>
> I'm not sure if this is correct place to post/discuss f
nd use that in all places? I'll go ahead and do that, since
> it's
> been long overdue.
>
> Re caching, do you have data you can share on which parts are the slowest,
> etc? Would you be willing to test a couple of patches if I add caches to
> hb-ft?
>
> Thanks,
> behd
,0+1023|s=2+1071|t=3+690]
>
> but this one is kerned *less*.
>
> I have no idea why you get such different results.
>
> Attaching the font without GPOS table for you to test.
>
> b
>
> On 15-10-05 04:54 PM, Nikolay Sivov wrote:
> > On 05.10.2015 23:17, Jamie
.
-Jamie.
On 28 August 2015 at 12:38, Jamie Dale jamiedale88+harfb...@gmail.com wrote:
Hey all,
I'm currently working on integrating HarfBuzz into an existing
FreeType based text rendering system, however I notice that the
default FreeType wrapper doesn't allow you to control the load flags
used
Thanks, I also have another question related to what I mentioned yesterday:
Is there a reliable way to detect which glyphs are ligatures?
My current solution checks for gaps in the cluster indices of the shaped
glyph infos, but that also requires some special case handling to detect if
the last
I actually just wrote something to give me very similar information since I
realised that my basic "this is a ligature" flag wasn't enough data, so
each of my glyphs now contains the number of characters that the glyph was
composed from. This, along with the cluster index of the glyph from the
I'm also curious to know the answer to this. I'm currently using
HB_BUFFER_CLUSTER_LEVEL_MONOTONE_CHARACTERS as I read somewhere that it
produces finer grained cluster data.
I'm currently adding the remaining bits of editable text support that I'd
skipped over before, and part of this is dealing
Yeah, I actually found that out myself as I'd added an assert that the
number of characters was never zero... and then I pasted in some Arabic and
it fired due to what you mentioned (multiple glyphs in a sequence with the
same cluster index).
I'm not too concerned by this though, as it's my
Hey all,
I've spent today fixing some issues in our editable text controls, mostly
relating to issues caused by the difference between characters and grapheme
clusters.
I've sorted most of my issues now, but I'm still having an issue the لا
ligature in Arabic.
My current code that performs
I don't have an answer to my original question, but I "solved" this by
changing our text layout to use an underlay for the text highlight rather
than a renderer, thus avoiding the need to split ligatures in the most
general of cases.
-Jamie.
___
Hey all,
I'm running HarfBuzz 1.2.4 with a modified hb_font implementation based on
the FreeType implementation in the vanilla version.
One of the differences is that I pass through the FreeType scale as
user-data and apply it when getting the metrics from FreeType (via
FT_Set_Transform).
We've
->x_scale = FT_MulFix(HarfBuzzFTFont->x_scale,
FixedFontScale);
HarfBuzzFTFont->y_scale = FT_MulFix(HarfBuzzFTFont->y_scale,
FixedFontScale);
-Jamie.
On 8 May 2017 at 21:31, Jamie Dale <jamiedale88+harfb...@gmail.com> wrote:
> The scale applied to the hb_font seems to affect how badl
2017 at 21:15, Jamie Dale <jamiedale88+harfb...@gmail.com> wrote:
> Something is definitely causing it to change when the font is scaled
> though:
>
> Scale | x_offset
> ~0.666 | 2141
> ~0.832 | 340
> ~1.000 | -1461
> ~1.165 | -3262
> ~1.332 | -5063
>
> -J
27 matches
Mail list logo
