Re: [HarfBuzz] Getting character bitmap
Hi Sagar,
I suggest you follow an example piece of code, like:
https://github.com/lxnt/ex-sdl-freetype-harfbuzz
behdad
http://behdad.org/
On Sun, Jan 15, 2023 at 11:47 AM Sagar Acharya
wrote:
> Thanks a lot for the quick help.
>
> I decided to go ahead with Freetype for C.
>
> Since I'm new to C, I don't quite know how to connect function Char_Index
> output to FT_Bitmap. I'm new to reading such C documentation.
>
> //===#include
>
> #include FT_FREETYPE_H
>
> void main()
> {
> FT_Library library;
> FT_Face face;
> FT_Error error;
> FT_UInt glyph_index;
> FT_Bitmap bmp;
>
> int width=200;
> int height=200;
>
> error = FT_Init_FreeType();
> error = FT_New_Face(library, "/path/to/ttf", 0, );
> error = FT_Set_Char_Size(face, 0, 16*64, 200, 200);
>
> glyph_index = FT_Get_Char_Index(face, 0x41);
>
> error = FT_Render_Glyph(face->glyph, FT_RENDER_MODE_MONO);
> printf("%d\n", error);
> }
> //===
> Thanking you
> Sagar Acharya
>
>
>
> Jan 13, 2023, 19:06 by beh...@behdad.org:
>
> > Hi Sagar,
> >
> > HarfBuzz does not have a rasterizer so you can't get that from HarfBuzz.
> You have two options:
> >
> > 1. Use FreeType library,
> >
> > 2. If you have a graphics library with a rasterizer capable of
> handling the moveTo/lineTo/curveTo model, you can use the hb-draw API to
> draw to it.
> >
> > Hope that helps,
> >
> > behdad
> > http://behdad.org/
> >
> >
> > On Fri, Jan 13, 2023 at 10:06 AM Sagar Acharya <>
> sagaracha...@tutanota.com> > wrote:
> >
> >> I have ttf file of the font that I want the bitmap of. In black and
> white mapped to 0 and 1, I want a set of 16x16 set of all characters.
> >>
> >> How do I do it?
> >>
> >> 111000
> >> 10
> >> 111000
> >> 111010
> >> 111000
> >>
> >> Something like above. How do I get it from ttf?
> >> Thanking you
> >> Sagar Acharya
> >>
>
>
Re: [HarfBuzz] Getting character bitmap
Hi Sagar, HarfBuzz does not have a rasterizer so you can't get that from HarfBuzz. You have two options: 1. Use FreeType library, 2. If you have a graphics library with a rasterizer capable of handling the moveTo/lineTo/curveTo model, you can use the hb-draw API to draw to it. Hope that helps, behdad http://behdad.org/ On Fri, Jan 13, 2023 at 10:06 AM Sagar Acharya wrote: > I have ttf file of the font that I want the bitmap of. In black and white > mapped to 0 and 1, I want a set of 16x16 set of all characters. > > How do I do it? > > 111000 > 10 > 111000 > 111010 > 111000 > > Something like above. How do I get it from ttf? > Thanking you > Sagar Acharya >
Re: [HarfBuzz] kaithi & arabic : glyphs that span number
NotoSansArabic has no special rules to make the U+0600 character work properly. behdad http://behdad.org/ On Fri, Dec 2, 2022 at 1:10 PM Behdad Esfahbod wrote: > Hi Madhu, > > I checked the Kaithi font. It has no rules for U+110BC character. But if > you use U+110BD you get the desired result. > > I have not checked the Arabic font. > > behdad > http://behdad.org/ > > > On Wed, Nov 30, 2022 at 2:15 AM Madhu wrote: > >> In April 2002, Sameer Singh posted a message on emacs-devel where he >> demonstrated the use of harfbuzz numerals with the kaithi script >> >> https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg01297.html >> to yield this image: >> >> [1] >> https://lists.gnu.org/archive/html/emacs-devel/2022-04/png4ClBZc1zV4.png >> >> There the first glyph spans the remaining chacracters when composed. >> >> I tried to reproduce it and showed my work on this message >> >> https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00341.html >> >> but I only get >> >> [2] >> https://lists.gnu.org/archive/html/emacs-devel/2022-05/pngTFsflcCrfU.png >> The first character does not span the remaining digit characters. >> >> Can anyone tell me what I might be missing? >> >> 1. 2.txt has code points 0x110BC 0x0967 0x0966 0x096E >> 2. hb-view --font-file=$HOME/.fonts/NotoSansKaithi-Regular.ttf >> --text-file=2.txt > 2.png >> >> This produces the image in the above mentioned url [2] . I believe it >> should look like [1]. >> >> Similar tests for arabic numbers >> a text file arabic-num.txt with code points 0x0600 0x31 0x32 0x33 >> and a command >> hb-view --font-file=$HOME/.fonts/NotoSansArabic-Regular.ttf >> --text-file=arabic-num.txt --output-file=arabic-num.png >> >> produces a file where the first character does not span the remaining >> characters. >> >> I believe I used the same font-files as Sameer did: >> >> -rw-r--r-- 1 madhu users 260740 Mar 24 2020 NotoSansArabic-Regular.ttf >> -rw-r--r-- 1 madhu users 87260 Mar 24 2020 NotoSansKaithi-Regular.ttf >> >> ---Madhu >> >
Re: [HarfBuzz] kaithi & arabic : glyphs that span number
Hi Madhu, I checked the Kaithi font. It has no rules for U+110BC character. But if you use U+110BD you get the desired result. I have not checked the Arabic font. behdad http://behdad.org/ On Wed, Nov 30, 2022 at 2:15 AM Madhu wrote: > In April 2002, Sameer Singh posted a message on emacs-devel where he > demonstrated the use of harfbuzz numerals with the kaithi script > > https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg01297.html > to yield this image: > > [1] > https://lists.gnu.org/archive/html/emacs-devel/2022-04/png4ClBZc1zV4.png > > There the first glyph spans the remaining chacracters when composed. > > I tried to reproduce it and showed my work on this message > > https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00341.html > > but I only get > > [2] > https://lists.gnu.org/archive/html/emacs-devel/2022-05/pngTFsflcCrfU.png > The first character does not span the remaining digit characters. > > Can anyone tell me what I might be missing? > > 1. 2.txt has code points 0x110BC 0x0967 0x0966 0x096E > 2. hb-view --font-file=$HOME/.fonts/NotoSansKaithi-Regular.ttf > --text-file=2.txt > 2.png > > This produces the image in the above mentioned url [2] . I believe it > should look like [1]. > > Similar tests for arabic numbers > a text file arabic-num.txt with code points 0x0600 0x31 0x32 0x33 > and a command > hb-view --font-file=$HOME/.fonts/NotoSansArabic-Regular.ttf > --text-file=arabic-num.txt --output-file=arabic-num.png > > produces a file where the first character does not span the remaining > characters. > > I believe I used the same font-files as Sameer did: > > -rw-r--r-- 1 madhu users 260740 Mar 24 2020 NotoSansArabic-Regular.ttf > -rw-r--r-- 1 madhu users 87260 Mar 24 2020 NotoSansKaithi-Regular.ttf > > ---Madhu >
Re: [HarfBuzz] GCC 12 warning of use after free in hbfont.cc
Hi phil,
The analysis is correct. The only part you / gcc are missing is
that hb_font_funcs_set_glyph_func() starts with:
if (hb_object_is_immutable (ffuncs))
{
if (destroy)
destroy (user_data);
return;
}
So we know ffuncs is not immutable.
At any rate, I moved the code around, so the compiler should not be
confused anymore:
https://github.com/harfbuzz/harfbuzz/commit/b58bfd9818243fc1178ecad0731fa24a5aa3f235
Hope that helps,
behdad
http://behdad.org/
On Wed, May 11, 2022 at 8:32 PM Philip Race wrote:
> Someone tried building OpenJDK (which includes harfbuzz) using gcc 12
> and got this warning
>
> In function 'void trampoline_reference(hb_trampoline_closure_t*)',
> inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*,
> hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at
>
> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24:
> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2286:12:
>
> error: pointer 'trampoline' used after 'void free(void*)'
> [-Werror=use-after-free]
> 2286 | closure->ref_count++;
>| ~^
> inlined from 'void trampoline_destroy(void*)' at
>
> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2290:1,
> inlined from 'void
> hb_font_funcs_set_nominal_glyph_func(hb_font_funcs_t*,
> hb_font_get_nominal_glyph_func_t, void*, hb_destroy_func_t)' at
>
> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:733:1,
> inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*,
> hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at
>
> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2363:40:
> /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2299:8:
>
> note: call to 'void free(void*)' here
> 2299 | free (closure);
>
> The line numbers don't match current git sources since OpenJDK has an
> older version but I think upstream is the same in this regard.
>
> It is referring to this code
> --
> hb_font_funcs_set_nominal_glyph_func (ffuncs,
> hb_font_get_nominal_glyph_trampoline,
> trampoline,
> trampoline_destroy);
>
>trampoline_reference (>closure);
>
> I *think* the potential problem is this
> void \
> hb_font_funcs_set_##name##_func (hb_font_funcs_t *ffuncs,\
> hb_font_get_##name##_func_t func, \
> void *user_data, \
> hb_destroy_func_t destroy) \
> { \
>if (hb_object_is_immutable (ffuncs)) \
> { \
> if (destroy) \
>destroy (user_data); \
> return; \
>}
>
> The macro expansion of that is hb_font_funcs_set_nominal_glyph_func
> which is called from
> hb_font_funcs_set_glyph_func and on return if that
> hb_object_is_immutable code path was taken
> then the trampoline reference will have been freed already since we have
>
> static void
> trampoline_destroy (void *user_data)
> {
>hb_trampoline_closure_t *closure = (hb_trampoline_closure_t *)
> user_data;
>
>if (--closure->ref_count)
> return;
>
>if (closure->destroy)
> closure->destroy (closure->user_data);
>free (closure);
> }
>
> I suppose if it is never immutable no problem, but I don't know how you
> prove that.
> And it isn't clear what fix would be wanted.
>
>
> -phil
>
Re: [HarfBuzz] Bounding box info
On Fri, Dec 17, 2021 at 12:49 PM Johan Vromans wrote: > Hi, > > After shaping the buffer contains the output glyphs and their positions. > > Maybe I'm overlooking something trivial, but does HarfBuzz provide a means > to get the bounding box for the buffer? > Not directly. But the bounding box of each glyph can be fetched using hb_font_get_glyph_extents(). behdad > -- Johan >
Re: [HarfBuzz] Subset
Hi, On Sat, Jun 26, 2021 at 1:56 PM Patrick wrote: > Hello all, > > I am a user of the great harfbuzz library and try to explore it a bit > more. After downloading the current version of the repository and > building the library on macOS, I have the following questions. I am > not a systems programmer, so these might be "stupid questions" > > 1) I see that the subsetting features are in a separate library, > 1 a) Is that correct? > Correct. > 1 b) Is there any plan to merge these in one library? (Not a feature > request, just a question. The background is that homebrew on macOS > seems to distribute only the non-subset library) > No. They are expected to remain in a separate library. > 2) When I compile a program, do I have to link to both libraries? Yes. 3) The manual at https://harfbuzz.github.io does not seem to list the > subset functions (hb_subset,...). Is that an oversight on my side or > are these functions not listed there on purpose? > That's because the subset functionality has been in development so far. We are just now working on finalizing the API and call it stable, at which point the docs should also appear there. You can track that work here: https://github.com/harfbuzz/harfbuzz/pull/3021 We have also largely migrated to github issues and Discussions instead of this list. You'll get faster response there. Cheers, b ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Is it possible to use HarfBuzz instead of GLib for Unicode functions?
Hi Mehdi, On Sun, Oct 25, 2020 at 7:24 AM Mehdi Sadeghi wrote: > Dear all, > > I am currently using the following GLib functions in order to recognize > certain charachteristics of the input text, such as script type (Arabic > or Latin) and category: > > - g_unichar_get_script > We have this one: hb_unicode_script(). Combine that with hb_unicode_funcs_get_default(). > - g_unichar_isalnum > - g_unichar_isalpha > - g_unichar_isdigit > We don't have these. > I see HarfBuzz used to come with UCDN and now has its own > implementation. I wonder whether I can replace above GLib functions > using that or in general using HarfBuzz. > > I would appreciate if someone gives me some hints, references or > perhaps examples on this. > > Please excuse my naivety in advance if this is some crystal clear topic > and I have missed some obvious points, docs, etc. > > Thank you, > Mehdi > > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz > ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] hb_script_from_iso15924_tag
On Thu, Oct 15, 2020 at 9:44 PM Werner LEMBERG wrote: > > >> Shouldn't hb_script_from_iso15924_tag map "Hans" and "Hant" to > >> HB_SCRIPT_HAN? > > > > hb_script_from_iso15924_tag() doesn't do any mapping whatsoever. > > > > Why is that desirable? > > > > [I find it really weird using mailing lists, as opposed to github > > issues, these days.] > > Really? For simple questions you want to use github issues also? For > me, this looks like abuse... It's just so much easier for posterity to have a URL that clearly shows the discussion around one topic in a simple chronological order. Mailing list archive browsers have miserably failed with that. > I think that a mailing list (or a forum) > is better suited to that, since normally there is a larger audience > who could help and answer. At least HB core developers are all very active on github. Plus, a simple @mention gets people's attention. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] hb_script_from_iso15924_tag
On Fri, Oct 16, 2020 at 7:23 AM Eric Muller wrote: > On 10/15/20 6:02 PM, Behdad Esfahbod wrote: > > On Thu, Oct 15, 2020 at 6:01 PM Eric Muller wrote: > >> Shouldn't hb_script_from_iso15924_tag map "Hans" and "Hant" to >> HB_SCRIPT_HAN? >> > > hb_script_from_iso15924_tag() doesn't do any mapping whatsoever. > > Why is that desirable? > > > We start from a BCP47 tag, completed with likely subtags, and want to get > baselines. I was hoping to use HB's knowledge of mapping from BCP47 scripts > to OT script tags. > This is David Crobett's area. We don't have satisfactory BCP47 API. The closest I see is: hb_ot_tags_from_script_and_language() I don't know if that does what you need. I would guess you call that and then hb_ot_layout_get_baseline() over the various combinations of script/language tags from there. For GSUB/GPOS we have hb_ot_layout_table_select_script() which does some of the repetitive work. I can imagine the same method can be extended to also work for BASE table. Are you using HB BASE-table API? Because that would be a first AFAIK and I'm interested in making it work for you. Thanks, behdad ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] hb_script_from_iso15924_tag
On Thu, Oct 15, 2020 at 6:01 PM Eric Muller wrote: > Shouldn't hb_script_from_iso15924_tag map "Hans" and "Hant" to > HB_SCRIPT_HAN? > hb_script_from_iso15924_tag() doesn't do any mapping whatsoever. Why is that desirable? [I find it really weird using mailing lists, as opposed to github issues, these days.] b > Thanks, > Eric. > > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz > ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] HarfBuzz OT+AAT "Unishaper" slides
Hi, I did some sketching of our main shaper using Prezi: https://prezi.com/view/THNPJGFVDUCWoM20syev/ Cheers, behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Reading a GSUB subtable
Hi Owen, I had to look up SMuFL. I see it's been around since 2013. I never heard about it and don't think anyone I know has either. I browsed the specification and found it bizarre when it comes to its relationship with OpenType. But that's out of scope of your project. Given that SMuFL hardcodes what the alternates are anyway, I suggest you just use a hardcoded list and don't look into GSUB. If you still want to, we don't have that API in HarfBuzz yet, but we can converge to adding it quickly I think. Here's the issue to follow: https://github.com/harfbuzz/harfbuzz/issues/673 Cheers, behdad On Mon, Jun 15, 2020 at 2:52 PM Owen Lamb wrote: > Hello, > > I tried sending this once, but it apparently went to moderator approval > because I wasn't a member of the list. It's been a few days without > response, so I decided to sign up for the list and try again. Hopefully > it'll make it through this time! My original message is as follows: > > I'm working on a GSoC project for the LilyPond music engraving program, > changing the music notation font standard to SMuFL, which ideally supports > OpenType features, i.e. ligatures and stylistic alternates. For the most > part, we've been using the FreeType library, but since FT doesn't support > OT features, I've begun to look elsewhere. HarfBuzz seems like a good > choice, as we already use Pango elsewhere in the program, so we already > have a dependency on it. > > However, I'm having trouble navigating the documentation, in particular > how to read the GSUB table's entire 'salt' lookup subtable at once (and > others, as needed), as an easy-to-use format, e.g. std::map. Is there a way > to take a font face loaded through FT and extract feature subtables from it > in this way? > > Thanks in advance, > Owen Lamb > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz > -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] The show must go on...
Heya, I took over maintenance of Pango 15 years ago. Code in there that I wanted to replace turned into HarfBuzz, and the rest is history. Lately, as you might have noticed, I've been slow to respond to my maintainer duties. At the same time, Ebrahim rose to fill in for me. He has proven to be very capable to replace me at this point, so I believe it's time to officiate that. My involvement in the project wouldn't otherwise change. I assure you all, my change of employment has nothing to do with this. It's just that.. it's time for me to stop blocking others' contributions while I focus on other things in life. Ebrahim, thank you for your leadership. I'm looking forward to seeing you make mistakes and learn from it. :) You are awesome. I look forward to talk to you in person next week. Cheers, behdad Tehran PS. Talk about "bus factor". Or is that called "bomb factor" these days.. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Exposing attachment tree / Arabic joining to shaping clients
On Tue, Nov 12, 2019 at 5:30 AM Ebrahim Byagowi wrote: > This is very interesting Behdad. Can this have Kashida priority also, like > what harfbuzz-old > <https://github.com/harfbuzz/harfbuzz-old/blob/master/src/harfbuzz-arabic.c#L402> > had. > I'm hesitant to do that. The reason I want to expose this is such that clients can do that while we figure out how to implement justification. > > [..] even the ones that do NOT use cursive joining. > > Guess this a property of a font rather than a buffer? > It's property of how font is designed. Some glyphs in the font might, and others not. > IranNastaliq had broken Kashida justification in IE6 but not in IE7, so > Microsoft probably has some insight to this, how to detect a font (or a > buffer) is not useful for Kashida justification. > Interesting. Can you provide test results for this? Let's understand what changed. > > [,,] The latter definitely belongs to the pos buffer > > Guess can't provide much help here. Just about shape of the API, maybe > like the way unsafe to break, hb_buffer_get_glyph_flags, is exposed, would > be useful for Arabic joining info and guess exposing priority can be done > in the some way but we can just forget about it for now. > > Thanks! > > On Thu, Oct 31, 2019 at 11:12 PM Behdad Esfahbod > wrote: > >> Hi, >> >> For reason that many of you know (letter-spacing, Arabic elongation, >> other postprocessing) I like to expose attachment data to the shaping >> clients. There's two separate pieces so far: >> >> - The Arabic joining info, which is applicable to all Arabic-like fonts >> even the ones that do NOT use cursive joining. >> >> - Mark attachment and cursive attachment. These form a tree with a >> attachment-type enum. >> >> I'm not sure which slots in the pos buffer to expose this in. The latter >> definitely belongs to the pos buffer, whereas the former is more a property >> of the text. So I feel like we should expose them separately. >> >> Ideas? >> >> -- >> behdad >> http://behdad.org/ >> ___ >> HarfBuzz mailing list >> HarfBuzz@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/harfbuzz > > -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Exposing attachment tree / Arabic joining to shaping clients
On Tue, Nov 12, 2019 at 7:31 PM Martin Hosken wrote: > Dear Behdad, > > > For reason that many of you know (letter-spacing, Arabic elongation, > other > > postprocessing) I like to expose attachment data to the shaping clients. > > There's two separate pieces so far: > > > > - The Arabic joining info, which is applicable to all Arabic-like fonts > > even the ones that do NOT use cursive joining. > > > > - Mark attachment and cursive attachment. These form a tree with a > > attachment-type enum. > > > > I'm not sure which slots in the pos buffer to expose this in. The latter > > definitely belongs to the pos buffer, whereas the former is more a > property > > of the text. So I feel like we should expose them separately. > > > > Ideas? > > Pulling back into the more generic script question, I think both may be > covered by giving the attachment parent and attachment type. Thus Arabic > joining is via cursive attachment Except that simple linear Arabic-like fonts don't do cursive joining. Letters just line up next to each other. > and diacritic attachment via mark attachment. IMHO, this would then also > apply naturally to other scripts and give some help with regard to > justification. > > Yours, > Martin > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Exposing attachment tree / Arabic joining to shaping clients
Hi, For reason that many of you know (letter-spacing, Arabic elongation, other postprocessing) I like to expose attachment data to the shaping clients. There's two separate pieces so far: - The Arabic joining info, which is applicable to all Arabic-like fonts even the ones that do NOT use cursive joining. - Mark attachment and cursive attachment. These form a tree with a attachment-type enum. I'm not sure which slots in the pos buffer to expose this in. The latter definitely belongs to the pos buffer, whereas the former is more a property of the text. So I feel like we should expose them separately. Ideas? -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Closing down the list, 2019 edition
On Tue, Aug 20, 2019 at 9:21 PM Werner LEMBERG wrote: > > >> I know I asked this before but... is there still value in keeping > >> the list around? I find myself preferring github issues over > >> mailing list threads all the time. > > I prefer e-mail lists. Assuming that I'm interested in general > HarfBuzz issues, I had to activate github tracking of all HarfBuzz > issues. However, this can produce an incredible amount of e-mails, as > the `fontforge' project shows where I have the `Watch' button enabled. > > Using github, how would I be able to `subscribe' only to general > HarfBuzz issues instead of reading all bug issues? > Sure. But a lot of discussion is already happening there. We'll keep the list as is I guess. > > Werner > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Closing down the list, 2019 edition
On Tue, Aug 20, 2019 at 5:56 PM Bob Hallissy wrote: > I guess I've not known of github issues being used for peer/community > support like asking "how to" questions, but is that what you are expecting? > Yes we already reply if people open such issues. We definitely won't bite. :) The reason I prefer issues is that they can seamlessly be turned into a tasklist for future, without being lost and without me or others having to keep in their inbox to remember... > Bob > > On 8/19/2019 11:58 AM, Behdad Esfahbod wrote: > > Hi all, > > I know I asked this before but... is there still value in keeping the list > around? I find myself preferring github issues over mailing list threads > all the time. > > I know our homepage / documentation / etc are lacking in a lot of ways and > maybe we just need to promote using github issues for all kinds of > inquiries instead... Anyway, just gauging how others feel, mid-2019 > edition. > > Cheers, > -- > behdad > http://behdad.org/ > > ___ > HarfBuzz mailing > listHarfBuzz@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/harfbuzz > > > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Closing down the list, 2019 edition
Hi all, I know I asked this before but... is there still value in keeping the list around? I find myself preferring github issues over mailing list threads all the time. I know our homepage / documentation / etc are lacking in a lot of ways and maybe we just need to promote using github issues for all kinds of inquiries instead... Anyway, just gauging how others feel, mid-2019 edition. Cheers, -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Display issue with DejaVu Sans Mono font
If the font has a GPOS table, we won't do any fallback positioning. As a result, if font has missing data (anchors in this case), you get exposed to that. On Sun, Aug 18, 2019 at 4:06 PM Khaled Hosny wrote: > > > > On Aug 18, 2019, at 4:40 AM, Eli Zaretskii wrote: > > > >> From: Khaled Hosny > >> Date: Sun, 18 Aug 2019 00:48:14 +0200 > >> Cc: Harfbuzz > >> > >>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-08/msg01082.html > >>> > >>> Is there something wrong with this font when displaying this sequence, > >>> or is there some kind of bug in Emacs and/or HarfBuzz? > >> > >> The second accent is placed next to the glyph, but hb-view is > incorrectly clipping the image, as you can see from hb-shape output: > >> > >> $ hb-shape DejaVuSansMono.ttf -u '061,301,302' > >> [aacute=0+1233|uni0302=0+0] > >> > >> Adding some margins gives: > >> > >> $ hb-view DejaVuSansMono.ttf -u '061,301,302’ --margin=0,150,0,0 > >> > >> > >> > >> HarfBuzz will compose U+0061 + U+0301 to U+00E1 (since it prefers > composed form when supported by the font), and that glyph does not have > anchors to position any marks above it, so the circumflex ends up with its > default position next to the glyph. > > > > So this is indeed some problem with that particular font? > > It is partly a font issue (missing anchors and combining marks default > position to the left of base glyph), and partly HarfBuzz design decision of > preferring composed forms. See > https://github.com/harfbuzz/harfbuzz/issues/653. > > Regards, > Khaled > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Use of bool and stdbool.h
On Fri, Aug 9, 2019 at 10:33 AM Ebrahim Byagowi wrote: > Was looking inside libraqm code and saw the use of stdbool.h there, made > we wonder why HarfBuzz went for hb_bool_t and whether we can go for it also > or not. > Because back in 2006 even stdint.h was not portable-enough. You still see the following block in hb-common.h: #if defined (_SVR4) || defined (SVR4) || defined (__OpenBSD__) || \ defined (_sgi) || defined (__sun) || defined (sun) || \ defined (__digital__) || defined (__HP_cc) # include #elif defined (_AIX) # include #elif defined (_MSC_VER) && _MSC_VER < 1600 /* VS 2010 (_MSC_VER 1600) has stdint.h */ typedef __int8 int8_t; typedef unsigned __int8 uint8_t; typedef __int16 int16_t; typedef unsigned __int16 uint16_t; typedef __int32 int32_t; typedef unsigned __int32 uint32_t; typedef __int64 int64_t; typedef unsigned __int64 uint64_t; #else # include #endif > If a migration isn't possible, most likely I'd guess, maybe having some > compiler definition for using actual bool instead 'int', at least for > clients that are embedding harfbuzz can trig some optimizations for them. > I don't think it makes any optimizations possible per se. I'd just forget it... We should review if we take any hb_bool_t* arguments in any API. If not, it's probably safe ABI-wise to change. > > Thanks! > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Failure in hb_font_get_nominal_glyph
Looks good to me.
On Thu, Jul 25, 2019, 11:57 AM Eli Zaretskii wrote:
> > From: Behdad Esfahbod
> > Date: Wed, 24 Jul 2019 15:21:15 -0400
> > Cc: Eli Zaretskii ,
> > "harfbuzz@lists.freedesktop.org"
> >
> > Ah, right. Yes. Before 2.0.0 you'd have to call hb_ot_font_set_funcs()
> explicitly...
> >
> > Thanks Khaled!
>
> Thanks.
>
> Just to be sure I understand: is the below the right fix?
>
> diff --git a/src/w32uniscribe.c b/src/w32uniscribe.c
> index aa6bebd..8fbbe7e 100644
> --- a/src/w32uniscribe.c
> +++ b/src/w32uniscribe.c
> @@ -32,6 +32,7 @@ #define _WIN32_WINNT 0x0600
> #include
> #ifdef HAVE_HARFBUZZ
> # include
> +# include /* for hb_ot_font_set_funcs */
> # if GNUC_PREREQ (4, 3, 0)
> # define bswap_32(v) __builtin_bswap32(v)
> # else
> @@ -1305,7 +1308,12 @@ w32hb_get_font (struct font *font, double *scale)
>hb_face_t *hb_face =
> hb_face_create_for_tables (w32hb_get_font_table, font_handle, NULL);
>if (hb_face_get_glyph_count (hb_face) > 0)
> -hb_font = hb_font_create (hb_face);
> +{
> + hb_font = hb_font_create (hb_face);
> + /* This is needed for HarfBuzz before 2.0.0; it is the default
> +in later versions. */
> + hb_ot_font_set_funcs (hb_font);
> +}
>
>struct uniscribe_font_info *uniscribe_font =
> (struct uniscribe_font_info *) font;
>
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Failure in hb_font_get_nominal_glyph
Ah, right. Yes. Before 2.0.0 you'd have to call hb_ot_font_set_funcs() explicitly... Thanks Khaled! On Wed, Jul 24, 2019 at 3:20 PM Khaled Hosny wrote: > > > > On Jul 24, 2019, at 9:13 PM, Eli Zaretskii wrote: > > > >> From: Behdad Esfahbod > >> Date: Wed, 24 Jul 2019 15:11:03 -0400 > >> Cc: "harfbuzz@lists.freedesktop.org" > >> > >> Nothing stands out to me. > > > > Thanks for taking a look. > > > > Could something like that be caused by an old version of Freetype > > library used with HarfBuzz? I believe when the OP upgraded his > > HarfBuzz he also upgraded Freetype as its dependency. > > > Emacs don’t seem to be using FreeType integration on your Windows code, so > that seems unlikely. > > I think Emacs is missing a call to hb_ot_font_set_funcs() after creating > the font. This is the default since only a few releases ago and Emacs code > seems to assume it. This is not needed on Linux since the FreeType > functions are used there. > > Regards, > Khaled -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Failure in hb_font_get_nominal_glyph
On Wed, Jul 24, 2019 at 3:13 PM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Wed, 24 Jul 2019 15:11:03 -0400 > > Cc: "harfbuzz@lists.freedesktop.org" > > > > Nothing stands out to me. > > Thanks for taking a look. > > Could something like that be caused by an old version of Freetype > library used with HarfBuzz? I believe when the OP upgraded his > HarfBuzz he also upgraded Freetype as its dependency. > Not really. Two-year-old version of either library shouldn't have such behavior, no. -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Failure in hb_font_get_nominal_glyph
Nothing stands out to me. On Tue, Jul 23, 2019 at 11:11 AM Eli Zaretskii wrote: > Could someone please take a look at the problems described here: > > https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00540.html > https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00557.html > https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00558.html > https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00561.html > > and tell whether it is expected that HarfBuzz 1.7.5 is too old to > support hb_font_get_nominal_glyph reliably on MS-Windows? According > to the HarfBuzz docs, that function is available since v1.2.3. > > Or maybe the code we have in Emacs has a bug? If you want to have a > look at the code that fails, it is here: > > http://git.savannah.gnu.org/cgit/emacs.git/tree/src/w32uniscribe.c#n1328 > > In a nutshell, the question is: why would hb_font_get_nominal_glyph > fail for the Courier New font, even when we are requesting a glyph for > an ASCII character? > > TIA > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] HB config
Hi Jonathan, Dominik, others, You might have noticed I spent last couple of months trimming down HarfBuzz binary size. I put some notes together in the repo: https://github.com/harfbuzz/harfbuzz/blob/master/CONFIG.md I like to hear any feedback, as well as any other tricks that need to be documented. I'm also working on a HB_NO_OT that will disable our main shaper. That's useful, eg. for apps shipping on iOS that can use CoreText while using HarfBuzz API still. Cheers, -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Order of combining diacriticals
On Thu, Jun 13, 2019 at 2:18 AM Eli Zaretskii wrote: > . For fonts that have no 'hebr' features, Emacs performs > substitution of known precomposed characters before it invokes the > shaping engine. In this case, it substituted U+FB31 for the > sequence U+05D1,U+05BC, and passed the sequence U+FB31,U+05B0 to > HarfBuzz. > You should remove all such hacks. -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Selecting fonts for HarfBuzz
On Wed, Jun 5, 2019 at 12:36 PM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Wed, 5 Jun 2019 12:07:36 -0700 > > Cc: "harfbuzz@lists.freedesktop.org" > > > > In other words, I don't know of a legitimate way to filter out broken > fonts like code2000. If that's what you are > > asking for. > > No, I wasn't asking about Code2000, I was asking a more general > question. > > > Let me ask it differently: why do you think you need to filter anything > out? > > I assumed that some fonts will not benefit from HarfBuzz, i.e. will > not support complex script shaping, because they lack some fundamental > features HarfBuzz needs. > > When Emacs needs to find a font for displaying a character which is > not supported by the default font, it scans the available fonts on the > system, looking for matching fonts. On Windows, we currently have 2 > matching criteria: one for fonts suitable for shaping with Uniscribe, > the other for all the rest (the latter generally don't support complex > script shaping). For HarfBuzz, the code currently employs the same > matching criteria as for Uniscribe (I described them roughly in a > previous message). I was asking whether HarfBuzz has additional > requirements from fonts, or would any font that's good for Uniscribe > will be good for HarfBuzz. > HarfBuzz handles everything it understands. It was designed, in fact, such that when combined with FreeType or other external font funcs implementation, it even "handles" font formats it does not understand. Eg. HarfBuzz doesn't understand BDF, PCF, etc, but if you use hb-ft, you can use hb-ft for everything, and BDF, PCF etc also magically work because HarfBuzz defers to FreeType for glyph access, and simply "passes through" for the rest. It was designed such that you can keep one shaping code path. -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Selecting fonts for HarfBuzz
On Tue, Jun 4, 2019 at 8:01 PM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Tue, 4 Jun 2019 12:05:00 -0700 > > Cc: "harfbuzz@lists.freedesktop.org" > > > > We assume fonts support shaping. Ie. we don't have a way to check for > font suitability for correct shaping. > > I understand, thanks. I wasn't asking how to do that with HarfBuzz, I > was asking what font features should my font matching function examine > to make sure the font will "support shaping" in the HarfBuzz sense. > Features that can be tested without actually shaping some text, of > course, i.e. without actually opening the font and using it. > And I was talking generally. There's nothing you can check in fonts that wouldn't leave some valid use-case out. In other words, I don't know of a legitimate way to filter out broken fonts like code2000. If that's what you are asking for. Let me ask it differently: why do you think you need to filter anything out? -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Patches for building HarfBuzz with mingw.org's MinGW
Hi Eli,
I can't say I'm super-excited about adding more workarounds, specially
since I don't even understand why you can't use mingw64 instead.
At any rate, I'm not one to judge. Please open a github Pull Request with
your changes and we'll go from there.
Thanks
On Sun, Jun 2, 2019 at 9:35 AM Eli Zaretskii wrote:
> Hi,
>
> I'd like to submit a few small patches that allow HarfBuzz to be built
> on Windows with mingw.org's MinGW toolchain. (And before you ask: the
> reason you don't see the problems I describe below in your MinGW
> builds is that you use MinGW64, which is a different flavor of MinGW.)
>
> The patches are against HarfBuzz 2.5.1.
>
> Here are the patches, with explanations:
>
> 1. This patch is needed because MinGW doesn't have _BitScanForward and
> _BitScanReverse. They are only used with old GCC versions, so
> conditioning their calls by those old versions of GCC is good enough,
> IMO.
>
> --- src/hb-algs.hh~02019-06-01 08:49:47.0 +0300
> +++ src/hb-algs.hh 2019-06-02 11:03:52.373677900 +0300
> @@ -400,7 +400,7 @@
> return sizeof (unsigned long long) * 8 - __builtin_clzll (v);
> #endif
>
> -#if (defined(_MSC_VER) && _MSC_VER >= 1500) || defined(__MINGW32__)
> +#if (defined(_MSC_VER) && _MSC_VER >= 1500) || (defined(__MINGW32__) &&
> (__GNUC__ < 4))
>if (sizeof (T) <= sizeof (unsigned int))
>{
> unsigned long where;
> @@ -474,7 +474,7 @@
> return __builtin_ctzll (v);
> #endif
>
> -#if (defined(_MSC_VER) && _MSC_VER >= 1500) || defined(__MINGW32__)
> +#if (defined(_MSC_VER) && _MSC_VER >= 1500) || (defined(__MINGW32__) &&
> (__GNUC__ < 4))
>if (sizeof (T) <= sizeof (unsigned int))
>{
> unsigned long where;
>
>
> 2. This patch is needed because mingw.org's MinGW defines
> MemoryBarrier as an inline function, not as a macro.
> __MINGW32_VERSION is defined only by mingw.org's MinGW, so the change
> shouldn't affect MinGW64.
>
> --- src/hb-atomic.hh~0 2019-05-27 20:07:58.0 +0300
> +++ src/hb-atomic.hh2019-06-02 10:55:49.013099500 +0300
> @@ -107,7 +107,7 @@
>
> static inline void _hb_memory_barrier ()
> {
> -#ifndef MemoryBarrier
> +#if !defined(MemoryBarrier) && !defined(__MINGW32_VERSION)
>/* MinGW has a convoluted history of supporting MemoryBarrier. */
>LONG dummy = 0;
>InterlockedExchange (, 1);
>
>
> 3. This patch is needed because MinGW doesn't define
> E_NOT_SUFFICIENT_BUFFER.
>
> --- src/hb-uniscribe.cc~0 2019-05-14 03:28:16.0 +0300
> +++ src/hb-uniscribe.cc 2019-06-02 11:04:43.843081900 +0300
> @@ -31,6 +31,10 @@
> #include
> #include
>
> +#ifndef E_NOT_SUFFICIENT_BUFFER
> +#define E_NOT_SUFFICIENT_BUFFER HRESULT_FROM_WIN32
> (ERROR_INSUFFICIENT_BUFFER)
> +#endif
> +
> #include "hb-uniscribe.h"
>
> #include "hb-open-file.hh"
>
>
> 4. This patch is needed because mingw.org's MinGW doesn't have the
> intrin.h header file; instead, the intrinsics are declared by
> including windows.h.
>
> --- src/hb.hh~0 2019-05-14 09:42:00.0 +0300
> +++ src/hb.hh 2019-06-02 11:06:01.413041500 +0300
> @@ -183,8 +183,15 @@
> #include
>
> #if (defined(_MSC_VER) && _MSC_VER >= 1500) || defined(__MINGW32__)
> +#ifdef __MINGW32_VERSION
> +#ifndef WIN32_LEAN_AND_MEAN
> +#define WIN32_LEAN_AND_MEAN 1
> +#endif
> +#include
> +#else
> #include
> #endif
> +#endif
>
> #define HB_PASTE1(a,b) a##b
> #define HB_PASTE(a,b) HB_PASTE1(a,b)
>
>
> Thank you for developing HarfBuzz.
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/harfbuzz
--
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Selecting fonts for HarfBuzz
We assume fonts support shaping. Ie. we don't have a way to check for font suitability for correct shaping. On Sun, Jun 2, 2019 at 11:43 AM Eli Zaretskii wrote: > When searching the system for suitable fonts, are there any > considerations or features the client should prefer, or prefer not to > have, besides preferring OTF/TTF fonts, to produce the best shaping > via HarfBuzz? > > Thanks. > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Help: Regarding HarfBuzz Library Support
Hi, It looks like an old & buggy C++ compiler to me. I'm afraid we are not able to help beyond that. Also, you *really* should be using newer HarfBuzz than 0.9.36... Try 2.4.0 or 2.5.0. On Thu, May 30, 2019 at 12:05 AM naga raju wrote: > Hi, > > I want to use HarfBuzz Library version. 0.9.36 in SH3 controllers using > VxWorks 6.4. > > When I tried to compile, I am getting the Template related errors as below. > > No instance of Function template "MIN" matches the argument list. > > No instance of Function template "ARRAY_LENGTH" matches the argument list. > > I am not able to proceed further. > > Request you to kindly suggest me for proceeding further. > > Thanks in advance. > > > Thanks & Regards > Nagaraju > > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Getting compliation error while building harfbuzz library 2.5.0
Hi, That's a known issue we are having with MSVC versions other than 2015. You can follow progress or find a workaround at: https://github.com/harfbuzz/harfbuzz/issues/1730 On Thu, May 30, 2019 at 9:27 AM Bikramjit Singh wrote: > Hi, > > > > We are building and using harfbuzz library 2.1.0 along with > icu-le-hb-1.0.3 on both Win and Mac platforms successfully. > > > > We are using Visual Studio 2017 along with SDK version 10.0.17134.0 to > build the libraries on Window. > > > > But when I try to build the harfbuzz library 2.5.0, it is giving the > following error on Windows: > > *“hb-algs.hh(839): error C2440: 'return': cannot convert > from 'hb_partial_t<2,Appl,V>' to 'hb_partial_t<2,Appl,V>'”* > > > > Please note that we are only building harfbuzz.lib and no other solution > e.g. harfbuzz-ot-tag or harfbuzz-subset etc. > > > > Can you please check and confirm ? > > > > Please send the solution also. > > > > *Thanks n Regards,* > > *Bikramjit Singh* > > > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Units of members of hb_glyph_position_t
On Tue, May 28, 2019 at 3:02 PM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Tue, 28 May 2019 14:46:45 -0400 > > Cc: "harfbuzz@lists.freedesktop.org" > > > > You pick what value you want to represent one pixel as. Say, you choose > 1024. Then if you want to render at > > "16px" font size, you set scale to 16*1024. That's all. > > And then the values of hb_glyph_position_t should be divided by 1024 > to produce pixels when using this hb_font_t object? > Yes. -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Units of members of hb_glyph_position_t
On Tue, May 28, 2019 at 11:44 AM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Mon, 27 May 2019 21:21:10 -0400 > > Cc: "harfbuzz@lists.freedesktop.org" > > > > control those units (if they are under the client program's control). > > > > They are controlled mainly using hb_font_set_scale(). > > > > In particular, I get a huge value of x_advance for the letter U+05EA > > HEBREW LETTER TAV when it is followed by U+05BB HEBREW POINT QUBUTS. > > The value of x_advance I get is 1229, which is too large even after > > dividing by 64 (which, btw, I still am not sure is TRT in my case, > > > > FreeType works in 26.6 fixed-point, ie. 64 units per 1.0. That's where > the 64 value comes from. And you > > don't see it in your code because hb_ft_font_create* sets that on > hb_font for you. > > > > In your Windows code, you should call hb_font_set_scale(). I believe > right now you are *not* calling, and you > > get values in the face's UPEM. That's the default scale for fonts. You > can get the face UPEM using > > hb_face_get_upem(). > > OK, I figured out how to scale the units from UPEM to pixels for a > given font size, and now I see reasonable results after such scaling. > > However, I think something is still amiss, because I still don't > understand how to determine the values with which to call > hb_font_set_scale. Say I call it with an integer value N, what will > that produce in terms of values of hb_glyph_position_t? Will the > values there be in the 0..N range, where N means the full height of > the em box? If so, how would I then convert those values to pixels -- > this conversion will need the font size as well, right? And if so, I > might well leave the values in UPEM units, and convert them to pixels > by hand. I feel that I'm still missing something, since you said "you > should call hb_font_set_scale". So presumably if I call that > function, conversion to pixels will somehow become easier? > You pick what value you want to represent one pixel as. Say, you choose 1024. Then if you want to render at "16px" font size, you set scale to 16*1024. That's all. -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Units of members of hb_glyph_position_t
On Mon, May 27, 2019 at 2:21 PM Eli Zaretskii wrote: > I cannot figure out in what units are these values reported, or how to > The meaning is left to the client. > control those units (if they are under the client program's control). > They are controlled mainly using hb_font_set_scale(). > In particular, I get a huge value of x_advance for the letter U+05EA > HEBREW LETTER TAV when it is followed by U+05BB HEBREW POINT QUBUTS. > The value of x_advance I get is 1229, which is too large even after > dividing by 64 (which, btw, I still am not sure is TRT in my case, > FreeType works in 26.6 fixed-point, ie. 64 units per 1.0. That's where the 64 value comes from. And you don't see it in your code because hb_ft_font_create* sets that on hb_font for you. In your Windows code, you should call hb_font_set_scale(). I believe right now you are *not* calling, and you get values in the face's UPEM. That's the default scale for fonts. You can get the face UPEM using hb_face_get_upem(). -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to get a glyph code for a character?
On Sat, May 25, 2019 at 10:26 AM Eli Zaretskii wrote: > One of the methods an Emacs font-backend should provide is the > encode_char method, which returns the glyph code of the selected font > for a character given by its Unicode codepoint. For example, the XFT > backend uses the XftCharIndex function for that purpose, and the > Freetype backend uses FT_Get_Char_Index. > > What is the best way of providing such a method with HarfBuzz on > MS-Windows? One possibility is obviously to call hb_shape, but maybe > there's a simpler way for a single codepoint? > hb_font_get_nominal_glyph(). Use of such facilities in an application is quite suspect though. > Btw, what does hb_font_get_glyph() return? > Boolean indicating whether the font supports that character. > TIA > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
On Fri, May 24, 2019 at 2:23 PM Eli Zaretskii wrote: > > But the question about hb_face_t management is still not entirely > clear. I don't really need hb_face_t, I only create it as an > intermediate step towards hb_font_t. So my question is: once I have > hb_font_t, can I destroy the hb_face_t I used to create hb_font_t? If > not, how do I arrange for hb_face_t to be destroyed when the > corresponding hb_font_t is destroyed? > Yes. Just destroy anything as soon as you personally don't need it. Destroy hb_blob_t after you pass it to hb_face_create...(). Destroy hb_face_t as soon as you pass it to hb_font_create(). HB uses reference-counting to actually destroy things when they are not used anymore. -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
On Fri, May 24, 2019 at 1:58 PM Konstantin Ritt wrote:
> пт, 24 мая 2019 г. в 20:49, Behdad Esfahbod :
>
>> Thanks Konstantin,
>>
>> What about DirectWrite-driven font funcs though? Does Qt have those?
>>
>
> Yep we do, both GDI and DW.
> I think we should start moving our backends (or their respective parts) to
> HB at some point. We could start a dedicated topic to discuss that.
>
Yes please. I look forward to that! Same with CoreText font funcs.
>
> Regards,
> Konstantin
>
>
>
>
>>
>> On Fri, May 24, 2019 at 1:45 PM Konstantin Ritt
>> wrote:
>>
>>> Hi Behdad,
>>>
>>> That was just a glance example of the font table
>>> referencing GDI-HB bridge.
>>> Feel free to use it in hb- if you like it ;P
>>>
>>> As for font-funcs, I doubt GDI is a subject of interest these days. I
>>> might be wrong here, though.
>>>
>>> Regards,
>>> Konstantin
>>>
>>>
>>> пт, 24 мая 2019 г. в 19:18, Behdad Esfahbod :
>>>
>>>> Thanks Konstantin!
>>>>
>>>> Should this become a hb-uniscribe (or hb-gdi?) API?
>>>>
>>>> On Fri, May 24, 2019 at 12:17 PM Konstantin Ritt
>>>> wrote:
>>>>
>>>>> hb_blob_t *my_reference_table(hb_face_t * /*face*/, hb_tag_t tag, void
>>>>> *user_data)
>>>>>
>>>>> {
>>>>>
>>>>> HDC hdc = (HDC)user_data;
>>>>>
>>>>> SelectObject(hdc, hfont);
>>>>>
>>>>>
>>>>> char *buffer = NULL;
>>>>>
>>>>> DWORD length = 0;
>>>>>
>>>>> length = GetFontData(hdc, byte_swap(tag), 0, buffer,
>>>>> length);
>>>>>
>>>>> if (length == GDI_ERROR)
>>>>>
>>>>> return hb_blob_get_empty();
>>>>>
>>>>>
>>>>> buffer = (char *)::malloc(length);
>>>>>
>>>>> length = GetFontData(hdc, byte_swap(tag), 0, buffer, length);
>>>>>
>>>>> if (length == GDI_ERROR)
>>>>>
>>>>> length = 0;
>>>>>
>>>>>
>>>>> return hb_blob_create((const char *)buffer, length,
>>>>> HB_MEMORY_MODE_READONLY, buffer, ::free);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> hb_face_t *my_face_create_from_hdc(HDC hdc)
>>>>>
>>>>> {
>>>>>
>>>>> return hb_face_create_for_tables(my_reference_table, (void *)hdc,
>>>>> NULL);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Konstantin
>>>>>
>>>>>
>>>>> пт, 24 мая 2019 г. в 16:39, Eli Zaretskii :
>>>>>
>>>>>> > From: Ebrahim Byagowi
>>>>>> > Date: Fri, 24 May 2019 20:13:43 +0430
>>>>>> > Cc: Harfbuzz
>>>>>> >
>>>>>> > Pardon me for the may inaccurate following answer I have to write
>>>>>> quickly,
>>>>>>
>>>>>> Thanks for your help.
>>>>>>
>>>>>> > > Also, does HarfBuzz support TrueType Collection (TTC) files, and
>>>>>> if so, does it want the data only for the
>>>>>> > currently selected font or all
>>>>>> > of the data?
>>>>>> >
>>>>>> > It does, if you want harfbuzz handles it for you, you should give
>>>>>> it the full blob and set the index you like in
>>>>>> > second argument of hb_face_create, otherwise you should handle it
>>>>>> yourself.
>>>>>>
>>>>>> OK, this brings me to another question: what should I in general pass
>>>>>> as the 2nd argument of hb_face_create? Suppose I'm using a TTF or OTF
>>>>>> font file, should I always pass zero as the 2nd argument? What is the
>>>>>> semantics of that argument?
>>>>>>
>>>>>> > > I'm now working on the HarfBuzz font driver for Emacs on Windows
>>>>>> using GetFontData with the dwTable
>>>>>> > argument zero, to get the entire data of the font.
>>>&
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
Thanks Konstantin!
Should this become a hb-uniscribe (or hb-gdi?) API?
On Fri, May 24, 2019 at 12:17 PM Konstantin Ritt wrote:
> hb_blob_t *my_reference_table(hb_face_t * /*face*/, hb_tag_t tag, void
> *user_data)
>
> {
>
> HDC hdc = (HDC)user_data;
>
> SelectObject(hdc, hfont);
>
>
> char *buffer = NULL;
>
> DWORD length = 0;
>
> length = GetFontData(hdc, byte_swap(tag), 0, buffer, length);
>
> if (length == GDI_ERROR)
>
> return hb_blob_get_empty();
>
>
> buffer = (char *)::malloc(length);
>
> length = GetFontData(hdc, byte_swap(tag), 0, buffer, length);
>
> if (length == GDI_ERROR)
>
> length = 0;
>
>
> return hb_blob_create((const char *)buffer, length,
> HB_MEMORY_MODE_READONLY, buffer, ::free);
>
> }
>
>
> hb_face_t *my_face_create_from_hdc(HDC hdc)
>
> {
>
> return hb_face_create_for_tables(my_reference_table, (void *)hdc, NULL);
>
> }
>
>
>
>
> Regards,
> Konstantin
>
>
> пт, 24 мая 2019 г. в 16:39, Eli Zaretskii :
>
>> > From: Ebrahim Byagowi
>> > Date: Fri, 24 May 2019 20:13:43 +0430
>> > Cc: Harfbuzz
>> >
>> > Pardon me for the may inaccurate following answer I have to write
>> quickly,
>>
>> Thanks for your help.
>>
>> > > Also, does HarfBuzz support TrueType Collection (TTC) files, and if
>> so, does it want the data only for the
>> > currently selected font or all
>> > of the data?
>> >
>> > It does, if you want harfbuzz handles it for you, you should give it
>> the full blob and set the index you like in
>> > second argument of hb_face_create, otherwise you should handle it
>> yourself.
>>
>> OK, this brings me to another question: what should I in general pass
>> as the 2nd argument of hb_face_create? Suppose I'm using a TTF or OTF
>> font file, should I always pass zero as the 2nd argument? What is the
>> semantics of that argument?
>>
>> > > I'm now working on the HarfBuzz font driver for Emacs on Windows
>> using GetFontData with the dwTable
>> > argument zero, to get the entire data of the font.
>> >
>> > Is it DirectWrite? Have you seen the helper we have the in
>> hb-directwrite.h and hb-uniscribe.h? They can be
>> > very useful.
>>
>> I'm not using DirectWrite, nor am I using Uniscribe. My HarfBuzz is
>> built without these two, as I understand building with these back-ends
>> is only needed for comparison. I want to use the HarfBuzz shaper, and
>> only it (Emacs already has support for Uniscribe).
>>
>> But yes, I do consult these files to figure out answers to my
>> questions.
>>
>> > > does their memory need to be freed in some manner after I have the
>> hb_font_t object, or do I have to keep
>> > them as long as hb_font_t is in use?
>> >
>> > Don't free it yourself specially if in use, you can use harfbuzz
>> destroy callback so harfbuzz can handle it for
>> > you.
>>
>> Sorry, I don't think I understand: what do you mean by "harfbuzz
>> destroy callback"? If you mean the 'destroy" argument of
>> hb_blob_create, then AFAIU this is called only to destroy user_data,
>> and I don't have user_data, I pass NULL as the 4th argument of
>> hb_blob_create. And hb_face_create doesn't have any callback argument
>> at all.
>>
>> I see in the few programs in util/ that both the blob and the face are
>> destroyed as soon as hb_font_t object is created, which is why I
>> thought I could do the same. But now you seem to say I shouldn't?
>>
>> For that matter, what should I use as the 'mode' argument of
>> hb_blob_create?
>>
>> This page:
>>
>> https://harfbuzz.github.io/object-model-blobs.html
>>
>> shows an example of calling hb_blob_create with 'free' (in my case,
>> 'xfree') as the 'destroy' callback, so I guess my interpretation of
>> that argument as being pertinent to user_data was incorrect? Still,
>> the questions about memory management for hb_face_t and about the
>> semantics of the hb_memory_mode_t enum values are left unanswered.
>>
>> > > I see that hb_blob_create, hb_face_create etc. return empty objects
>> when they fail. But I see no "is-empty"
>> > function or macro in the docs, did I miss something?
>> >
>> > Some of the objects may work with empty comparison but it is not broken
>> face
>> > https://github.com/harfbuzz/harfbuzz/issues/1572 but something does it
>> very accurately is
>> > hb_face_get_glyph_count
>>
>> AFAIU, you are saying that if hb_face_get_glyph_count returns zero,
>> the face is empty and shouldn't be used, is that right?
>>
>> > > Where do those 64.0 factors come from?
>> >
>> > Subpixel accuracy, harfbuzz works with integers but as subpixel
>> accuracy needed you have to we need to do
>> > some scaling. Scaling is not the pixels but _set_ppem and _set_ptem is
>> (this is very inaccurate, but I hope
>> > would be useful)
>>
>> Does this mean I should use the factor of 64 in my code as well? Or
>> does that value depend on some properties of the font?
>>
>> >
>> > > Or point me to the documentation where that is described, if I missed
>> it?
>> >
>> >
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
Also font-funcs if you can contribute those.
On Fri, May 24, 2019 at 12:17 PM Behdad Esfahbod wrote:
> Thanks Konstantin!
>
> Should this become a hb-uniscribe (or hb-gdi?) API?
>
> On Fri, May 24, 2019 at 12:17 PM Konstantin Ritt
> wrote:
>
>> hb_blob_t *my_reference_table(hb_face_t * /*face*/, hb_tag_t tag, void
>> *user_data)
>>
>> {
>>
>> HDC hdc = (HDC)user_data;
>>
>> SelectObject(hdc, hfont);
>>
>>
>> char *buffer = NULL;
>>
>> DWORD length = 0;
>>
>> length = GetFontData(hdc, byte_swap(tag), 0, buffer, length);
>>
>> if (length == GDI_ERROR)
>>
>> return hb_blob_get_empty();
>>
>>
>> buffer = (char *)::malloc(length);
>>
>> length = GetFontData(hdc, byte_swap(tag), 0, buffer, length);
>>
>> if (length == GDI_ERROR)
>>
>> length = 0;
>>
>>
>> return hb_blob_create((const char *)buffer, length,
>> HB_MEMORY_MODE_READONLY, buffer, ::free);
>>
>> }
>>
>>
>> hb_face_t *my_face_create_from_hdc(HDC hdc)
>>
>> {
>>
>> return hb_face_create_for_tables(my_reference_table, (void *)hdc, NULL);
>>
>> }
>>
>>
>>
>>
>> Regards,
>> Konstantin
>>
>>
>> пт, 24 мая 2019 г. в 16:39, Eli Zaretskii :
>>
>>> > From: Ebrahim Byagowi
>>> > Date: Fri, 24 May 2019 20:13:43 +0430
>>> > Cc: Harfbuzz
>>> >
>>> > Pardon me for the may inaccurate following answer I have to write
>>> quickly,
>>>
>>> Thanks for your help.
>>>
>>> > > Also, does HarfBuzz support TrueType Collection (TTC) files, and if
>>> so, does it want the data only for the
>>> > currently selected font or all
>>> > of the data?
>>> >
>>> > It does, if you want harfbuzz handles it for you, you should give it
>>> the full blob and set the index you like in
>>> > second argument of hb_face_create, otherwise you should handle it
>>> yourself.
>>>
>>> OK, this brings me to another question: what should I in general pass
>>> as the 2nd argument of hb_face_create? Suppose I'm using a TTF or OTF
>>> font file, should I always pass zero as the 2nd argument? What is the
>>> semantics of that argument?
>>>
>>> > > I'm now working on the HarfBuzz font driver for Emacs on Windows
>>> using GetFontData with the dwTable
>>> > argument zero, to get the entire data of the font.
>>> >
>>> > Is it DirectWrite? Have you seen the helper we have the in
>>> hb-directwrite.h and hb-uniscribe.h? They can be
>>> > very useful.
>>>
>>> I'm not using DirectWrite, nor am I using Uniscribe. My HarfBuzz is
>>> built without these two, as I understand building with these back-ends
>>> is only needed for comparison. I want to use the HarfBuzz shaper, and
>>> only it (Emacs already has support for Uniscribe).
>>>
>>> But yes, I do consult these files to figure out answers to my
>>> questions.
>>>
>>> > > does their memory need to be freed in some manner after I have the
>>> hb_font_t object, or do I have to keep
>>> > them as long as hb_font_t is in use?
>>> >
>>> > Don't free it yourself specially if in use, you can use harfbuzz
>>> destroy callback so harfbuzz can handle it for
>>> > you.
>>>
>>> Sorry, I don't think I understand: what do you mean by "harfbuzz
>>> destroy callback"? If you mean the 'destroy" argument of
>>> hb_blob_create, then AFAIU this is called only to destroy user_data,
>>> and I don't have user_data, I pass NULL as the 4th argument of
>>> hb_blob_create. And hb_face_create doesn't have any callback argument
>>> at all.
>>>
>>> I see in the few programs in util/ that both the blob and the face are
>>> destroyed as soon as hb_font_t object is created, which is why I
>>> thought I could do the same. But now you seem to say I shouldn't?
>>>
>>> For that matter, what should I use as the 'mode' argument of
>>> hb_blob_create?
>>>
>>> This page:
>>>
>>> https://harfbuzz.github.io/object-model-blobs.html
>>>
>>> shows an example of calling hb_blob_create with 'free' (in my case,
>>> 'xfree') as the 'destroy' callback, so I guess my interpretation of
>>> that argu
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
On Sat, May 11, 2019 at 12:16 PM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Sat, 11 May 2019 11:51:16 -0700 > > Cc: Jonathan Kew , > > "harfbuzz@lists.freedesktop.org" > > > > Not sure yet. What is a "font" for this purpose? Does it have to be > > the full contents of a font file on disk? > > > > Yes. The font file. Maybe describe what you are trying to do? > > I'm trying to use on MS-Windows the HarfBuzz shaping function for > Emacs, which Khaled wrote. The code as written uses Freetype-specific > data (FT_Face), and I'm trying to provide it with the Windows > equivalents instead. > > As for passing the font file's data to hb_blob_create: it is quite > unusual to manipulate physical font files on MS-Windows, the usual > paradigm is to use a "logical font", which is a specification for a > font, and then retrieve the metrics of the font using dedicated APIs. > So I wonder whether there's an alternative to accessing the physical > font files. > See what Jonathan said. That, and you can even implement Windows-backed font-funcs. Several projects do that. Say, look at Qt maybe? -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
On Sat, May 11, 2019 at 11:50 AM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Sat, 11 May 2019 11:38:58 -0700 > > Cc: Jonathan Kew , > > "harfbuzz@lists.freedesktop.org" > > > > The blob simply hold the font file bytes. There's even > hb_blob_create_from_file. > > > > Makes sense? > > Not sure yet. What is a "font" for this purpose? Does it have to be > the full contents of a font file on disk? > Yes. The font file. Maybe describe what you are trying to do? -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
On Sat, May 11, 2019 at 11:36 AM Eli Zaretskii wrote: > > From: Behdad Esfahbod > > Date: Sat, 11 May 2019 11:26:29 -0700 > > Cc: Jonathan Kew , > > "harfbuzz@lists.freedesktop.org" > > > > Or just use hb_face_create() and hb_font_create(). > > Thanks, that's what I thought I needed to do to begin with. However, > hb_face_create needs a 'blob' argument, and I couldn't understand how > to call hb_blob_create to get a suitable blob. Then I looked at how > hb_ft_face_create does it, and saw that it makes a blob out of FT_Face > structure. But I couldn't see how that blob is used by HarfBuzz, and > so couldn't decide how to call hb_blob_create in my case. > The blob simply hold the font file bytes. There's even hb_blob_create_from_file. Makes sense? -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
On Sat, May 11, 2019 at 4:13 AM Eli Zaretskii wrote: > > From: Jonathan Kew > > Date: Sat, 11 May 2019 11:08:42 +0100 > > > > You can use hb_face_create_for_tables, passing it a function that can > > retrieve font tables (as hb_blobs) when requested by harfbuzz. > > > > This is what Firefox does, to use harfbuzz with Windows or MacOS font > > APIs; a starting point to explore the Firefox code would be [1], where > > we call hb_face_create_for_tables and pass it HBGetTable as the > > reference_table_func. This calls down to the GetFontTable() method, > > which has separate implementations for the various platforms. > > Thanks, this gets me a notch forward, but I'm afraid there's still a > lot of fog. Specifically, what does HarfBuzz expect from the > hb_blob's it retrieves this way, and where and how does it use those > blobs? > Or just use hb_face_create() and hb_font_create(). -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Question on converting UTF-8 codepoints to complex glyphs
Oh oh! Can you point us to the tutorial page? Nate, can you fix this please? On Thu, Apr 11, 2019 at 5:24 PM Paul Daughetee wrote: > Thanks Richard for the pointer. I wish I had seen Jonathan's post. > However, it never appeared in the digest I received from the list (nor to > me directly) so I never saw it. To be fair, the following is from the > HarfBuzz tutorial on the "Why do I need a shaping engine?" page: "For > example, in Tamil, when the letter "TTA" (ட) letter is followed by "U" (உ), > the pair must be replaced by the single glyph "டு". The sequence of Unicode > characters "டஉ" needs to be substituted with a single "டு" glyph from the > font." So maybe that needs an edit. > > I converted my UTF-8 string to be [0xE0, 0xAE, 0x88, 0xE0, 0xAE, 0x9F, > 0xE0, 0xAF, 0x81] and I finally got back the correct glyph identifiers. So > thank you all for your responses. I'm sure I'll have more questions as this > project evolves. > > -Original Message- > From: Richard Wordingham > Sent: April 11, 2019 12:16 PM > To: harfbuzz@lists.freedesktop.org > Cc: Paul Daughetee > Subject: Re: [HarfBuzz] Question on converting UTF-8 codepoints to complex > glyphs > > On Thu, 11 Apr 2019 18:03:10 + > Paul Daughetee wrote: > > > டு [...] > > is the ligature formed by the codepoints corresponding to the glyphs ட > > and உ. > > No! You already have been told by Jonathan Kew. > > டு is the codepoint sequence SIGN U>; it is **not** the ligature of ட TTA> and உ . If you don't believe me, paste > them into Word and use alt/X to convert the characters to their codepoints. > > Richard. > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Question on converting UTF-8 codepoints to complex glyphs
What you say seems irrelevant to me. Jonathan is correct. On Thu, Apr 11, 2019, 11:34 AM Bobby de Vos wrote: > Paul, > > You don't need to convert the Google Tamil font to OpenType, Google has > already done that at > > > https://github.com/googlei18n/noto-fonts/tree/master/phaseIII_only/unhinted/otf/NotoSansTamil > > However, I don't think those fonts will solve your issue. The list of > shapers that you mention are different technologies to specify the complex > shaping (such ligatures, positioning, sub forms, half foms, etc). Indeed, > OpenType is one such technology. SIL Graphite and Apple Advanced Typography > (AAT) are other technologies to do this. > > TrueType fonts can contain OpenType shaping instructions. You do not have > to have an OpenType font format to use OpenType shaping. > > TrueType fonts have quadratic Bézier curves for their glyphs. Fonts in the > OpenType font format can use the same quadratic Bézier curves, or cubic > Bézier curves. The OTF files I mentioned above have cubic Bézier curves. > > https://en.wikipedia.org/wiki/B%C3%A9zier_curve#Fonts > > If I have mis-understood your situation, and/or made any errors if what I > wrote, I apologize. > > Bobby > On 2019-04-10 3:25 p.m., Paul Daughetee wrote: > > Thanks for the quick response. I’m a licensed user of FontCreator > Professional Edition from High-Logic and have the most recent update to > version 11.5 installed. The correct ligature is displayed when I type the > tta and u Tamil characters into the test string edit box in the OpenType > Designer dialog. In the box just below the test string the two characters > are displayed unless I check either the _shaper or psts feature check box. > If one of those is checked, then the correct ligature is displayed. So I > guess Google did get the Tamil font right but I cannot seem to get HarfBuzz > to return a single glyph id when presented with a buffer containing the tta > and u Tamil characters. I’ve tried adding various features when calling > hb_shape but that doesn’t seem to change anything. > > > > I noticed that when I list shapers using a call to hb_shape_list_shapers, > the only shaper listed is “ot”. So I guess my next try will be to convert > the Google Tamil true type font to an open type font and see if that makes > any difference. If it does, I guess I’ll be having a “duh” moment. > > > > *From:* Cody Planteen > *Sent:* April 10, 2019 12:38 PM > *To:* Paul Daughetee > *Cc:* harfbuzz@lists.freedesktop.org > *Subject:* Re: [HarfBuzz] Question on converting UTF-8 codepoints to > complex glyphs > > > > It's possible your font isn't doing what you think it should be. You can > test this theory with the tool High-Logic FontCreator for Windows. I > believe there is a free evaluation. You can open up your font, then go to > Font -> OpenType Designer. In this dialog, you can enter your test string > and see what glyphs come out. > > > > https://www.high-logic.com/font-editor/fontcreator > > > > > > On Wed, Apr 10, 2019 at 1:19 PM Paul Daughetee > wrote: > > Let me give you a little more info. I just recently built and installed > vcpkg and used it to install HarfBuzz on Windows 10. It installed version > 2.3.1-3 of the static libraries for Window x86. I linked my app to the > HarfBuzz library and its dependencies. I added code to my app to capture > single words that I could send to be processed by HarfBuzz as they were > typed by the user. I installed Google’s NotoSansTamil true type font after > verifying that it properly defined substitutions for the ligature that is > formed by the Tamil consonant “tta” when paired with a vowel such as “u” or > “I”. After processing a UTF-8 string containing the consonant and the vowel > “tta” and “u” [0xE0, 0xAE, 0x9F, 0xE0, 0xAE, 0x89], the hb_glyph_info_t > object I get back has tow glyph indices, the same indices as the “tta” and > “u” (17, 10) rather than the index for the “ttauvowelsign” (116) ligature I > expected. My code is virtually identical to the examples found in the > HarfBuzz wiki and to several examples found in git. Any help here would be > greatly appreciated. > > > > *From:* Behdad Esfahbod > *Sent:* April 8, 2019 1:47 PM > *To:* Paul Daughetee > *Cc:* harfbuzz@lists.freedesktop.org > *Subject:* Re: [HarfBuzz] Question on converting UTF-8 codepoints to > complex glyphs > > > > On Mon, Apr 8, 2019 at 4:12 PM Paul Daughetee > wrote: > > I’m new to HarfBuzz and attempting to use it for converting a UTF-8 string > that contains one or more sets of codepoints that should combine to form > single complex glyphs to the correct string of glyphs. I’ve followed > numerous examples and they all
Re: [HarfBuzz] Question on converting UTF-8 codepoints to complex glyphs
On Mon, Apr 8, 2019 at 4:12 PM Paul Daughetee wrote: > I’m new to HarfBuzz and attempting to use it for converting a UTF-8 string > that contains one or more sets of codepoints that should combine to form > single complex glyphs to the correct string of glyphs. I’ve followed > numerous examples and they all lead me to the point where I use > hb_buffer_get_glyph_infos to get what I thought would be a hb_glyph_info > object that contains the codepoints for the glyphs I seek. So my first > question is as follows. Is that what I should be getting? I ask because I’m > not getting what I would expect to get. > Yes. > I can’t even successfully get a complex glyph to represent the combination > of the letter A and the grave accent. So if I’m just confused as to how or > what HarfBuzz does, please help me find a better path. Thanks! > What do you get? A + grave-accent only forms one glyph if the font was designed so. It may very well be represented by two glyphs. > > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] 2.4.0 tarball reuploaded
The tarball I had uploaded had wrong hb-version.h. Instead of a followup release, I just uploaded a replacement tarball... -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] HarfBuzz now requires C++11
On Fri, Mar 29, 2019 at 3:49 PM Philip Race wrote: > Hi, > > On 3/29/19, 3:06 PM, Behdad Esfahbod wrote: > > Hi, > > I just merged the 'iter' branch [0]. This is a branch I've been working > on for three / four months, and has gathered over 200 commits. It's > finally time to merge it such that the work can continue in master. > > The work there is aimed at GSUB/GPOS subsetting. The constructs I needed > proved to be impossible to achieve without C++11. So that has become > mandatory. I removed gcc 4.2 bots from our continuous-integration as they > were not up to the task. I also disabled the Oracle build bot which was > not happy, > > > Was that using Oracle's Studio compilers on Solaris or on Linux ? > On Linux. I don't have access to Solaris. > If yes to the compiler, which version ? 12u6 ? > Yes. I was hoping that we were using older version. But I checked and it was 12u6. I can reenable and show you the log, or you can just try building yourself. Any help is appreciated. > as well as an ios one. So currently the remaining bots are happy EXCEPT > for MSVC ones. If someone can help debug and make those happy, that would > be great: > > https://ci.appveyor.com/project/harfbuzz/harfbuzz/builds/23465714 > > I'll go ahead and remove the C++<11 compat code. > > > If this is not yet removed, what do you have to be sure you are testing > the C++11 code path ? > This one was really minor: https://github.com/harfbuzz/harfbuzz/commit/1d75db19fb5df139b9648ff3f5e6184a5c554345 That's not the issue. The C++11 features we rely on now cannot be polyfilled... > -phil. > > > Please test with your ancient compilers sooner than later and come up with > a plan forward. It's possible that we may maintain a 2.4 branched just > before this work for a year or two, backporting important fixes to it **if > there is demand for it**. So let us know if you can use that. > > Thanks everyone, > -- > behdad > http://behdad.org/ > > > ___ > HarfBuzz mailing > listHarfBuzz@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/harfbuzz > > -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] HarfBuzz now requires C++11
Hi, I just merged the 'iter' branch [0]. This is a branch I've been working on for three / four months, and has gathered over 200 commits. It's finally time to merge it such that the work can continue in master. The work there is aimed at GSUB/GPOS subsetting. The constructs I needed proved to be impossible to achieve without C++11. So that has become mandatory. I removed gcc 4.2 bots from our continuous-integration as they were not up to the task. I also disabled the Oracle build bot which was not happy, as well as an ios one. So currently the remaining bots are happy EXCEPT for MSVC ones. If someone can help debug and make those happy, that would be great: https://ci.appveyor.com/project/harfbuzz/harfbuzz/builds/23465714 I'll go ahead and remove the C++<11 compat code. Please test with your ancient compilers sooner than later and come up with a plan forward. It's possible that we may maintain a 2.4 branched just before this work for a year or two, backporting important fixes to it **if there is demand for it**. So let us know if you can use that. Thanks everyone, -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Changes to 'refs/tags/2.4.0'
Tag '2.4.0' created by Behdad Esfahbod at 2019-03-29 18:32 + 2.4.0 -BEGIN PGP SIGNATURE- iG8EABECADAWIQQid2UKTovf5Lf2vkGf7gTl01MRFQUCXJ5kuRIcYmVoZGFkQGJl aGRhZC5vcmcACgkQn+4E5dNTERUeugCgo32j9AMg0wvcs5kxbUYCqz8+A6YAlR8Z iL3JT7XnZhktIcmhkRXW4xA= =9kIW -END PGP SIGNATURE- Changes since 2.3.1-114: --- 0 files changed --- ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 3 commits
docs/harfbuzz-docs.xml |1 -
docs/harfbuzz-sections.txt | 10 --
src/hb-common.h|2 +-
src/hb-directwrite.cc | 36 +++-
src/hb-directwrite.h |3 +++
src/hb-subset-input.cc |4 ++--
6 files changed, 45 insertions(+), 11 deletions(-)
New commits:
commit b292772e6ef15728dd66329e637265748df0efe1
Author: Ebrahim Byagowi
Date: Fri Mar 29 13:00:56 2019 -0700
[dwrite] A new API, hb_directwrite_face_get_font_face (#1600)
Can be useful when using HarfBuzz for font loading and shaping
but using DirectWrite for rendering.
diff --git a/docs/harfbuzz-sections.txt b/docs/harfbuzz-sections.txt
index 27dc1e2d..f97902f7 100644
--- a/docs/harfbuzz-sections.txt
+++ b/docs/harfbuzz-sections.txt
@@ -217,6 +217,14 @@ hb_coretext_font_get_ct_font
+hb-directwrite
+hb_directwrite_face_create
+hb_directwrite_face_get_font_face
+
+hb_directwrite_shape_experimental_width
+
+
+
hb-face
hb_face_count
hb_face_t
@@ -715,8 +723,6 @@ hb_unicode_script_func_t
hb-uniscribe
hb_uniscribe_font_get_hfont
hb_uniscribe_font_get_logfontw
-
-hb_directwrite_shape_experimental_width
diff --git a/src/hb-directwrite.cc b/src/hb-directwrite.cc
index cbf04a82..d8076c92 100644
--- a/src/hb-directwrite.cc
+++ b/src/hb-directwrite.cc
@@ -846,10 +846,23 @@ _hb_directwrite_shape (hb_shape_plan_t*shape_plan,
features, num_features, 0);
}
-/*
- * Public [experimental] API
- */
-
+/**
+ * hb_directwrite_shape_experimental_width:
+ * Experimental API to test DirectWrite's justification algorithm.
+ *
+ * It inserts Kashida at wrong order so don't use the API ever.
+ *
+ * It doesn't work with cygwin/msys due to header bugs so one
+ * should use MSVC toolchain in order to use it for now.
+ *
+ * @font:
+ * @buffer:
+ * @features:
+ * @num_features:
+ * @width:
+ *
+ * Since: 1.4.2
+ **/
hb_bool_t
hb_directwrite_shape_experimental_width (hb_font_t *font,
hb_buffer_t*buffer,
@@ -918,6 +931,7 @@ _hb_directwrite_font_release (void *data)
/**
* hb_directwrite_face_create:
* @font_face:
+ *
* Since: 2.4.0
**/
hb_face_t *
@@ -928,3 +942,15 @@ hb_directwrite_face_create (IDWriteFontFace *font_face)
return hb_face_create_for_tables (reference_table, font_face,
_hb_directwrite_font_release);
}
+
+/**
+* hb_directwrite_face_get_font_face:
+* @face:
+*
+* Since: REPLACEME
+**/
+IDWriteFontFace *
+hb_directwrite_face_get_font_face (hb_face_t *face)
+{
+ return face->data.directwrite->fontFace;
+}
diff --git a/src/hb-directwrite.h b/src/hb-directwrite.h
index 09776fd0..de813d06 100644
--- a/src/hb-directwrite.h
+++ b/src/hb-directwrite.h
@@ -37,6 +37,9 @@ hb_directwrite_shape_experimental_width (hb_font_t *font,
hb_buffer_t *buffer,
HB_EXTERN hb_face_t *
hb_directwrite_face_create (IDWriteFontFace *font_face);
+HB_EXTERN IDWriteFontFace *
+hb_directwrite_face_get_font_face (hb_face_t *face);
+
HB_END_DECLS
#endif /* HB_DIRECTWRITE_H */
commit 59f36f36820f6e6fb1d3b6da26d6b5ee7588c42f
Author: Behdad Esfahbod
Date: Fri Mar 29 10:55:12 2019 -0700
Replace REPLACEME's left out of 2.4.0
https://github.com/harfbuzz/harfbuzz/issues/1641
diff --git a/src/hb-common.h b/src/hb-common.h
index fbabd71c..371b2bfc 100644
--- a/src/hb-common.h
+++ b/src/hb-common.h
@@ -358,7 +358,7 @@ typedef enum
/*11.0*/HB_SCRIPT_SOGDIAN= HB_TAG ('S','o','g','d'),
/*
- * Since REPLACEME
+ * Since 2.4.0
*/
/*12.0*/HB_SCRIPT_ELYMAIC= HB_TAG ('E','l','y','m'),
/*12.0*/HB_SCRIPT_NANDINAGARI= HB_TAG
('N','a','n','d'),
diff --git a/src/hb-directwrite.cc b/src/hb-directwrite.cc
index 137cd56c..cbf04a82 100644
--- a/src/hb-directwrite.cc
+++ b/src/hb-directwrite.cc
@@ -918,7 +918,7 @@ _hb_directwrite_font_release (void *data)
/**
* hb_directwrite_face_create:
* @font_face:
- * Since: REPLACEME
+ * Since: 2.4.0
**/
hb_face_t *
hb_directwrite_face_create (IDWriteFontFace *font_face)
diff --git a/src/hb-subset-input.cc b/src/hb-subset-input.cc
index 693c9c21..4d203b54 100644
--- a/src/hb-subset-input.cc
+++ b/src/hb-subset-input.cc
@@ -152,7 +152,7 @@ hb_subset_input_get_desubroutinize (hb_subset_input_t
*subset_input)
* hb_subset_input_set_retain_gids:
* @subset_input: a subset_input.
* @retain_gids: If true the subsetter will not renumber glyph ids.
- * Since: REPLACEME
+ * Since: 2.4.0
**/
HB_EXTERN void
hb_subset_input_set_retain_gids (hb_subset_input_t *subset_input,
@@ -164,7 +164,7 @@ hb_subset_input_set_retain_gids (hb_subset_input_t
*subset_input,
/**
* hb_subset_input_get_retain_gids:
* Returns: value of retain_gids.
- * Since: REPLACEME
+ * Since: 2.4.0
**/
HB_EXTERN hb_bool_t
hb_subset_input_get_retain_gids (hb_subset_input_t *subset_input)
[HarfBuzz] harfbuzz: Changes to 'refs/tags/2.3.0'
Tag '2.3.0' created by Behdad Esfahbod at 2018-12-21 02:49 + 2.3.0 -BEGIN PGP SIGNATURE- iHAEABECADAWIQQid2UKTovf5Lf2vkGf7gTl01MRFQUCXBxUoxIcYmVoZGFkQGJl aGRhZC5vcmcACgkQn+4E5dNTERUwuwCcCf6rDCHJ7FIRVzxNd7sm9/3zATEAn2KC 2uNNl6FInVG1sRQXAb9vN1nl =3zbS -END PGP SIGNATURE- Changes since 2.2.0-387: --- 0 files changed --- ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Changes to 'refs/tags/2.3.1'
Tag '2.3.1' created by Behdad Esfahbod at 2019-01-30 21:54 + 2.3.1 -BEGIN PGP SIGNATURE- iHAEABECADAWIQQid2UKTovf5Lf2vkGf7gTl01MRFQUCXFIdEhIcYmVoZGFkQGJl aGRhZC5vcmcACgkQn+4E5dNTERWgZACgjKwC3n1T3U59VzM2x/sF7hihzTUAnRbN 3sNGcmhY3LsS4YuHgDdxXakD =hTZ5 -END PGP SIGNATURE- Changes since 2.3.0-181: --- 0 files changed --- ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Determine whether font contains a glyph for a sequence of code points
Shape and check the result. On Fri, Feb 15, 2019, 9:24 AM Konstantin Pozin via HarfBuzz < harfbuzz@lists.freedesktop.org> wrote: > What is simplest (and ideally, most performant) way to check whether an > hb_font_t contains a glyph for a sequence of code points? For single code > points, there's hb_font_get_glyph. If you already know the glyph ID (or > glyph name, when the font face has glyph names defined), there's > hb_font_glyph_from_string. > > But what if I want to check whether the face has a single glyph for a > ligature or grapheme cluster, such as "لا", "", or "♀️"? > > Thank you, > Konstantin > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Building and testing HarfBuzz 2.3.0 on MinGW
We should port the test suite runner to C, and test suite to gtest (Google Test) instead of glib. For hb-shape / hb-view, requirements stay the same, and they are hinted at in the configure report. On Sun, Jan 27, 2019 at 4:48 PM Eli Zaretskii wrote: > > From: Ebrahim Byagowi > > Date: Sun, 27 Jan 2019 01:02:01 +0330 > > Cc: Harfbuzz > > > > 1) Agreed > > Btw, one other prerequisite for running the test suite is Python. I > suggest that to be mentioned as well. In my case, Python was not on > PATH, and most tests failed. > > > 2) Something feels wrong as we compile all these in our msys2 CI already > and that shouldn't be that different > > from your setup > > I saw that similar failures were reported here: > > https://github.com/harfbuzz/harfbuzz/issues/1560 > > So I upgraded my Freetype 2.5.0.1 to the latest 2.9.1, and then all > the tests passed. Therefore, I suggest that the oldest version of > Freetype that is considered "good enough" for the test suite be > referenced in the documentation of prerequisites for running the > tests. > > > 3) Uniscribe and DirectWrite backends and now CoreText, are mostly for > comparison while development, so > > developers can check what can be expected behavior while development, > and are not used in the test suit at > > least which tends to be platform agnostic so don't use them at all if > you can. > > Got it, thanks. > ___ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/harfbuzz > -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] C++11
I'm proposing we switch now: https://github.com/harfbuzz/harfbuzz/issues/1509 Shout now, or never. :) -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Cluster question (Was Cluster soap box time)
On Thu, Dec 13, 2018 at 11:05 PM Ansel Sermersheim wrote: > On 11/29/18 7:29 AM, Behdad Esfahbod wrote: > > On Tue, Nov 27, 2018 at 8:34 PM Ansel Sermersheim > wrote: > >> On 11/19/2018 07:16 PM, Behdad Esfahbod wrote: >> >> Hi Ansel, >> >> On Mon, Nov 19, 2018 at 7:44 PM Ansel Sermersheim >> wrote: >> >>> ...We have tried cluster >>> levels 0 and 1, and neither one worked as we expected. In every case, >>> combining accents are marked as being in a separate cluster to the base >>> codepoint. For example, U+0061 Latin Small Letter A followed by U+0308 >>> Combining Diaeresis are being placed in adjacent clusters rather than >>> the same cluster. >> >> >> That doesn't sound right. Are you setting any custom unicode-funcs on >> the buffer? Only thing I can think of that can do this is faulty / missing >> Unicode funcs. >> >> >> We had a feeling something was missing. No, we are not supplying any >> unicode funcs. Do you have a sample or documentation reference for what we >> need to supply? >> > > Not supplying anything is good. Was just ruling out that as a cause. > > >> I have looked at the online documentation without seeing a clear list of >> what is required. We are specifically looking to use harfbuzz to decipher >> special case grapheme breaks. >> > > Can you check with hb-shape command-line tool, to make sure what you > expect is what HarfBuzz produces there? > > Sorry it took a while to get back with you, we really do appreciate your > help. We have been looking over the code and we believe we are having a > problem with missing unicode callback functions. We are compiling HarfBuzz > with the following options turned on: > >-DHAVE_ATEXIT >-DHB_EXTERN= >-DHB_NO_UNICODE_FUNCS >-DHB_NDEBUG > > I am particularly suspicious of the HB_NO_UNICODE_FUNCS define. Am I > correct in thinking that this is suppressing the built-in harfbuzz unicode > functions, so we must supply our own? > Or just use hb-ucdn that is shipped with HarfBuzz. > Thanks so much for your continued help and support, > > -Ansel > -- behdad http://behdad.org/ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
src/hb-aat-fdsc-table.hh|2 +-
src/hb-cff-interp-common.hh |5 +
src/hb-cff2-interp-cs.hh| 14 +-
3 files changed, 15 insertions(+), 6 deletions(-)
New commits:
commit 1abd4fcaec31053b442525d7f240af489c5974b1
Author: Ebrahim Byagowi
Date: Fri Dec 7 22:34:12 2018 +0330
[fdsc] minor
diff --git a/src/hb-aat-fdsc-table.hh b/src/hb-aat-fdsc-table.hh
index d432d7fc..136172c4 100644
--- a/src/hb-aat-fdsc-table.hh
+++ b/src/hb-aat-fdsc-table.hh
@@ -52,7 +52,7 @@ struct GXFontDescriptor
DEFINE_SIZE_STATIC (8);
};
-struct gasp
+struct fdsc
{
enum { tableTag = HB_AAT_TAG_fdsc };
commit 59345cdef38cf1f514a6a0eb6e8852350acb6166
Author: Michiharu Ariza
Date: Thu Dec 6 13:36:26 2018 -0800
[CFF] Refix oss-fuzz 11714: set_blends (PR #1458) (#1460)
* pass subarray of stack to set_blends
* get_subarray to return a value, not ref
* restored error check (with tweak)
diff --git a/src/hb-cff-interp-common.hh b/src/hb-cff-interp-common.hh
index 9b595ff1..effc0812 100644
--- a/src/hb-cff-interp-common.hh
+++ b/src/hb-cff-interp-common.hh
@@ -576,6 +576,11 @@ struct ArgStack : Stack
return true;
}
+ inline hb_array_t get_subarray (unsigned int start) const
+ {
+return S::elements.sub_array (start);
+ }
+
private:
typedef Stack S;
};
diff --git a/src/hb-cff2-interp-cs.hh b/src/hb-cff2-interp-cs.hh
index 18e84680..8e296b6e 100644
--- a/src/hb-cff2-interp-cs.hh
+++ b/src/hb-cff2-interp-cs.hh
@@ -52,7 +52,7 @@ struct BlendArg : Number
inline void set_real (double v) { reset_blends (); Number::set_real (v); }
inline void set_blends (unsigned int numValues_, unsigned int valueIndex_,
- unsigned int numBlends, const BlendArg *blends_)
+ unsigned int numBlends, const hb_array_t _)
{
numValues = numValues_;
valueIndex = valueIndex_;
@@ -235,15 +235,19 @@ struct CFF2CSOpSet : CSOpSet
env.process_blend ();
k = env.get_region_count ();
n = env.argStack.pop_uint ();
-if (unlikely (env.argStack.get_count () < ((k+1) * n)))
+/* copy the blend values into blend array of the default values */
+unsigned int start = env.argStack.get_count () - ((k+1) * n);
+/* let an obvious error case fail, but note CFF2 spec doesn't forbid n==0
*/
+if (unlikely (start > env.argStack.get_count ()))
{
env.set_error ();
return;
}
-/* copy the blend values into blend array of the default values */
-unsigned int start = env.argStack.get_count () - ((k+1) * n);
for (unsigned int i = 0; i < n; i++)
- env.argStack[start + i].set_blends (n, i, k, [start + n +
(i * k)]);
+{
+ const hb_array_t blends = env.argStack.get_subarray
(start + n + (i * k));
+ env.argStack[start + i].set_blends (n, i, k, blends);
+}
/* pop off blend values leaving default values now adorned with blend
values */
env.argStack.pop (k * n);
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 12 commits
src/hb-cff-interp-dict-common.hh
| 51 +++---
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5672006905757696
|binary
2 files changed, 37 insertions(+), 14 deletions(-)
New commits:
commit d9dabc00e9278a346e85538212c126da7e610d55
Merge: 81cfd3c7 010e2ddb
Author: Behdad Esfahbod
Date: Wed Dec 5 15:39:34 2018 -0800
Merge pull request #1454 from harfbuzz/cff-fixbcd
[CFF] fix oss-fuzz issue 11674: parse_bcd
commit 010e2ddb384b5a721172fd7466aafec58dbf8063
Author: Michiharu Ariza
Date: Wed Dec 5 12:23:58 2018 -0800
minimized test case for oss-fuzz issue 11674
diff --git
a/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5672006905757696
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5672006905757696
new file mode 100644
index ..cb5fb83d
Binary files /dev/null and
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5672006905757696
differ
commit 2cb9d4c183afc838ecf2ba0d47814e9eaa6f09c6
Merge: a5fa843c 8394a6cb
Author: Michiharu Ariza
Date: Wed Dec 5 11:25:29 2018 -0800
Merge branch 'master' into cff-fixbcd
commit a5fa843c746e20aaca48ece6cff057deb8d916ca
Author: Michiharu Ariza
Date: Wed Dec 5 11:18:16 2018 -0800
fixed a bug with fractional part in a negative value
diff --git a/src/hb-cff-interp-dict-common.hh b/src/hb-cff-interp-dict-common.hh
index 005e15e6..63ca685e 100644
--- a/src/hb-cff-interp-dict-common.hh
+++ b/src/hb-cff-interp-dict-common.hh
@@ -146,7 +146,11 @@ struct DictOpSet : OpSet
case END:
value = (double)(neg? -int_part: int_part);
if (frac_count > 0)
- value += (frac_part / pow (10.0, (double)frac_count));
+ {
+ double frac = (frac_part / pow (10.0, (double)frac_count));
+ if (neg) frac = -frac;
+ value += frac;
+ }
if (unlikely (exp_overflow))
{
if (value == 0.0)
commit 620d1ef588c6ce25644891cfe4b9c20fd8a9d1db
Author: Michiharu Ariza
Date: Wed Dec 5 00:36:11 2018 -0800
fix unsigned long const
diff --git a/src/hb-cff-interp-dict-common.hh b/src/hb-cff-interp-dict-common.hh
index 2c7a9710..005e15e6 100644
--- a/src/hb-cff-interp-dict-common.hh
+++ b/src/hb-cff-interp-dict-common.hh
@@ -115,7 +115,7 @@ struct DictOpSet : OpSet
boolexp_overflow = false;
enum Part { INT_PART=0, FRAC_PART, EXP_PART } part = INT_PART;
enum Nibble { DECIMAL=10, EXP_POS, EXP_NEG, RESERVED, NEG, END };
-const uint64_t MAX_FRACT = 0xFlu; /* 1^52-1 */
+const uint64_t MAX_FRACT = 0xFllu; /* 1^52-1 */
const uint32_t MAX_EXP = 0x7FFu; /* 1^11-1 */
double value = 0.0;
commit 28dfb4c14280b05ad0a519f9df2b0eda41a62540
Author: Michiharu Ariza
Date: Wed Dec 5 00:26:03 2018 -0800
fix signed/unsigned comparison
diff --git a/src/hb-cff-interp-dict-common.hh b/src/hb-cff-interp-dict-common.hh
index d5376e84..2c7a9710 100644
--- a/src/hb-cff-interp-dict-common.hh
+++ b/src/hb-cff-interp-dict-common.hh
@@ -108,7 +108,7 @@ struct DictOpSet : OpSet
{
boolneg = false;
double int_part = 0;
-int64_t frac_part = 0;
+uint64_t frac_part = 0;
uint32_t frac_count = 0;
boolexp_neg = false;
uint32_t exp_part = 0;
@@ -206,7 +206,7 @@ struct DictOpSet : OpSet
case FRAC_PART:
if (likely ((frac_part <= MAX_FRACT / 10)))
{
- frac_part = (frac_part * 10) + d;
+ frac_part = (frac_part * 10) + (unsigned)d;
frac_count++;
}
break;
commit f9cee08edd32182044407bf6ffde00df0feb09b7
Author: Michiharu Ariza
Date: Tue Dec 4 23:58:26 2018 -0800
use sized int types in parse_bcd
diff --git a/src/hb-cff-interp-dict-common.hh b/src/hb-cff-interp-dict-common.hh
index 0ffd4cec..d5376e84 100644
--- a/src/hb-cff-interp-dict-common.hh
+++ b/src/hb-cff-interp-dict-common.hh
@@ -108,19 +108,19 @@ struct DictOpSet : OpSet
{
boolneg = false;
double int_part = 0;
-longfrac_part = 0;
-unsigned int frac_count = 0;
+int64_t frac_part = 0;
+uint32_t frac_count = 0;
boolexp_neg = false;
-unsigned int exp_part = 0;
+uint32_t exp_part = 0;
boolexp_overflow = false;
enum Part { INT_PART=0, FRAC_PART, EXP_PART } part = INT_PART;
enum Nibble { DECIMAL=10, EXP_POS, EXP_NEG, RESERVED, NEG, END };
-const unsigned long MAX_FRACT = 0xFlu; /* 1^52-1 */
-const unsigned int MAX_EXP = 0x7FFu; /* 1^11-1 */
+const uint64_t MAX_FRACT = 0xFlu; /* 1^52-1 */
+const uint32_t MAX_EXP = 0x7FFu; /* 1^11-1 */
double value = 0.0;
unsigned char byte = 0;
-for (unsigned int i = 0;; i++)
+for (uint32_t i = 0;; i++)
{
char d;
if ((i & 1) == 0)
commit c01a5f32a33fa875de68ca29a4672fd36a052
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
src/hb-cff-interp-common.hh
| 18 --
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5768186323009536
|binary
2 files changed, 16 insertions(+), 2 deletions(-)
New commits:
commit 81cfd3c775dbc470f57d7fe2775cc068ffa367b6
Merge: 8394a6cb 6708c559
Author: Behdad Esfahbod
Date: Wed Dec 5 15:37:15 2018 -0800
Merge pull request #1455 from harfbuzz/cff-strinc_assert
[CFF] fix oss-fuzz issue 11675 (ASSERT: count <= str.len)
commit 6708c5595fc6babdae0132f8a23cbe3558a58703
Author: Michiharu Ariza
Date: Wed Dec 5 12:51:18 2018 -0800
fix oss-fuzz issue 11675 (ASSERT: count <= str.len)
Also added an additional error check to avail ()
diff --git a/src/hb-cff-interp-common.hh b/src/hb-cff-interp-common.hh
index f2ccc2bd..9b595ff1 100644
--- a/src/hb-cff-interp-common.hh
+++ b/src/hb-cff-interp-common.hh
@@ -391,8 +391,22 @@ struct SubByteStr
inline operator ByteStr (void) const { return ByteStr (str, offset, str.len
- offset); }
- inline bool avail (unsigned int count=1) const { return str.check_limit
(offset, count); }
- inline void inc (unsigned int count=1) { offset += count; assert (count <=
str.len); }
+ inline bool avail (unsigned int count=1) const
+ {
+return (!in_error () && str.check_limit (offset, count));
+ }
+ inline void inc (unsigned int count=1)
+ {
+if (likely (!in_error () && (offset <= str.len) && (offset + count <=
str.len)))
+{
+ offset += count;
+}
+else
+{
+ offset = str.len;
+ set_error ();
+}
+ }
inline void set_error (void) { error = true; }
inline bool in_error (void) const { return error; }
diff --git
a/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5768186323009536
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5768186323009536
new file mode 100644
index ..858604d7
Binary files /dev/null and
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5768186323009536
differ
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 16 commits
src/Makefile.sources
|2
src/hb-aat-fdsc-table.hh
| 103 ++
src/hb-aat-layout.cc
|1
src/hb-cff-interp-cs-common.hh
| 22 +-
src/hb-coretext.cc
| 16 -
src/hb-ot-cff-common.hh
|2
src/hb-ot-cff1-table.hh
| 16 -
src/hb-ot-cff2-table.hh
|3
src/hb-ot-gasp-table.hh
| 84
src/hb-ot-layout.cc
|5
src/hb-ot-os2-table.hh
| 88 ++--
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5175735354916864
|binary
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5700264032468992
|binary
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5672913680728064
|binary
14 files changed, 290 insertions(+), 52 deletions(-)
New commits:
commit 8394a6cb252dd8b4230c2b59e8c346ec5403bf88
Author: Ebrahim Byagowi
Date: Wed Dec 5 15:23:41 2018 +0330
[os2] Make newer table fields accessible (#1452)
diff --git a/src/hb-ot-os2-table.hh b/src/hb-ot-os2-table.hh
index e53eda73..46e8b708 100644
--- a/src/hb-ot-os2-table.hh
+++ b/src/hb-ot-os2-table.hh
@@ -30,7 +30,7 @@
#include "hb-open-type.hh"
#include "hb-ot-os2-unicode-ranges.hh"
-namespace OT {
+#include "hb-set.hh"
/*
* OS/2 and Windows Metrics
@@ -38,16 +38,65 @@ namespace OT {
*/
#define HB_OT_TAG_OS2 HB_TAG('O','S','/','2')
-struct OS2
+
+namespace OT {
+
+struct OS2V1Tail
{
- enum { tableTag = HB_OT_TAG_OS2 };
+ inline bool sanitize (hb_sanitize_context_t *c) const
+ {
+TRACE_SANITIZE (this);
+return_trace (c->check_struct (this));
+ }
+
+ public:
+ HBUINT32 ulCodePageRange1;
+ HBUINT32 ulCodePageRange2;
+ public:
+ DEFINE_SIZE_STATIC (8);
+};
+
+struct OS2V2Tail
+{
+ inline bool sanitize (hb_sanitize_context_t *c) const
+ {
+TRACE_SANITIZE (this);
+return_trace (c->check_struct (this));
+ }
+
+ public:
+ HBINT16 sxHeight;
+ HBINT16 sCapHeight;
+ HBUINT16 usDefaultChar;
+ HBUINT16 usBreakChar;
+ HBUINT16 usMaxContext;
+ public:
+ DEFINE_SIZE_STATIC (10);
+};
+struct OS2V5Tail
+{
inline bool sanitize (hb_sanitize_context_t *c) const
{
TRACE_SANITIZE (this);
return_trace (c->check_struct (this));
}
+ public:
+ HBUINT16 usLowerOpticalPointSize;
+ HBUINT16 usUpperOpticalPointSize;
+ public:
+ DEFINE_SIZE_STATIC (4);
+};
+
+struct OS2
+{
+ enum { tableTag = HB_OT_TAG_OS2 };
+
+ inline const OS2V1Tail (void) const { return version >= 1 ? v1X : Null
(OS2V1Tail); }
+ inline const OS2V2Tail (void) const { return version >= 2 ? v2X : Null
(OS2V2Tail); }
+ inline const OS2V5Tail (void) const { return version >= 5 ? v5X : Null
(OS2V5Tail); }
+
inline bool subset (hb_subset_plan_t *plan) const
{
hb_blob_t *os2_blob = hb_sanitize_context_t ().reference_table
(plan->source);
@@ -125,10 +174,18 @@ struct OS2
return (font_page_t) (fsSelection & 0xFF00);
}
+ inline bool sanitize (hb_sanitize_context_t *c) const
+ {
+TRACE_SANITIZE (this);
+if (unlikely (!c->check_struct (this))) return_trace (false);
+if (unlikely (version >= 1 && !v1X.sanitize (c))) return_trace (false);
+if (unlikely (version >= 2 && !v2X.sanitize (c))) return_trace (false);
+if (unlikely (version >= 5 && !v5X.sanitize (c))) return_trace (false);
+return_trace (true);
+ }
+
public:
HBUINT16 version;
-
- /* Version 0 */
HBINT16 xAvgCharWidth;
HBUINT16 usWeightClass;
HBUINT16 usWidthClass;
@@ -155,24 +212,11 @@ struct OS2
HBINT16 sTypoLineGap;
HBUINT16 usWinAscent;
HBUINT16 usWinDescent;
-
- /* Version 1 */
- //HBUINT32 ulCodePageRange1;
- //HBUINT32 ulCodePageRange2;
-
- /* Version 2 */
- //HBINT16sxHeight;
- //HBINT16sCapHeight;
- //HBUINT16 usDefaultChar;
- //HBUINT16 usBreakChar;
- //HBUINT16 usMaxContext;
-
- /* Version 5 */
- //HBUINT16 usLowerOpticalPointSize;
- //HBUINT16 usUpperOpticalPointSize;
-
+ OS2V1Tailv1X;
+ OS2V2Tailv2X;
+ OS2V5Tailv5X;
public:
- DEFINE_SIZE_STATIC (78);
+ DEFINE_SIZE_MIN (78);
};
} /* namespace OT */
commit 5ab086ebb18112ef48bf6c913acc91b2009a9bed
Author: Ebrahim Byagowi
Date: Wed Dec 5 14:17:37 2018 +0330
[fdsc] Implement the table parsing
Related to https://github.com/harfbuzz/harfbuzz/issues/1337
[HarfBuzz] harfbuzz: Branch 'master' - 6 commits
src/hb-cff-interp-common.hh
| 88 +-
src/hb-cff-interp-dict-common.hh
| 10 -
src/hb-cff2-interp-cs.hh
|6
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5647267827023872
|binary
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5725855502827520
|binary
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5736657639178240
|binary
6 files changed, 23 insertions(+), 81 deletions(-)
New commits:
commit c968869f212dbfcb86d42fb36049328521cbf00c
Merge: 8c05b955 c48f53d3
Author: Behdad Esfahbod
Date: Tue Dec 4 04:14:13 2018 -0500
Merge pull request #1441 from harfbuzz/cff-doublenum
use double as CFF Number implementation
commit c48f53d30901dfc20b7432c2947e66642010dc4e
Author: Michiharu Ariza
Date: Mon Dec 3 16:59:41 2018 -0800
more double changes
diff --git a/src/hb-cff2-interp-cs.hh b/src/hb-cff2-interp-cs.hh
index 935a1a1f..d258b814 100644
--- a/src/hb-cff2-interp-cs.hh
+++ b/src/hb-cff2-interp-cs.hh
@@ -49,7 +49,7 @@ struct BlendArg : Number
inline void set_int (int v) { reset_blends (); Number::set_int (v); }
inline void set_fixed (int32_t v) { reset_blends (); Number::set_fixed (v); }
- inline void set_real (float v) { reset_blends (); Number::set_real (v); }
+ inline void set_real (double v) { reset_blends (); Number::set_real (v); }
inline void set_blends (unsigned int numValues_, unsigned int valueIndex_,
unsigned int numBlends, const BlendArg *blends_)
@@ -172,7 +172,7 @@ struct CFF2CSInterpEnv : CSInterpEnv
double v = arg.to_real ();
for (unsigned int i = 0; i < scalars.len; i++)
{
- v += scalars[i] * arg.deltas[i].to_real ();
+ v += (double)scalars[i] * arg.deltas[i].to_real ();
}
arg.set_real (v);
arg.deltas.resize (0);
diff --git a/test/api/test-ot-extents-cff.c b/test/api/test-ot-extents-cff.c
index bb70a626..49b87997 100644
--- a/test/api/test-ot-extents-cff.c
+++ b/test/api/test-ot-extents-cff.c
@@ -171,7 +171,7 @@ test_extents_cff2_vsindex (void)
g_assert_cmpint (extents.x_bearing, ==, 11);
g_assert_cmpint (extents.y_bearing, ==, 656);
g_assert_cmpint (extents.width, ==, 653);
- g_assert_cmpint (extents.height, ==, -657);
+ g_assert_cmpint (extents.height, ==, -656);
result = hb_font_get_glyph_extents (font, 2, );
g_assert (result);
commit 9424e8052686a6a93e0d30e38aecbe927db9d787
Author: Michiharu Ariza
Date: Mon Dec 3 16:18:10 2018 -0800
added minimized test cases
diff --git
a/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5647267827023872
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5647267827023872
new file mode 100644
index ..068e7e8f
Binary files /dev/null and
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5647267827023872
differ
diff --git
a/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5725855502827520
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5725855502827520
new file mode 100644
index ..5781bbad
Binary files /dev/null and
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5725855502827520
differ
diff --git
a/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5736657639178240
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5736657639178240
new file mode 100644
index ..343429cf
Binary files /dev/null and
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5736657639178240
differ
commit 5fff6ab0024547a8ac47723a0047f4b17416d6ce
Author: Michiharu Ariza
Date: Mon Dec 3 16:06:58 2018 -0800
additional precision made a difference in extents test
diff --git a/src/hb-cff-interp-common.hh b/src/hb-cff-interp-common.hh
index 396bc8c7..f2ccc2bd 100644
--- a/src/hb-cff-interp-common.hh
+++ b/src/hb-cff-interp-common.hh
@@ -229,7 +229,7 @@ struct Number
{
return (int32_t)(value * 65536.0);
}
- inline void set_real (double v) { value = (double)v; }
+ inline void set_real (double v) { value = v; }
inline double to_real (void) const
{
return value;
diff --git a/src/hb-cff2-interp-cs.hh b/src/hb-cff2-interp-cs.hh
index 8d193d62..935a1a1f 100644
--- a/src/hb-cff2-interp-cs.hh
+++ b/src/hb-cff2-interp-cs.hh
@@ -169,7 +169,7 @@ struct CFF2CSInterpEnv : CSInterpEnv
{
if (likely (scalars.len == arg.deltas.len))
{
- float v = arg.to_real ();
+ double v = arg.to_real ();
for (unsigned int i = 0; i < scalars.len; i++)
{
v += scalars[i] * arg.deltas[i].to_real ();
diff --git a/test/api/test-ot-extents-cff.c b/test/api/test-ot-extents-cff.c
index 49b87997..bb70a626 100644
--- a/test/api/test-ot-extents
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
docs/harfbuzz-sections.txt |7 ---
src/hb-aat-layout.cc|9 -
src/hb-aat-layout.h |8
src/hb-aat-layout.hh|3 ---
test/api/fonts/aat-morx.ttf |binary
test/api/fonts/aat-trak.ttf |binary
test/api/test-aat-layout.c | 13 +
7 files changed, 33 insertions(+), 7 deletions(-)
New commits:
commit 8c05b955eb4aa088b2b5df9b6415863486eaf59c
Merge: d19b1680 01f628cf
Author: Behdad Esfahbod
Date: Mon Dec 3 14:30:51 2018 -0500
Merge pull request #1439 from ebraminio/tracking
[aat] Expose hb_aat_layout_has_tracking API
commit 01f628cf5571b8b58108ab66cfc3e929c9840e31
Author: Ebrahim Byagowi
Date: Mon Dec 3 22:04:48 2018 +0330
[aat] Expose hb_aat_layout_has_tracking API
diff --git a/docs/harfbuzz-sections.txt b/docs/harfbuzz-sections.txt
index 63224317..fd7682ef 100644
--- a/docs/harfbuzz-sections.txt
+++ b/docs/harfbuzz-sections.txt
@@ -7,13 +7,14 @@ HB_OT_H_IN
hb-aat-layout
HB_AAT_LAYOUT_NO_SELECTOR_INDEX
hb_aat_layout_feature_type_t
-hb_aat_layout_get_feature_types
-hb_aat_layout_feature_type_get_name_id
hb_aat_layout_feature_selector_t
hb_aat_layout_feature_selector_info_t
+hb_aat_layout_feature_type_get_name_id
hb_aat_layout_feature_type_get_selector_infos
-hb_aat_layout_has_substitution
+hb_aat_layout_get_feature_types
hb_aat_layout_has_positioning
+hb_aat_layout_has_substitution
+hb_aat_layout_has_tracking
diff --git a/src/hb-aat-layout.cc b/src/hb-aat-layout.cc
index 837dcbae..e39df0e1 100644
--- a/src/hb-aat-layout.cc
+++ b/src/hb-aat-layout.cc
@@ -296,7 +296,14 @@ hb_aat_layout_position (const hb_ot_shape_plan_t *plan,
}
-bool
+/*
+ * hb_aat_layout_has_tracking:
+ * @face:
+ *
+ * Returns:
+ * Since: REPLACEME
+ */
+hb_bool_t
hb_aat_layout_has_tracking (hb_face_t *face)
{
return face->table.trak->has_data ();
diff --git a/src/hb-aat-layout.h b/src/hb-aat-layout.h
index f5745096..760aaae4 100644
--- a/src/hb-aat-layout.h
+++ b/src/hb-aat-layout.h
@@ -473,6 +473,14 @@ HB_EXTERN hb_bool_t
hb_aat_layout_has_positioning (hb_face_t *face);
+/*
+ * trak
+ */
+
+HB_EXTERN hb_bool_t
+hb_aat_layout_has_tracking (hb_face_t *face);
+
+
HB_END_DECLS
#endif /* HB_AAT_LAYOUT_H */
diff --git a/src/hb-aat-layout.hh b/src/hb-aat-layout.hh
index cbb94546..56a4818b 100644
--- a/src/hb-aat-layout.hh
+++ b/src/hb-aat-layout.hh
@@ -72,9 +72,6 @@ hb_aat_layout_position (const hb_ot_shape_plan_t *plan,
hb_font_t *font,
hb_buffer_t *buffer);
-HB_INTERNAL bool
-hb_aat_layout_has_tracking (hb_face_t *face);
-
HB_INTERNAL void
hb_aat_layout_track (const hb_ot_shape_plan_t *plan,
hb_font_t *font,
diff --git a/test/api/fonts/aat-morx.ttf b/test/api/fonts/aat-morx.ttf
new file mode 100644
index ..5827ec5a
Binary files /dev/null and b/test/api/fonts/aat-morx.ttf differ
diff --git a/test/api/fonts/aat-trak.ttf b/test/api/fonts/aat-trak.ttf
new file mode 100644
index ..07ae3afd
Binary files /dev/null and b/test/api/fonts/aat-trak.ttf differ
diff --git a/test/api/test-aat-layout.c b/test/api/test-aat-layout.c
index 358fac87..8cfebb13 100644
--- a/test/api/test-aat-layout.c
+++ b/test/api/test-aat-layout.c
@@ -101,6 +101,18 @@ test_aat_get_feature_selectors (void)
g_assert_cmpuint (0, ==, count);
}
+static void
+test_aat_has (void)
+{
+ hb_face_t *morx = hb_test_open_font_file ("fonts/aat-morx.ttf");
+ g_assert (hb_aat_layout_has_substitution (morx));
+ hb_face_destroy (morx);
+
+ hb_face_t *trak = hb_test_open_font_file ("fonts/aat-trak.ttf");
+ g_assert (hb_aat_layout_has_tracking (trak));
+ hb_face_destroy (trak);
+}
+
int
main (int argc, char **argv)
{
@@ -108,6 +120,7 @@ main (int argc, char **argv)
hb_test_add (test_aat_get_feature_types);
hb_test_add (test_aat_get_feature_selectors);
+ hb_test_add (test_aat_has);
face = hb_test_open_font_file ("fonts/aat-feat.ttf");
sbix = hb_test_open_font_file ("fonts/chromacheck-sbix.ttf");
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
docs/harfbuzz-sections.txt |2 ++
src/hb-aat-layout.cc | 20
src/hb-aat-layout.h| 16
src/hb-aat-layout.hh |6 --
4 files changed, 34 insertions(+), 10 deletions(-)
New commits:
commit d19b1680b53e54f449736432f369a676c394ebf8
Author: Behdad Esfahbod
Date: Mon Dec 3 10:41:37 2018 -0500
[aat] Expose a couple APIs
New API:
+hb_aat_layout_has_substitution()
+hb_aat_layout_has_positioning()
diff --git a/docs/harfbuzz-sections.txt b/docs/harfbuzz-sections.txt
index 5c45153c..63224317 100644
--- a/docs/harfbuzz-sections.txt
+++ b/docs/harfbuzz-sections.txt
@@ -12,6 +12,8 @@ hb_aat_layout_feature_type_get_name_id
hb_aat_layout_feature_selector_t
hb_aat_layout_feature_selector_info_t
hb_aat_layout_feature_type_get_selector_infos
+hb_aat_layout_has_substitution
+hb_aat_layout_has_positioning
diff --git a/src/hb-aat-layout.cc b/src/hb-aat-layout.cc
index fae67800..837dcbae 100644
--- a/src/hb-aat-layout.cc
+++ b/src/hb-aat-layout.cc
@@ -205,7 +205,14 @@ hb_aat_layout_compile_map (const hb_aat_map_builder_t
*mapper,
}
-bool
+/*
+ * hb_aat_layout_has_substitution:
+ * @face:
+ *
+ * Returns:
+ * Since: REPLACEME
+ */
+hb_bool_t
hb_aat_layout_has_substitution (hb_face_t *face)
{
return face->table.morx->has_data () ||
@@ -259,9 +266,14 @@ hb_aat_layout_remove_deleted_glyphs (hb_buffer_t *buffer)
hb_ot_layout_delete_glyphs_inplace (buffer, is_deleted_glyph);
}
-
-
-bool
+/*
+ * hb_aat_layout_has_positioning:
+ * @face:
+ *
+ * Returns:
+ * Since: REPLACEME
+ */
+hb_bool_t
hb_aat_layout_has_positioning (hb_face_t *face)
{
return face->table.kerx->has_data ();
diff --git a/src/hb-aat-layout.h b/src/hb-aat-layout.h
index 696e9033..f5745096 100644
--- a/src/hb-aat-layout.h
+++ b/src/hb-aat-layout.h
@@ -457,6 +457,22 @@ hb_aat_layout_feature_type_get_selector_infos (hb_face_t
unsigned int
*default_index /* OUT. May be NULL. */);
+/*
+ * morx/mort
+ */
+
+HB_EXTERN hb_bool_t
+hb_aat_layout_has_substitution (hb_face_t *face);
+
+
+/*
+ * kerx
+ */
+
+HB_EXTERN hb_bool_t
+hb_aat_layout_has_positioning (hb_face_t *face);
+
+
HB_END_DECLS
#endif /* HB_AAT_LAYOUT_H */
diff --git a/src/hb-aat-layout.hh b/src/hb-aat-layout.hh
index 5fd47ed6..cbb94546 100644
--- a/src/hb-aat-layout.hh
+++ b/src/hb-aat-layout.hh
@@ -56,9 +56,6 @@ HB_INTERNAL void
hb_aat_layout_compile_map (const hb_aat_map_builder_t *mapper,
hb_aat_map_t *map);
-HB_INTERNAL bool
-hb_aat_layout_has_substitution (hb_face_t *face);
-
HB_INTERNAL void
hb_aat_layout_substitute (const hb_ot_shape_plan_t *plan,
hb_font_t *font,
@@ -70,9 +67,6 @@ hb_aat_layout_zero_width_deleted_glyphs (hb_buffer_t *buffer);
HB_INTERNAL void
hb_aat_layout_remove_deleted_glyphs (hb_buffer_t *buffer);
-HB_INTERNAL bool
-hb_aat_layout_has_positioning (hb_face_t *face);
-
HB_INTERNAL void
hb_aat_layout_position (const hb_ot_shape_plan_t *plan,
hb_font_t *font,
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-aat-layout-common.hh
|2 +-
test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5768046065483776
|binary
2 files changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 84efe0438e1cfc5b070e114b70e8c070be6119ca
Author: Behdad Esfahbod
Date: Sun Dec 2 12:38:53 2018 -0500
[aat] Fix division sign fallout
Happened after 11d2f49af8f53340134c844173f4d8655b00dea3
since now nClasses is unsigned int...
diff --git a/src/hb-aat-layout-common.hh b/src/hb-aat-layout-common.hh
index 588dbdf2..57228c41 100644
--- a/src/hb-aat-layout-common.hh
+++ b/src/hb-aat-layout-common.hh
@@ -504,7 +504,7 @@ struct StateTable
};
inline int new_state (unsigned int newState) const
- { return Types::extended ? newState : ((int) newState - (int)
stateArrayTable) / nClasses; }
+ { return Types::extended ? newState : ((int) newState - (int)
stateArrayTable) / (int) nClasses; }
inline unsigned int get_class (hb_codepoint_t glyph_id, unsigned int
num_glyphs) const
{
diff --git
a/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5768046065483776
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5768046065483776
new file mode 100644
index ..0ab14470
Binary files /dev/null and
b/test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-shape-fuzzer-5768046065483776
differ
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-open-type.hh | 13 ++---
src/hb-vector.hh|2 ++
2 files changed, 12 insertions(+), 3 deletions(-)
New commits:
commit 2087f5a2a743380b36399ba8a2b4ff9e93890fcf
Author: Behdad Esfahbod
Date: Sat Dec 1 20:04:45 2018 -0500
Add casts to hb_array_t<>
diff --git a/src/hb-open-type.hh b/src/hb-open-type.hh
index 0038ad8b..69cc5ccf 100644
--- a/src/hb-open-type.hh
+++ b/src/hb-open-type.hh
@@ -374,16 +374,17 @@ struct UnsizedArrayOf
return *p;
}
- template inline operator T * (void) { return arrayZ; }
- template inline operator const T * (void) const { return
arrayZ; }
-
inline unsigned int get_size (unsigned int len) const
{ return len * Type::static_size; }
+ template inline operator T * (void) { return arrayZ; }
+ template inline operator const T * (void) const { return
arrayZ; }
inline hb_array_t as_array (unsigned int len)
{ return hb_array (arrayZ, len); }
inline hb_array_t as_array (unsigned int len) const
{ return hb_array (arrayZ, len); }
+ inline operator hb_array_t (void) { return as_array (); }
+ inline operator hb_array_t (void) const { as_array (); }
template
inline Type (unsigned int len, const T , Type _found = Crap
(Type))
@@ -488,6 +489,8 @@ struct SortedUnsizedArrayOf : UnsizedArrayOf
{ return hb_sorted_array (this->arrayZ, len); }
inline hb_sorted_array_t as_array (unsigned int len) const
{ return hb_sorted_array (this->arrayZ, len); }
+ inline operator hb_sorted_array_t (void) { return as_array (); }
+ inline operator hb_sorted_array_t (void) const { as_array (); }
template
inline Type (unsigned int len, const T , Type _found = Crap
(Type))
@@ -533,6 +536,8 @@ struct ArrayOf
{ return hb_array (arrayZ, len); }
inline hb_array_t as_array (void) const
{ return hb_array (arrayZ, len); }
+ inline operator hb_array_t (void) { return as_array (); }
+ inline operator hb_array_t (void) const { as_array (); }
inline hb_array_t sub_array (unsigned int start_offset, unsigned
int count) const
{ return as_array ().sub_array (start_offset, count);}
@@ -802,6 +807,8 @@ struct SortedArrayOf : ArrayOf
{ return hb_sorted_array (this->arrayZ, this->len); }
inline hb_sorted_array_t as_array (void) const
{ return hb_sorted_array (this->arrayZ, this->len); }
+ inline operator hb_sorted_array_t (void) { return as_array (); }
+ inline operator hb_sorted_array_t (void) const { as_array (); }
inline hb_array_t sub_array (unsigned int start_offset, unsigned
int count) const
{ return as_array ().sub_array (start_offset, count);}
diff --git a/src/hb-vector.hh b/src/hb-vector.hh
index 953a776e..4b34a381 100644
--- a/src/hb-vector.hh
+++ b/src/hb-vector.hh
@@ -105,6 +105,8 @@ struct hb_vector_t
template explicit_operator inline operator T * (void) { return
arrayZ(); }
template explicit_operator inline operator const T * (void)
const { return arrayZ(); }
+ inline operator hb_array_t (void) { return as_array (); }
+ inline operator hb_array_t (void) const { as_array (); }
inline Type * operator + (unsigned int i) { return arrayZ() + i; }
inline const Type * operator + (unsigned int i) const { return arrayZ() +
i; }
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
CMakeLists.txt| 12 --
src/Makefile.am |6 -
src/Makefile.sources | 231 +-
test/api/hb-subset-test.h |2
4 files changed, 112 insertions(+), 139 deletions(-)
New commits:
commit 58d4d19947794aded4e966290b01e1034f216a7d
Author: Behdad Esfahbod
Date: Sat Dec 1 19:34:18 2018 -0500
Simplify build source list
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 019e205b..2d6e77e8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -168,10 +168,6 @@ extract_make_variable(HB_BASE_headers ${SRCSOURCES})
add_prefix_to_list(HB_BASE_headers "${PROJECT_SOURCE_DIR}/src/")
extract_make_variable(HB_FALLBACK_sources ${SRCSOURCES})
add_prefix_to_list(HB_FALLBACK_sources "${PROJECT_SOURCE_DIR}/src/")
-extract_make_variable(HB_OT_sources ${SRCSOURCES})
-add_prefix_to_list(HB_OT_sources "${PROJECT_SOURCE_DIR}/src/")
-extract_make_variable(HB_OT_headers ${SRCSOURCES})
-add_prefix_to_list(HB_OT_headers "${PROJECT_SOURCE_DIR}/src/")
extract_make_variable(HB_SUBSET_sources ${SRCSOURCES})
add_prefix_to_list(HB_SUBSET_sources "${PROJECT_SOURCE_DIR}/src/")
@@ -180,13 +176,10 @@ extract_make_variable(HB_SUBSET_headers ${SRCSOURCES})
add_prefix_to_list(HB_SUBSET_headers "${PROJECT_SOURCE_DIR}/src/")
extract_make_variable(HB_BASE_RAGEL_GENERATED_sources ${SRCSOURCES})
-extract_make_variable(HB_OT_RAGEL_GENERATED_sources ${SRCSOURCES})
#if (IN_HB_DIST)
add_prefix_to_list(HB_BASE_RAGEL_GENERATED_sources
"${PROJECT_SOURCE_DIR}/src/")
- add_prefix_to_list(HB_OT_RAGEL_GENERATED_sources
"${PROJECT_SOURCE_DIR}/src/")
#else ()
# add_prefix_to_list(HB_BASE_RAGEL_GENERATED_sources
"${PROJECT_BINARY_DIR}/src/")
-# add_prefix_to_list(HB_OT_RAGEL_GENERATED_sources
"${PROJECT_BINARY_DIR}/src/")
#endif ()
extract_make_variable(HB_VIEW_sources ${UTILSOURCES})
@@ -212,7 +205,7 @@ set (HB_VERSION_MICRO ${CMAKE_MATCH_4})
## Define ragel tasks
# if (NOT IN_HB_DIST)
-# foreach (ragel_output IN ITEMS ${HB_BASE_RAGEL_GENERATED_sources}
${HB_OT_RAGEL_GENERATED_sources})
+# foreach (ragel_output IN ITEMS ${HB_BASE_RAGEL_GENERATED_sources})
#string(REGEX MATCH "([^/]+)\\.hh" temp ${ragel_output})
#set (target_name ${CMAKE_MATCH_1})
#add_custom_command(OUTPUT ${ragel_output}
@@ -246,8 +239,6 @@ set (project_sources
${HB_BASE_RAGEL_GENERATED_sources}
${HB_FALLBACK_sources}
- ${HB_OT_sources}
- ${HB_OT_RAGEL_GENERATED_sources}
)
set (subset_project_sources
@@ -260,7 +251,6 @@ set (project_headers
#${HB_VERSION_H}
${HB_BASE_headers}
- ${HB_OT_headers}
)
set (subset_project_headers
diff --git a/src/Makefile.am b/src/Makefile.am
index c726cf2a..3618d03a 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -28,10 +28,6 @@ HBSOURCES = $(HB_BASE_sources)
HBSOURCES += $(HB_BASE_RAGEL_GENERATED_sources)
HBHEADERS = $(HB_BASE_headers)
-HBSOURCES += $(HB_OT_sources)
-HBSOURCES += $(HB_OT_RAGEL_GENERATED_sources)
-HBHEADERS += $(HB_OT_headers)
-
if HAVE_FALLBACK
HBSOURCES += $(HB_FALLBACK_sources)
endif
@@ -299,12 +295,10 @@ built-sources: $(BUILT_SOURCES)
RAGEL_GENERATED = \
$(patsubst %,$(srcdir)/%,$(HB_BASE_RAGEL_GENERATED_sources)) \
- $(patsubst %,$(srcdir)/%,$(HB_OT_RAGEL_GENERATED_sources)) \
$(NULL)
BUILT_SOURCES += $(RAGEL_GENERATED)
EXTRA_DIST += \
$(HB_BASE_RAGEL_sources) \
- $(HB_OT_RAGEL_sources) \
$(NULL)
# We decided to add ragel-generated files to git...
#MAINTAINERCLEANFILES += $(RAGEL_GENERATED)
diff --git a/src/Makefile.sources b/src/Makefile.sources
index 5484764c..e12d3b55 100644
--- a/src/Makefile.sources
+++ b/src/Makefile.sources
@@ -1,199 +1,177 @@
# Base and default-included sources and headers
HB_BASE_sources = \
+ hb-aat-layout-ankr-table.hh \
+ hb-aat-layout-bsln-table.hh \
+ hb-aat-layout-common.hh \
+ hb-aat-layout-feat-table.hh \
+ hb-aat-layout-just-table.hh \
+ hb-aat-layout-kerx-table.hh \
+ hb-aat-layout-lcar-table.hh \
+ hb-aat-layout-morx-table.hh \
+ hb-aat-layout-trak-table.hh \
+ hb-aat-layout.cc \
+ hb-aat-layout.hh \
+ hb-aat-ltag-table.hh \
+ hb-aat-map.cc \
+ hb-aat-map.hh \
hb-atomic.hh \
- hb-blob.hh \
hb-blob.cc \
- hb-buffer.hh \
+ hb-blob.hh \
hb-buffer-serialize.cc \
hb-buffer.cc \
+ hb-buffer.hh \
hb-cache.hh \
+ hb-cff-interp-common.hh \
+ hb-cff-interp-cs-common.hh \
+ hb-cff-interp-dict-common.hh \
+ hb-cff1-interp-cs.hh \
+ hb-cff2-interp-cs.hh \
hb-common.cc \
hb-debug.hh \
hb-dsalgs.hh \
- hb-face.hh \
hb-face.cc \
- hb-font.hh \
+ hb-face.hh \
hb-font.cc \
+ hb-font.hh \
hb-iter.hh \
hb-kern.hh \
- hb-map.hh \
-
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
src/hb-dsalgs.hh| 16 ++--
src/hb-open-type.hh | 12 ++--
2 files changed, 20 insertions(+), 8 deletions(-)
New commits:
commit 11d2f49af8f53340134c844173f4d8655b00dea3
Author: Behdad Esfahbod
Date: Sat Dec 1 13:12:21 2018 -0500
New approach to change BigEndian casts to be int-sized
Fixes spurious warnings like:
Fixes https://github.com/harfbuzz/harfbuzz/issues/1436
diff --git a/src/hb-open-type.hh b/src/hb-open-type.hh
index ee76d7ed..0038ad8b 100644
--- a/src/hb-open-type.hh
+++ b/src/hb-open-type.hh
@@ -52,13 +52,19 @@ namespace OT {
* Int types
*/
+template struct hb_signedness_int;
+template <> struct hb_signedness_int { typedef unsigned int value; };
+template <> struct hb_signedness_int { typedef signed int value; };
+
/* Integer types in big-endian order and no alignment requirement */
template
struct IntType
{
typedef Type type;
- inline void set (Type i) { v.set (i); }
- inline operator Type (void) const { return v; }
+ typedef typename hb_signedness_int::value>::value
wide_type;
+
+ inline void set (wide_type i) { v.set (i); }
+ inline operator wide_type (void) const { return v; }
inline bool operator == (const IntType ) const { return (Type)
v == (Type) o.v; }
inline bool operator != (const IntType ) const { return !(*this
== o); }
static inline int cmp (const IntType *a, const IntType
*b) { return b->cmp (*a); }
@@ -88,6 +94,8 @@ typedef IntType HBUINT16;/* 16-bit
unsigned integer. */
typedef IntType HBINT16; /* 16-bit signed integer. */
typedef IntType HBUINT32; /* 32-bit unsigned integer. */
typedef IntType HBINT32; /* 32-bit signed integer. */
+/* Note: we cannot defined a signed HBINT24 because there's no corresponding C
type.
+ * Works for unsigned, but not signed, since we rely on compiler for
sign-extension. */
typedef IntType HBUINT24; /* 24-bit unsigned integer. */
/* 16-bit signed integer (HBINT16) that describes a quantity in FUnits. */
commit 50e0273ab18acd2fbb21bcf18ad487092e890b4e
Author: Behdad Esfahbod
Date: Sat Dec 1 13:03:52 2018 -0500
Change hb_assert_unsigned_t<> to hb_is_signed<>
diff --git a/src/hb-dsalgs.hh b/src/hb-dsalgs.hh
index 9c920fc8..dccca3cf 100644
--- a/src/hb-dsalgs.hh
+++ b/src/hb-dsalgs.hh
@@ -287,11 +287,15 @@ hb_ceil_to_4 (unsigned int v)
return ((v - 1) | 3) + 1;
}
-template class hb_assert_unsigned_t;
-template <> class hb_assert_unsigned_t {};
-template <> class hb_assert_unsigned_t {};
-template <> class hb_assert_unsigned_t {};
-template <> class hb_assert_unsigned_t {};
+template struct hb_is_signed;
+template <> struct hb_is_signed { enum { value = true }; };
+template <> struct hb_is_signed { enum { value = true }; };
+template <> struct hb_is_signed { enum { value = true }; };
+template <> struct hb_is_signed { enum { value = true }; };
+template <> struct hb_is_signed { enum { value = false }; };
+template <> struct hb_is_signed { enum { value = false }; };
+template <> struct hb_is_signed { enum { value = false }; };
+template <> struct hb_is_signed { enum { value = false }; };
template static inline bool
hb_in_range (T u, T lo, T hi)
@@ -301,7 +305,7 @@ hb_in_range (T u, T lo, T hi)
* one right now. Declaring a variable won't work as HB_UNUSED
* is unusable on some platforms and unused types are less likely
* to generate a warning than unused variables. */
- static_assert ((sizeof (hb_assert_unsigned_t) >= 0), "");
+ static_assert (!hb_is_signed::value, "");
/* The casts below are important as if T is smaller than int,
* the subtract results will become a signed int! */
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-open-type.hh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
New commits:
commit c3a8b047aab47e40dc107a952b3a1472068ec932
Author: Behdad Esfahbod
Date: Sat Dec 1 00:14:48 2018 -0500
Revert "Change BigEndian casts to be int-sized"
This reverts commit eb5ddd32bf4e458ca0af8d5784f8fd46485ad225.
Broke tests, badly. To be investigated and reenabled.
diff --git a/src/hb-open-type.hh b/src/hb-open-type.hh
index 99a1c9b9..ee76d7ed 100644
--- a/src/hb-open-type.hh
+++ b/src/hb-open-type.hh
@@ -66,7 +66,7 @@ struct IntType
inline int cmp (Type2 a) const
{
Type b = v;
-if (Size < sizeof (int) && sizeof (Type2) < sizeof (int))
+if (sizeof (Type) < sizeof (int) && sizeof (Type2) < sizeof (int))
return (int) a - (int) b;
else
return a < b ? -1 : a == b ? 0 : +1;
@@ -82,13 +82,13 @@ struct IntType
DEFINE_SIZE_STATIC (Size);
};
-typedef IntType HBUINT8; /* 8-bit unsigned integer. */
-typedef IntType< signed, 1> HBINT8; /* 8-bit signed integer. */
-typedef IntType HBUINT16; /* 16-bit unsigned integer. */
-typedef IntType< signed, 2> HBINT16; /* 16-bit signed integer. */
-typedef IntType HBUINT24; /* 24-bit unsigned integer. */
-typedef IntType HBUINT32; /* 32-bit unsigned integer. */
-typedef IntType< signed, 4> HBINT32; /* 32-bit signed integer. */
+typedef IntType HBUINT8; /* 8-bit unsigned integer. */
+typedef IntType HBINT8; /* 8-bit signed integer. */
+typedef IntType HBUINT16; /* 16-bit unsigned integer. */
+typedef IntType HBINT16; /* 16-bit signed integer. */
+typedef IntType HBUINT32; /* 32-bit unsigned integer. */
+typedef IntType HBINT32; /* 32-bit signed integer. */
+typedef IntType HBUINT24; /* 24-bit unsigned integer. */
/* 16-bit signed integer (HBINT16) that describes a quantity in FUnits. */
typedef HBINT16 FWORD;
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-layout-gsub-table.hh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit be45677ab605efc711a433323d66e4051c289252
Author: Behdad Esfahbod
Date: Sat Dec 1 00:04:29 2018 -0500
Minor
diff --git a/src/hb-ot-layout-gsub-table.hh b/src/hb-ot-layout-gsub-table.hh
index 6acdcf2f..73a852f0 100644
--- a/src/hb-ot-layout-gsub-table.hh
+++ b/src/hb-ot-layout-gsub-table.hh
@@ -270,7 +270,7 @@ struct SingleSubst
/* TODO(serialize) check for wrap-around */
delta = substitutes[0] - glyphs[0];
for (unsigned int i = 1; i < num_glyphs; i++)
- if (delta != substitutes[i] - glyphs[i]) {
+ if (delta != (int) (substitutes[i] - glyphs[i])) {
format = 2;
break;
}
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-open-type.hh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
New commits:
commit eb5ddd32bf4e458ca0af8d5784f8fd46485ad225
Author: Behdad Esfahbod
Date: Sat Dec 1 00:03:01 2018 -0500
Change BigEndian casts to be int-sized
Fixes spurious warnings like:
Fixes https://github.com/harfbuzz/harfbuzz/issues/1436
diff --git a/src/hb-open-type.hh b/src/hb-open-type.hh
index ee76d7ed..99a1c9b9 100644
--- a/src/hb-open-type.hh
+++ b/src/hb-open-type.hh
@@ -66,7 +66,7 @@ struct IntType
inline int cmp (Type2 a) const
{
Type b = v;
-if (sizeof (Type) < sizeof (int) && sizeof (Type2) < sizeof (int))
+if (Size < sizeof (int) && sizeof (Type2) < sizeof (int))
return (int) a - (int) b;
else
return a < b ? -1 : a == b ? 0 : +1;
@@ -82,13 +82,13 @@ struct IntType
DEFINE_SIZE_STATIC (Size);
};
-typedef IntType HBUINT8; /* 8-bit unsigned integer. */
-typedef IntType HBINT8; /* 8-bit signed integer. */
-typedef IntType HBUINT16; /* 16-bit unsigned integer. */
-typedef IntType HBINT16; /* 16-bit signed integer. */
-typedef IntType HBUINT32; /* 32-bit unsigned integer. */
-typedef IntType HBINT32; /* 32-bit signed integer. */
-typedef IntType HBUINT24; /* 24-bit unsigned integer. */
+typedef IntType HBUINT8; /* 8-bit unsigned integer. */
+typedef IntType< signed, 1> HBINT8; /* 8-bit signed integer. */
+typedef IntType HBUINT16; /* 16-bit unsigned integer. */
+typedef IntType< signed, 2> HBINT16; /* 16-bit signed integer. */
+typedef IntType HBUINT24; /* 24-bit unsigned integer. */
+typedef IntType HBUINT32; /* 32-bit unsigned integer. */
+typedef IntType< signed, 4> HBINT32; /* 32-bit signed integer. */
/* 16-bit signed integer (HBINT16) that describes a quantity in FUnits. */
typedef HBINT16 FWORD;
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-cff-common.hh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit e8860fdcaa69e3452edd903f78599bc8fa9d109c
Author: Behdad Esfahbod
Date: Fri Nov 30 23:38:24 2018 -0500
Fix more warning
diff --git a/src/hb-ot-cff-common.hh b/src/hb-ot-cff-common.hh
index a83435d4..e824dae3 100644
--- a/src/hb-ot-cff-common.hh
+++ b/src/hb-ot-cff-common.hh
@@ -233,7 +233,7 @@ struct CFFIndex
inline unsigned int max_offset (void) const
{
unsigned int max = 0;
-for (unsigned int i = 0; i < count + 1; i++)
+for (unsigned int i = 0; i < count + 1u; i++)
{
unsigned int off = offset_at (i);
if (off > max) max = off;
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Changes to 'overload-overload'
New branch 'overload-overload' available with the following commits: commit db56d481cdfe848240d0f009656d290cf7e63d14 Author: Behdad Esfahbod Date: Fri Nov 30 19:49:03 2018 -0500 Another approach to fixing pesky-gcc's ambiguous overload overload commit 51977fb38f73ea3ef9ae436353208de828ec6141 Author: Behdad Esfahbod Date: Fri Nov 30 19:47:11 2018 -0500 Break pesky-gcc build ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-color-cpal-table.hh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit fedd8e6c176dea85194693399e50243eb1c117c4
Author: Behdad Esfahbod
Date: Fri Nov 30 16:50:30 2018 -0500
One more.
I wonder if there's something better to do about these :(.
In file included from hb-ot-color.cc:31:
hb-ot-color-cpal-table.hh: In member function 'unsigned int
OT::CPAL::get_size() const':
hb-ot-color-cpal-table.hh:118: error: ISO C++ says that these are
ambiguous, even though the worst conversion for the first is better than the
worst conversion for the second:
diff --git a/src/hb-ot-color-cpal-table.hh b/src/hb-ot-color-cpal-table.hh
index 095f96f2..85bdc7ef 100644
--- a/src/hb-ot-color-cpal-table.hh
+++ b/src/hb-ot-color-cpal-table.hh
@@ -115,7 +115,7 @@ struct CPAL
inline bool has_data (void) const { return numPalettes; }
inline unsigned int get_size (void) const
- { return min_size + numPalettes * sizeof (colorRecordIndicesZ[0]); }
+ { return min_size + numPalettes * sizeof (colorRecordIndicesZ[0u]); }
inline unsigned int get_palette_count () const { return numPalettes; }
inline unsigned int get_color_count () const { return numColors; }
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-vorg-table.hh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit bc5db9b0807767ac04d6e50070d69cb9c520f06e Author: Behdad Esfahbod Date: Fri Nov 30 16:04:52 2018 -0500 One more hb-ot-vorg-table.hh:96: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: hb-vector.hh:87: note: candidate 1: const Type& hb_vector_t::operator[](unsigned int) const [with Type = OT::VertOriginMetric, unsigned int PreallocedCount = 8u] hb-ot-vorg-table.hh:96: note: candidate 2: operator[](const T*, int) diff --git a/src/hb-ot-vorg-table.hh b/src/hb-ot-vorg-table.hh index f724fe04..e8dcc503 100644 --- a/src/hb-ot-vorg-table.hh +++ b/src/hb-ot-vorg-table.hh @@ -93,7 +93,7 @@ struct VORG unsigned int size = VertOriginMetric::static_size * subset_metrics.len; VertOriginMetric *metrics = c.allocate_size (size); if (likely (metrics != nullptr)) -memcpy (metrics, _metrics[0], size); +memcpy (metrics, _metrics[0u], size); else success = false; } ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-kern-table.hh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit d39760cabfe4007cefdfc45231e85e93fababac2 Author: Behdad Esfahbod Date: Fri Nov 30 15:55:30 2018 -0500 One more... Sigh. hb-ot-kern-table.hh: In member function 'int OT::KernSubTableFormat3::get_kerning(hb_codepoint_t, hb_codepoint_t) const': hb-ot-kern-table.hh:59: error: ambiguous overload for 'operator[]' in 'kernValue[kernIndex[i]]' hb-ot-kern-table.hh:59: note: candidates are: operator[](T*, int) hb-dsalgs.hh:574: note: Type& hb_array_t::operator[](unsigned int) const [with Type = const OT::IntType] diff --git a/src/hb-ot-kern-table.hh b/src/hb-ot-kern-table.hh index e1348b70..a184f2e1 100644 --- a/src/hb-ot-kern-table.hh +++ b/src/hb-ot-kern-table.hh @@ -56,7 +56,7 @@ struct KernSubTableFormat3 if (unlikely (leftC >= leftClassCount || rightC >= rightClassCount)) return 0; unsigned int i = leftC * rightClassCount + rightC; -return kernValue[kernIndex[i]]; +return kernValue[(unsigned) kernIndex[i]]; } inline bool apply (AAT::hb_aat_apply_context_t *c) const ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-aat-layout-morx-table.hh |4 ++--
src/hb-ot-layout-gpos-table.hh | 32
src/hb-ot-layout-gsubgpos.hh| 16
3 files changed, 26 insertions(+), 26 deletions(-)
New commits:
commit 9c6921c08c905a0cf45ba0182134e6ff910fac51
Author: Behdad Esfahbod
Date: Fri Nov 30 15:16:57 2018 -0500
More...
hb-ot-layout-gsubgpos.hh:1707: error: ISO C++ says that these are
ambiguous, even though the worst conversion for the first is better than the
worst conversion for the second:
...
diff --git a/src/hb-aat-layout-morx-table.hh b/src/hb-aat-layout-morx-table.hh
index 9b37a713..78a7b7d7 100644
--- a/src/hb-aat-layout-morx-table.hh
+++ b/src/hb-aat-layout-morx-table.hh
@@ -249,7 +249,7 @@ struct ContextualSubtable
{
if (entry->data.markIndex != 0x)
{
- const Lookup = subs[entry->data.markIndex];
+ const Lookup = subs[(unsigned)
entry->data.markIndex];
replacement = lookup.get_value (buffer->info[mark].codepoint,
driver->num_glyphs);
}
}
@@ -274,7 +274,7 @@ struct ContextualSubtable
{
if (entry->data.currentIndex != 0x)
{
- const Lookup = subs[entry->data.currentIndex];
+ const Lookup = subs[(unsigned)
entry->data.currentIndex];
replacement = lookup.get_value (buffer->info[idx].codepoint,
driver->num_glyphs);
}
}
diff --git a/src/hb-ot-layout-gpos-table.hh b/src/hb-ot-layout-gpos-table.hh
index 32ed13c0..8559744f 100644
--- a/src/hb-ot-layout-gpos-table.hh
+++ b/src/hb-ot-layout-gpos-table.hh
@@ -625,8 +625,8 @@ struct PairSet
inline bool intersects (const hb_set_t *glyphs,
const ValueFormat *valueFormats) const
{
-unsigned int len1 = valueFormats[0].get_len ();
-unsigned int len2 = valueFormats[1].get_len ();
+unsigned int len1 = valueFormats[0u].get_len ();
+unsigned int len2 = valueFormats[1u].get_len ();
unsigned int record_size = HBUINT16::static_size * (1 + len1 + len2);
const PairValueRecord *record =
@@ -644,8 +644,8 @@ struct PairSet
const ValueFormat *valueFormats) const
{
TRACE_COLLECT_GLYPHS (this);
-unsigned int len1 = valueFormats[0].get_len ();
-unsigned int len2 = valueFormats[1].get_len ();
+unsigned int len1 = valueFormats[0u].get_len ();
+unsigned int len2 = valueFormats[1u].get_len ();
unsigned int record_size = HBUINT16::static_size * (1 + len1 + len2);
const PairValueRecord *record =
@@ -658,8 +658,8 @@ struct PairSet
{
TRACE_APPLY (this);
hb_buffer_t *buffer = c->buffer;
-unsigned int len1 = valueFormats[0].get_len ();
-unsigned int len2 = valueFormats[1].get_len ();
+unsigned int len1 = valueFormats[0u].get_len ();
+unsigned int len2 = valueFormats[1u].get_len ();
unsigned int record_size = HBUINT16::static_size * (1 + len1 + len2);
unsigned int count = len;
@@ -681,8 +681,8 @@ struct PairSet
else
{
/* Note the intentional use of "|" instead of short-circuit "||". */
- if (valueFormats[0].apply_value (c, this, >values[0],
buffer->cur_pos()) |
- valueFormats[1].apply_value (c, this, >values[len1],
buffer->pos[pos]))
+ if (valueFormats[0u].apply_value (c, this, >values[0u],
buffer->cur_pos()) |
+ valueFormats[1u].apply_value (c, this, >values[len1],
buffer->pos[pos]))
buffer->unsafe_to_break (buffer->idx, pos + 1);
if (len2)
pos++;
@@ -698,7 +698,7 @@ struct PairSet
{
const void *base;
const ValueFormat *valueFormats;
-unsigned int len1; /* valueFormats[0].get_len() */
+unsigned int len1; /* valueFormats[0u].get_len() */
unsigned int stride; /* 1 + len1 + len2 */
};
@@ -713,8 +713,8 @@ struct PairSet
unsigned int count = len;
const PairValueRecord *record =
-return_trace (closure->valueFormats[0].sanitize_values_stride_unsafe (c,
closure->base, >values[0], count, closure->stride) &&
- closure->valueFormats[1].sanitize_values_stride_unsafe (c,
closure->base, >values[closure->len1], count, closure->stride));
+return_trace (closure->valueFormats[0u].sanitize_values_stride_unsafe (c,
closure->base, >values[0u], count, closure->stride) &&
+ closure->valueFormats[1u].sanitize_values_stride_unsafe (c,
closure->base, >values[closure->len1], count, closure->stride));
}
protected:
@@ -781,8 +781,8 @@ struct PairPosFormat1
if (!c->check_struct (this)) return_trace (false);
-unsigned int len1 = valueFormat[0].get_len ();
-unsigned int len2 = valueFormat[1].get_len ();
+unsigned int len1 = valueFormat[0u].get_len ();
+unsigned int len2 = valueFormat[1u]
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-name-table.hh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit f998bb2086342d6fdcd4295593eddea91396e0b6
Author: Behdad Esfahbod
Date: Fri Nov 30 12:52:21 2018 -0500
More weird fixes
In file included from hb-ot-name.cc:29:
hb-ot-name-table.hh: In member function 'unsigned int OT::name::get_size()
const':
hb-ot-name-table.hh:157: error: ISO C++ says that these are ambiguous, even
though the worst conversion for the first is better than the worst conversion
for the second:
hb-open-type.hh:354: note: candidate 1: const Type&
OT::UnsizedArrayOf::operator[](unsigned int) const [with Type =
OT::NameRecord]
hb-ot-name-table.hh:157: note: candidate 2: operator[](const T*, int)
hb-ot-name-table.hh: In member function 'void
OT::name::accelerator_t::init(hb_face_t*)':
hb-ot-name-table.hh:196: error: ISO C++ says that these are ambiguous, even
though the worst conversion for the first is better than the worst conversion
for the second:
hb-dsalgs.hh:574: note: candidate 1: Type&
hb_array_t::operator[](unsigned int) const [with Type = const
OT::NameRecord]
hb-ot-name-table.hh:196: note: candidate 2: operator[](T*, int)
hb-ot-name-table.hh:197: error: ISO C++ says that these are ambiguous, even
though the worst conversion for the first is better than the worst conversion
for the second:
hb-dsalgs.hh:574: note: candidate 1: Type&
hb_array_t::operator[](unsigned int) const [with Type = const
OT::NameRecord]
hb-ot-name-table.hh:197: note: candidate 2: operator[](T*, int)
hb-ot-name-table.hh:198: error: ISO C++ says that these are ambiguous, even
though the worst conversion for the first is better than the worst conversion
for the second:
hb-dsalgs.hh:574: note: candidate 1: Type&
hb_array_t::operator[](unsigned int) const [with Type = const
OT::NameRecord]
hb-ot-name-table.hh:198: note: candidate 2: operator[](T*, int)
make[4]: *** [libharfbuzz_la-hb-ot-name.lo] Error 1
make[3]: *** [all-recursive] Error 1
diff --git a/src/hb-ot-name-table.hh b/src/hb-ot-name-table.hh
index 4f24d737..a903e1cd 100644
--- a/src/hb-ot-name-table.hh
+++ b/src/hb-ot-name-table.hh
@@ -154,7 +154,7 @@ struct name
enum { tableTag = HB_OT_TAG_name };
inline unsigned int get_size (void) const
- { return min_size + count * nameRecordZ[0].min_size; }
+ { return min_size + count * nameRecordZ.item_size; }
inline bool sanitize_records (hb_sanitize_context_t *c) const {
TRACE_SANITIZE (this);
@@ -189,7 +189,7 @@ struct name
this->names.init ();
this->names.alloc (all_names.len);
- for (uint16_t i = 0; i < all_names.len; i++)
+ for (unsigned int i = 0; i < all_names.len; i++)
{
hb_ot_name_entry_t *entry = this->names.push ();
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
src/hb-machinery.hh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 67fd94da98f950b5feb719ac805f2a45379fc935
Merge: abd81ed4 ae79fdaa
Author: Behdad Esfahbod
Date: Fri Nov 30 11:53:30 2018 -0500
Merge commit 'ae79fdaa7774d3f886a8f03926577c3bd2010b03'
commit abd81ed4f5cbc5a94171747909bc6b77551cb929
Author: Behdad Esfahbod
Date: Fri Nov 30 11:51:26 2018 -0500
Umm. Cryptic, yes
In file included from hb-face.cc:35:
hb-ot-cmap-table.hh: In member function 'void
OT::CmapSubtableFormat4::_compiles_assertion_on_line_388() const':
hb-ot-cmap-table.hh:388: error: ISO C++ says that these are ambiguous, even
though the worst conversion for the first is better than the worst conversion
for the second:
hb-open-type.hh:354: note: candidate 1: const Type&
OT::UnsizedArrayOf::operator[](unsigned int) const [with Type =
OT::IntType]
hb-ot-cmap-table.hh:388: note: candidate 2: operator[](const T*, int)
hb-ot-cmap-table.hh: In member function 'void
OT::CmapSubtableFormat4::_instance_assertion_on_line_388() const':
hb-ot-cmap-table.hh:388: error: ISO C++ says that these are ambiguous, even
though the worst conversion for the first is better than the worst conversion
for the second:
hb-open-type.hh:354: note: candidate 1: const Type&
OT::UnsizedArrayOf::operator[](unsigned int) const [with Type =
OT::IntType]
hb-ot-cmap-table.hh:388: note: candidate 2: operator[](const T*, int)
hb-face.cc: In function 'hb_blob_t*
_hb_face_builder_data_reference_blob(hb_face_builder_data_t*)':
hb-face.cc:650: error: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion for the
second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t::operator[](unsigned int) [with Type =
hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:650: note: candidate 2: operator[](T*, int)
hb-face.cc:650: error: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion for the
second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t::operator[](unsigned int) [with Type =
hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:650: note: candidate 2: operator[](const T*, int)
hb-face.cc:651: error: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion for the
second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t::operator[](unsigned int) [with Type =
hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:651: note: candidate 2: operator[](T*, int)
hb-face.cc:651: error: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion for the
second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t::operator[](unsigned int) [with Type =
hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:651: note: candidate 2: operator[](const T*, int)
diff --git a/src/hb-face.cc b/src/hb-face.cc
index 724f54d5..a1ae1d77 100644
--- a/src/hb-face.cc
+++ b/src/hb-face.cc
@@ -647,8 +647,8 @@ _hb_face_builder_data_reference_blob
(hb_face_builder_data_t *data)
bool is_cff = data->tables.lsearch (HB_TAG ('C','F','F',' ')) ||
data->tables.lsearch (HB_TAG ('C','F','F','2'));
hb_tag_t sfnt_tag = is_cff ? OT::OpenTypeFontFile::CFFTag :
OT::OpenTypeFontFile::TrueTypeTag;
- Suppliertags_supplier (>tables[0].tag, table_count,
data->tables.item_size);
- Supplier blobs_supplier (>tables[0].blob, table_count,
data->tables.item_size);
+ Suppliertags_supplier (>tables[0u].tag, table_count,
data->tables.item_size);
+ Supplier blobs_supplier (>tables[0u].blob, table_count,
data->tables.item_size);
bool ret = f->serialize_single (,
sfnt_tag,
tags_supplier,
diff --git a/src/hb-machinery.hh b/src/hb-machinery.hh
index 1732d297..19d2e17a 100644
--- a/src/hb-machinery.hh
+++ b/src/hb-machinery.hh
@@ -117,8 +117,8 @@ static inline Type& StructAfter(TObject )
enum { min_size = (size) }
#define DEFINE_SIZE_ARRAY(size, array) \
- DEFINE_COMPILES_ASSERTION ((void) (array)[0].static_size) \
- DEFINE_INSTANCE_ASSERTION (sizeof (*this) == (size) + VAR * sizeof
((array)[0])) \
+ DEFINE_COMPILES_ASSERTION ((void) (array)[0u].static_size) \
+ DEFINE_INSTANCE_ASSERTION (sizeof (*this) == (size) + VAR * sizeof
((array)[0u])) \
enum { null_size = (size) }; \
enum { min_size = (size) }
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-face.cc |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit ae79fdaa7774d3f886a8f03926577c3bd2010b03
Author: Behdad Esfahbod
Date: Fri Nov 30 11:51:26 2018 -0500
Umm. Cryptic, yes
hb-face.cc:650: error: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion for the
second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t::operator[](unsigned int) [with Type =
hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:650: note: candidate 2: operator[](T*, int)
diff --git a/src/hb-face.cc b/src/hb-face.cc
index 724f54d5..a1ae1d77 100644
--- a/src/hb-face.cc
+++ b/src/hb-face.cc
@@ -647,8 +647,8 @@ _hb_face_builder_data_reference_blob
(hb_face_builder_data_t *data)
bool is_cff = data->tables.lsearch (HB_TAG ('C','F','F',' ')) ||
data->tables.lsearch (HB_TAG ('C','F','F','2'));
hb_tag_t sfnt_tag = is_cff ? OT::OpenTypeFontFile::CFFTag :
OT::OpenTypeFontFile::TrueTypeTag;
- Suppliertags_supplier (>tables[0].tag, table_count,
data->tables.item_size);
- Supplier blobs_supplier (>tables[0].blob, table_count,
data->tables.item_size);
+ Suppliertags_supplier (>tables[0u].tag, table_count,
data->tables.item_size);
+ Supplier blobs_supplier (>tables[0u].blob, table_count,
data->tables.item_size);
bool ret = f->serialize_single (,
sfnt_tag,
tags_supplier,
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-face.cc |4 ++--
src/hb-set.hh |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
New commits:
commit 0f32c95e1487ffcc37439635c3294f941eae857a
Author: Behdad Esfahbod
Date: Fri Nov 30 11:31:39 2018 -0500
Fix a few more sizeof(vector[0]) errors with weird compilers
diff --git a/src/hb-face.cc b/src/hb-face.cc
index 5b33784f..724f54d5 100644
--- a/src/hb-face.cc
+++ b/src/hb-face.cc
@@ -647,8 +647,8 @@ _hb_face_builder_data_reference_blob
(hb_face_builder_data_t *data)
bool is_cff = data->tables.lsearch (HB_TAG ('C','F','F',' ')) ||
data->tables.lsearch (HB_TAG ('C','F','F','2'));
hb_tag_t sfnt_tag = is_cff ? OT::OpenTypeFontFile::CFFTag :
OT::OpenTypeFontFile::TrueTypeTag;
- Suppliertags_supplier (>tables[0].tag, table_count,
sizeof (data->tables[0]));
- Supplier blobs_supplier (>tables[0].blob, table_count,
sizeof (data->tables[0]));
+ Suppliertags_supplier (>tables[0].tag, table_count,
data->tables.item_size);
+ Supplier blobs_supplier (>tables[0].blob, table_count,
data->tables.item_size);
bool ret = f->serialize_single (,
sfnt_tag,
tags_supplier,
diff --git a/src/hb-set.hh b/src/hb-set.hh
index a3beeef1..f1fccd8f 100644
--- a/src/hb-set.hh
+++ b/src/hb-set.hh
@@ -678,7 +678,7 @@ struct hb_set_t
pages[map.index].init0 ();
memmove (page_map + i + 1,
page_map + i,
- (page_map.len - 1 - i) * sizeof (page_map[0]));
+ (page_map.len - 1 - i) * page_map.item_size);
page_map[i] = map;
}
return [page_map[i].index];
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-deprecated.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 88630a458b21b811075bed9e761a94c50736dc11 Author: Behdad Esfahbod Date: Fri Nov 30 01:11:04 2018 -0500 Fix build for realz diff --git a/src/hb-ot-deprecated.h b/src/hb-ot-deprecated.h index 0dfabc9b..bce51b71 100644 --- a/src/hb-ot-deprecated.h +++ b/src/hb-ot-deprecated.h @@ -31,7 +31,7 @@ #ifndef HB_OT_DEPRECATED_H #define HB_OT_DEPRECATED_H -#include "hb-common.h" +#include "hb.h" #include "hb-ot-name.h" ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-deprecated.h |1 + 1 file changed, 1 insertion(+) New commits: commit 346286d04eb616c43ba8c796211fa2e5e7bf1983 Author: Behdad Esfahbod Date: Fri Nov 30 00:44:40 2018 -0500 Fix build diff --git a/src/hb-ot-deprecated.h b/src/hb-ot-deprecated.h index 1d54dc69..0dfabc9b 100644 --- a/src/hb-ot-deprecated.h +++ b/src/hb-ot-deprecated.h @@ -31,6 +31,7 @@ #ifndef HB_OT_DEPRECATED_H #define HB_OT_DEPRECATED_H +#include "hb-common.h" #include "hb-ot-name.h" ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-ot-post-table.hh |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) New commits: commit 31f39cb41e1497a76c5838c93f9b4034089049f2 Author: Behdad Esfahbod Date: Fri Nov 30 00:38:08 2018 -0500 [post] Rename v2 to v2X diff --git a/src/hb-ot-post-table.hh b/src/hb-ot-post-table.hh index 0ca3760b..64f0936f 100644 --- a/src/hb-ot-post-table.hh +++ b/src/hb-ot-post-table.hh @@ -107,7 +107,7 @@ struct post version = table->version.to_int (); if (version != 0x0002) return; - const postV2Tail = table->v2; + const postV2Tail = table->v2X; glyphNameIndex = pool = (v2.glyphNameIndex); @@ -250,7 +250,7 @@ struct post TRACE_SANITIZE (this); return_trace (likely (c->check_struct (this) && (version.to_int () == 0x0001 || - (version.to_int () == 0x0002 && v2.sanitize (c)) || + (version.to_int () == 0x0002 && v2X.sanitize (c)) || version.to_int () == 0x0003))); } @@ -286,7 +286,7 @@ struct post * is downloaded as a Type 1 font. */ HBUINT32 maxMemType1;/* Maximum memory usage when an OpenType font * is downloaded as a Type 1 font. */ - postV2Tail v2; + postV2Tail v2X; DEFINE_SIZE_MIN (32); }; ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/Makefile.sources |1
src/hb-deprecated.h| 61
src/hb-ot-deprecated.h | 106 +
src/hb-ot.h|1
4 files changed, 109 insertions(+), 60 deletions(-)
New commits:
commit e3dd47e6025a7f082af4830ba483d90d9b44381f
Author: Behdad Esfahbod
Date: Fri Nov 30 00:32:12 2018 -0500
Move things
diff --git a/src/Makefile.sources b/src/Makefile.sources
index ba90ef02..3ae5806d 100644
--- a/src/Makefile.sources
+++ b/src/Makefile.sources
@@ -185,6 +185,7 @@ HB_OT_headers = \
hb-aat-layout.h \
hb-ot.h \
hb-ot-color.h \
+ hb-ot-deprecated.h \
hb-ot-font.h \
hb-ot-layout.h \
hb-ot-math.h \
diff --git a/src/hb-deprecated.h b/src/hb-deprecated.h
index 9ceb2648..4a5e702f 100644
--- a/src/hb-deprecated.h
+++ b/src/hb-deprecated.h
@@ -52,6 +52,7 @@ HB_BEGIN_DECLS
#ifndef HB_DISABLE_DEPRECATED
+
#define HB_SCRIPT_CANADIAN_ABORIGINAL HB_SCRIPT_CANADIAN_SYLLABICS
#define HB_BUFFER_FLAGS_DEFAULTHB_BUFFER_FLAG_DEFAULT
@@ -217,66 +218,6 @@ hb_font_get_glyph_kerning_for_direction (hb_font_t *font,
hb_direction_t direction,
hb_position_t *x, hb_position_t *y);
-/* Like hb_ot_layout_table_find_script, but takes zero-terminated array of
scripts to test */
-HB_EXTERN HB_DEPRECATED_FOR (hb_ot_layout_table_select_script) hb_bool_t
-hb_ot_layout_table_choose_script (hb_face_t *face,
- hb_tag_ttable_tag,
- const hb_tag_t *script_tags,
- unsigned int *script_index,
- hb_tag_t *chosen_script);
-
-HB_EXTERN HB_DEPRECATED_FOR (hb_ot_layout_script_select_language) hb_bool_t
-hb_ot_layout_script_find_language (hb_face_t*face,
- hb_tag_t table_tag,
- unsigned int script_index,
- hb_tag_t language_tag,
- unsigned int *language_index);
-
-HB_EXTERN HB_DEPRECATED_FOR (hb_ot_tags_from_script_and_language) void
-hb_ot_tags_from_script (hb_script_t script,
- hb_tag_t*script_tag_1,
- hb_tag_t*script_tag_2);
-
-HB_EXTERN HB_DEPRECATED_FOR (hb_ot_tags_from_script_and_language) hb_tag_t
-hb_ot_tag_from_language (hb_language_t language);
-
-
-typedef unsigned int hb_ot_name_id_t; /* Since is in hb-ot.h */
-
-/**
- * HB_OT_VAR_NO_AXIS_INDEX:
- *
- * Since: 1.4.2
- * Deprecated: 2.2.0
- */
-#define HB_OT_VAR_NO_AXIS_INDEX0xu
-
-/**
- * hb_ot_var_axis_t:
- *
- * Since: 1.4.2
- * Deprecated: 2.2.0
- */
-typedef struct hb_ot_var_axis_t
-{
- hb_tag_t tag;
- hb_ot_name_id_t name_id;
- float min_value;
- float default_value;
- float max_value;
-} hb_ot_var_axis_t;
-
-HB_EXTERN HB_DEPRECATED_FOR (hb_ot_var_get_axis_infos) unsigned int
-hb_ot_var_get_axes (hb_face_t*face,
- unsigned int start_offset,
- unsigned int *axes_count /* IN/OUT */,
- hb_ot_var_axis_t *axes_array /* OUT */);
-
-HB_EXTERN HB_DEPRECATED_FOR (hb_ot_var_find_axis_info) hb_bool_t
-hb_ot_var_find_axis (hb_face_t*face,
-hb_tag_t axis_tag,
-unsigned int *axis_index,
-hb_ot_var_axis_t *axis_info);
#endif
diff --git a/src/hb-ot-deprecated.h b/src/hb-ot-deprecated.h
new file mode 100644
index ..1d54dc69
--- /dev/null
+++ b/src/hb-ot-deprecated.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright © 2018 Google, Inc.
+ *
+ * This is part of HarfBuzz, a text shaping library.
+ *
+ * Permission is hereby granted, without written agreement and without
+ * license or royalty fees, to use, copy, modify, and distribute this
+ * software and its documentation for any purpose, provided that the
+ * above copyright notice and the following two paragraphs appear in
+ * all copies of this software.
+ *
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE TO ANY PARTY FOR
+ * DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
+ * ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN
+ * IF THE COPYRIGHT HOLDER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * THE COPYRIGHT HOLDER SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING,
+ * BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+ * ON AN "AS IS" BASIS, AND THE COPYRIGHT HOLDER HAS NO OBLIGATION TO
+ * PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
+ *
+ * Google Author(s): Behdad Esfahbod
+ */
+
+#ifndef HB_OT_H_IN
+#error "Include instead."
+#endif
+
+#ifndef HB_OT_D
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-coretext.cc |2 +-
src/hb-uniscribe.cc | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
New commits:
commit 27a6b0a2f7255ed6fc7bfe1f10052c2e344e319b
Author: Behdad Esfahbod
Date: Thu Nov 29 16:29:30 2018 -0500
Fix build for realz
diff --git a/src/hb-coretext.cc b/src/hb-coretext.cc
index fbb165e9..15b8c62d 100644
--- a/src/hb-coretext.cc
+++ b/src/hb-coretext.cc
@@ -598,7 +598,7 @@ _hb_coretext_shape (hb_shape_plan_t*shape_plan,
} else {
active_feature_t *feature = active_features.find (>feature);
if (feature)
- active_features.remove (feature - (active_feature_t *)
active_features);
+ active_features.remove (feature - active_features.arrayZ ());
}
}
}
diff --git a/src/hb-uniscribe.cc b/src/hb-uniscribe.cc
index c403d165..e98e41f9 100644
--- a/src/hb-uniscribe.cc
+++ b/src/hb-uniscribe.cc
@@ -695,7 +695,7 @@ _hb_uniscribe_shape (hb_shape_plan_t*shape_plan,
{
active_feature_t *feature = active_features.find (>feature);
if (feature)
- active_features.remove (feature - (active_feature_t *)
active_features);
+ active_features.remove (feature - active_features.arrayZ ());
}
}
@@ -886,8 +886,8 @@ retry:
[i].a,
script_tags[i],
language_tag,
-range_char_counts,
-range_properties,
+range_char_counts.arrayZ (),
+range_properties.arrayZ (),
range_properties.len,
pchars + chars_offset,
item_chars_len,
@@ -927,8 +927,8 @@ retry:
[i].a,
script_tags[i],
language_tag,
-range_char_counts,
-range_properties,
+range_char_counts.arrayZ (),
+range_properties.arrayZ (),
range_properties.len,
pchars + chars_offset,
log_clusters + chars_offset,
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 4 commits
.circleci/config.yml | 48 ++--
src/hb-machinery.hh |2
src/hb-uniscribe.cc |2
test/shaping/data/in-house/tests/macos.tests | 64 +--
4 files changed, 58 insertions(+), 58 deletions(-)
New commits:
commit e2af4dd1ecbe398c60fe5f3f370dd35400d7e1eb
Author: Behdad Esfahbod
Date: Thu Nov 29 16:03:15 2018 -0500
[uniscribe] Fix build
diff --git a/src/hb-uniscribe.cc b/src/hb-uniscribe.cc
index 1fae6435..c403d165 100644
--- a/src/hb-uniscribe.cc
+++ b/src/hb-uniscribe.cc
@@ -695,7 +695,7 @@ _hb_uniscribe_shape (hb_shape_plan_t*shape_plan,
{
active_feature_t *feature = active_features.find (>feature);
if (feature)
- active_features.remove (feature - active_features);
+ active_features.remove (feature - (active_feature_t *)
active_features);
}
}
commit bf738ba3ba80778c7feb95ece446607a250d9382
Author: Ebrahim Byagowi
Date: Fri Nov 30 00:06:40 2018 +0330
[test][aat] Remove extra --shaper ot
As run-tests.py already adds it
diff --git a/test/shaping/data/in-house/tests/macos.tests
b/test/shaping/data/in-house/tests/macos.tests
index 9fb46e8c..859992cd 100644
--- a/test/shaping/data/in-house/tests/macos.tests
+++ b/test/shaping/data/in-house/tests/macos.tests
@@ -1,35 +1,35 @@
# 10.12.6 https://gist.github.com/ebraminio/1704341fa16b06979e605aafd88198cf
-/System/Library/Fonts/Helvetica.dfont@c7bec2785a4c402b7809b5e35337c3d24c18e281:--shaper
ot --font-funcs ot:U+006D,U+0300:[m=0+1706|gravecmb=0@-284,10+0]
-/System/Library/Fonts/LucidaGrande.ttc@d89a9d7e57767bfe3b5a4cfd22bb1e9dbe03a062:--shaper
ot --font-funcs ot:U+006D,U+0300:[mgrave=0+1912]
-/System/Library/Fonts/Times.dfont@39c954614d3f3317b28564db06d5b7b7a6ff0e39:--shaper
ot --font-funcs ot:U+0066,U+0069:[fi=0+1139]
-/Library/Fonts/Khmer MN.ttc@5f5b1072df99b7355d3066ea85fe82969d13c94a:--shaper
ot --font-funcs
ot:U+17A2,U+1780,U+17D2,U+179F,U+179A,U+1781,U+17D2,U+1798,U+17C2,U+179A:[km_qa=0+1025|km_ka=1+1025|km_sa.sub=1+517|km_ro=4+593|km_vs_ae=5+605|km_kha=5+1025|km_mo.sub=5+0|km_ro=9+593]
-/Library/Fonts/Tamil MN.ttc@37a2020c3f86ebcc45e02c1de5fdf81e2676989d:--shaper
ot --font-funcs
ot:U+0BA4,U+0BCA,U+0B95,U+0BC1,U+0B95,U+0BCD,U+0B95,U+0BAA,U+0BCD,U+0BAA,U+0B9F,U+0BCD,U+0B9F,U+0BC1:[tgm_e=0+1702|tgc_ta=0+1598|tgm_aa=0+1149|tgc_ku=2+1962|tgc_k=4+1592|tgc_ka=6+1592|tgc_p=7+1370|tgc_pa=9+1370|tgc_tt=10+1596|tgc_ttu=12+1833]
-/System/Library/Fonts/Times.dfont@39c954614d3f3317b28564db06d5b7b7a6ff0e39:--shaper
ot --font-funcs
ot:U+0041,U+0066,U+0300,U+0066,U+0069,U+005A:[A=0+1479|f=1+682|gravecmb=1@-480,588+0|fi=3+1139|Z=5+1251]
-/System/Library/Fonts/LucidaGrande.ttc@d89a9d7e57767bfe3b5a4cfd22bb1e9dbe03a062:--shaper
ot --font-funcs ot:U+05E1,U+05B0:[shevahebrew=0@-7,0+0|samekhhebrew=0+1361]
-/Library/Fonts/Apple
Chancery.ttf@5fc49ae9bce39e2105864323183b68ea34c9e562:--shaper ot --font-funcs
ot:U+0054,U+0068,U+0020,U+0074,U+0068,U+0020,U+006C,U+006C,U+0020,U+0074,U+0065,U+0020,U+0074,U+006F,U+0020,U+0074,U+0072,U+0020,U+0066,U+0072,U+0020,U+0066,U+0075,U+0020,U+0066,U+006A:[T_h=0+2308|space=2+569|t_h=3+1687|space=5+569|l_l=6+1108|space=8+569|t_e=9+1408|space=11+569|t_o=12+1531|space=14+569|t_r=15+1385|space=17+569|f_r=18+1432|space=20+569|f_u=21+1733|space=23+569|f_j=24+1098]
-/Library/Fonts/Apple
Chancery.ttf@5fc49ae9bce39e2105864323183b68ea34c9e562:--shaper ot --font-funcs
ot:U+0054,U+0065,U+0020,U+0041,U+0056,U+0020,U+0054,U+0072,U+0020,U+0056,U+0061,U+0020,U+0072,U+0054,U+0020,U+0065,U+0054,U+0020,U+0054,U+0064:[T=0+1497|e=1@-62,0+699|space=2+569|A=3+1431|V=4@-37,0+1377|space=5+569|T=6+1510|r=7@-50,0+803|space=8+569|V=9+1376|a=10@-37,0+1014|space=11+569|r=12+853|T=13+1560|space=14+569|e=15+761|T=16+1560|space=17+569|T=18+1515|d=19@-45,0+1006]
-/System/Library/Fonts/GeezaPro.ttc@f43ee7151c2e9f1dddfbc26cfc148609eb5c5820:--shaper
ot --font-funcs
ot:U+0627,U+0644,U+0623,U+064E,U+0628,U+0652,U+062C,U+064E,U+062F,U+0650,U+064A,U+064E,U+0651,U+0629,U+0640,U+0627,U+0644,U+0639,U+064E,U+0631,U+064E,U+0628,U+0650,U+064A,U+064E,U+0651,U+0629:[u0629.final.tehMarbuta=26+713|u064e_u0651.shaddaFatha=23@0,-200+0|u064a.medial.yeh=23+656|u0650.kasra=21@80,290+80|u0628.initial.beh=21@-80,0+576|u064e.fatha=19@200,-570+200|u0631.final.reh=19@-200,0+702|u064e.fatha=17@200,-200+200|u0639.medial.ain=17@-200,0+738|u0644.initial.lam=16+515|u0627.final.alef=15+647|u0640.tatweel=14+449|u0629.final.tehMarbuta=13+713|u064e_u0651.shaddaFatha=10@0,-200+0|u064a.initial.yeh=10+656|u0650.kasra=8@80,570+80|u062f.final.dal=8@-80,0+822|u064e.fatha=6@290,-160+290|u062c.medial.jeem=6@-290,0+1069|u0652.sukun=4@0,-200+0|u0628.initial.beh=4+656|u064e.fatha=1@-252,120+-252|u0644_u0623.isolated.lamHamzaOnAlef=1@120,0+1282|u0627.alef=0+647]
-/System/Library/Fonts/GeezaPro.ttc@f43ee7151c2e9f1dddfbc26cfc148609eb5c5820:--shaper
ot --font-funcs
ot:U+0628,U+064A,U+064E,U+0651,U+0629:[u0
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-coretext.cc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit ac0264717b949df8840b179d882a9bed2993fb74
Author: Behdad Esfahbod
Date: Thu Nov 29 15:07:44 2018 -0500
[coretext] Fix compile
Fingers crossed.
diff --git a/src/hb-coretext.cc b/src/hb-coretext.cc
index 918f649d..fbb165e9 100644
--- a/src/hb-coretext.cc
+++ b/src/hb-coretext.cc
@@ -598,7 +598,7 @@ _hb_coretext_shape (hb_shape_plan_t*shape_plan,
} else {
active_feature_t *feature = active_features.find (>feature);
if (feature)
- active_features.remove (feature - active_features);
+ active_features.remove (feature - (active_feature_t *)
active_features);
}
}
}
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 3 commits
src/hb-aat-layout-ankr-table.hh |2 +-
src/hb-aat-layout-bsln-table.hh |2 +-
src/hb-aat-layout-common.hh |4 ++--
src/hb-aat-layout-feat-table.hh |2 +-
src/hb-aat-layout-just-table.hh |2 +-
src/hb-aat-layout-kerx-table.hh | 10 +-
src/hb-aat-layout-lcar-table.hh |2 +-
src/hb-aat-layout-morx-table.hh | 14 +++---
src/hb-aat-layout-trak-table.hh |2 +-
src/hb-aat-ltag-table.hh|2 +-
src/hb-dsalgs.hh| 16
src/hb-map.hh |2 +-
src/hb-ot-cmap-table.hh |2 +-
src/hb-ot-color-cbdt-table.hh |4 ++--
src/hb-ot-color-colr-table.hh |2 +-
src/hb-ot-color-cpal-table.hh |2 +-
src/hb-ot-color-sbix-table.hh |2 +-
src/hb-ot-color-svg-table.hh|2 +-
src/hb-ot-glyf-table.hh |4 ++--
src/hb-ot-hdmx-table.hh |2 +-
src/hb-ot-head-table.hh |2 +-
src/hb-ot-hhea-table.hh |4 ++--
src/hb-ot-hmtx-table.hh | 14 +++---
src/hb-ot-kern-table.hh | 14 +++---
src/hb-ot-layout-base-table.hh |2 +-
src/hb-ot-layout-gdef-table.hh |2 +-
src/hb-ot-layout-gpos-table.hh |2 +-
src/hb-ot-layout-gsub-table.hh |2 +-
src/hb-ot-layout-jstf-table.hh |2 +-
src/hb-ot-layout.cc |4 ++--
src/hb-ot-math-table.hh |2 +-
src/hb-ot-maxp-table.hh |2 +-
src/hb-ot-name-table.hh |2 +-
src/hb-ot-os2-table.hh |2 +-
src/hb-ot-post-table.hh |2 +-
src/hb-ot-stat-table.hh |2 +-
src/hb-ot-var-avar-table.hh |2 +-
src/hb-ot-var-fvar-table.hh |2 +-
src/hb-ot-var-hvar-table.hh |8
src/hb-ot-var-mvar-table.hh |2 +-
src/hb-ot-vorg-table.hh |2 +-
src/hb-set-digest.hh| 14 +++---
42 files changed, 85 insertions(+), 85 deletions(-)
New commits:
commit 5c4fead734b082e0168e6811bec4bcaa19acc36a
Author: Behdad Esfahbod
Date: Thu Nov 29 15:04:34 2018 -0500
Convert "static const hb_tag_t" constants to enum
diff --git a/src/hb-aat-layout-ankr-table.hh b/src/hb-aat-layout-ankr-table.hh
index b793245a..763bbedd 100644
--- a/src/hb-aat-layout-ankr-table.hh
+++ b/src/hb-aat-layout-ankr-table.hh
@@ -58,7 +58,7 @@ typedef LArrayOf GlyphAnchors;
struct ankr
{
- static const hb_tag_t tableTag = HB_AAT_TAG_ankr;
+ enum { tableTag = HB_AAT_TAG_ankr };
inline const Anchor _anchor (hb_codepoint_t glyph_id,
unsigned int i,
diff --git a/src/hb-aat-layout-bsln-table.hh b/src/hb-aat-layout-bsln-table.hh
index b8640862..d2ea71d1 100644
--- a/src/hb-aat-layout-bsln-table.hh
+++ b/src/hb-aat-layout-bsln-table.hh
@@ -116,7 +116,7 @@ struct BaselineTableFormat3Part
struct bsln
{
- static const hb_tag_t tableTag = HB_AAT_TAG_bsln;
+ enum { tableTag = HB_AAT_TAG_bsln };
inline bool sanitize (hb_sanitize_context_t *c) const
{
diff --git a/src/hb-aat-layout-feat-table.hh b/src/hb-aat-layout-feat-table.hh
index 4e63ec8e..1565d432 100644
--- a/src/hb-aat-layout-feat-table.hh
+++ b/src/hb-aat-layout-feat-table.hh
@@ -155,7 +155,7 @@ struct FeatureName
struct feat
{
- static const hb_tag_t tableTag = HB_AAT_TAG_feat;
+ enum { tableTag = HB_AAT_TAG_feat };
inline bool has_data (void) const { return version.to_int (); }
diff --git a/src/hb-aat-layout-just-table.hh b/src/hb-aat-layout-just-table.hh
index 92ca6603..295205fd 100644
--- a/src/hb-aat-layout-just-table.hh
+++ b/src/hb-aat-layout-just-table.hh
@@ -382,7 +382,7 @@ struct JustificationHeader
struct just
{
- static const hb_tag_t tableTag = HB_AAT_TAG_just;
+ enum { tableTag = HB_AAT_TAG_just };
inline bool sanitize (hb_sanitize_context_t *c) const
{
diff --git a/src/hb-aat-layout-kerx-table.hh b/src/hb-aat-layout-kerx-table.hh
index 9a2351a1..b25feea2 100644
--- a/src/hb-aat-layout-kerx-table.hh
+++ b/src/hb-aat-layout-kerx-table.hh
@@ -982,7 +982,7 @@ struct kerx : KerxTable
{
friend struct KerxTable;
- static const hb_tag_t tableTag = HB_AAT_TAG_kerx;
+ enum { tableTag = HB_AAT_TAG_kerx };
enum { minVersion = 2u };
typedef KerxSubTableHeader SubTableHeader;
diff --git a/src/hb-aat-layout-lcar-table.hh b/src/hb-aat-layout-lcar-table.hh
index 40d34f59..9bfb6849 100644
--- a/src/hb-aat-layout-lcar-table.hh
+++ b/src/hb-aat-layout-lcar-table.hh
@@ -40,7 +40,7 @@ typedef ArrayOf LigCaretClassEntry;
struct lcar
{
- static const hb_tag_t tableTag = HB_AAT_TAG_lcar;
+ enum { tableTag = HB_AAT_TAG_lcar };
inline unsigned int get_lig_carets (hb_font_t *font,
hb_direction_t direction,
diff --git a/src/hb-aat-layout-morx-table.hh b/src/hb-aat-layout-morx-table.hh
index e8a0cdfc..9b37a713 100644
--- a/src/hb-aat-layout-morx-table.hh
+++ b/src/hb-aat-layout-morx-table.hh
@@ -1096,7 +1096,7 @@ struct Chain
template
struct mortmorx
{
- st
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-machinery.hh |2 +-
src/hb-ot-cmap-table.hh |3 ++-
src/hb-set.hh |4 ++--
src/hb-subset.cc|2 +-
src/hb-vector.hh|4 ++--
5 files changed, 8 insertions(+), 7 deletions(-)
New commits:
commit 861bc75349257f74c12b261abfcd5ab9e2f04863
Author: Behdad Esfahbod
Date: Thu Nov 29 14:34:44 2018 -0500
[vector] Make pointer cast explicit
Too bad this doesn't help MSVC 2008 build, as explicit operators are
C++11.
diff --git a/src/hb-machinery.hh b/src/hb-machinery.hh
index 39e96293..5f3d153e 100644
--- a/src/hb-machinery.hh
+++ b/src/hb-machinery.hh
@@ -658,7 +658,7 @@ struct Supplier
}
inline Supplier (const hb_vector_t *v)
{
-head = *v;
+head = (const Type *) *v;
len = v->len;
stride = sizeof (Type);
}
diff --git a/src/hb-ot-cmap-table.hh b/src/hb-ot-cmap-table.hh
index cdc610be..a2e611c9 100644
--- a/src/hb-ot-cmap-table.hh
+++ b/src/hb-ot-cmap-table.hh
@@ -495,7 +495,8 @@ struct CmapSubtableLongSegmented
{
TRACE_SERIALIZE (this);
if (unlikely (!c->extend_min (*this))) return_trace (false);
-Supplier supplier (group_data, group_data.len);
+Supplier supplier ((const
OT::CmapSubtableLongGroup*) group_data,
+ group_data.len);
if (unlikely (!groups.serialize (c, supplier, group_data.len)))
return_trace (false);
return true;
}
diff --git a/src/hb-set.hh b/src/hb-set.hh
index 100bdb2a..a3beeef1 100644
--- a/src/hb-set.hh
+++ b/src/hb-set.hh
@@ -375,8 +375,8 @@ struct hb_set_t
if (!resize (count))
return;
population = other->population;
-memcpy (pages, other->pages, count * pages.item_size);
-memcpy (page_map, other->page_map, count * page_map.item_size);
+memcpy ((void *) pages, (const void *) other->pages, count *
pages.item_size);
+memcpy ((void *) page_map, (const void *) other->page_map, count *
page_map.item_size);
}
inline bool is_equal (const hb_set_t *other) const
diff --git a/src/hb-subset.cc b/src/hb-subset.cc
index a3917b86..14d4774c 100644
--- a/src/hb-subset.cc
+++ b/src/hb-subset.cc
@@ -77,7 +77,7 @@ _subset2 (hb_subset_plan_t *plan)
return false;
}
retry:
-hb_serialize_context_t serializer (buf, buf_size);
+hb_serialize_context_t serializer ((void *) buf, buf_size);
hb_subset_context_t c (plan, );
result = table->subset ();
if (serializer.ran_out_of_room)
diff --git a/src/hb-vector.hh b/src/hb-vector.hh
index 787512f9..313c24c4 100644
--- a/src/hb-vector.hh
+++ b/src/hb-vector.hh
@@ -101,8 +101,8 @@ struct hb_vector_t
inline hb_sorted_array_t as_sorted_array (void) const
{ return hb_sorted_array (arrayZ(), len); }
- template inline operator T * (void) { return arrayZ(); }
- template inline operator const T * (void) const { return
arrayZ(); }
+ template explicit_operator inline operator T * (void) { return
arrayZ(); }
+ template explicit_operator inline operator const T * (void)
const { return arrayZ(); }
inline Type * operator + (unsigned int i) { return arrayZ() + i; }
inline const Type * operator + (unsigned int i) const { return arrayZ() +
i; }
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-set.hh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 72955e68256806f082439d65e6f9b5cf2e35fa8a Author: Behdad Esfahbod Date: Thu Nov 29 14:28:44 2018 -0500 Hand-hold older compilers diff --git a/src/hb-set.hh b/src/hb-set.hh index 8b7a0f3d..100bdb2a 100644 --- a/src/hb-set.hh +++ b/src/hb-set.hh @@ -660,7 +660,7 @@ struct hb_set_t unsigned int count = pages.len; for (int i = count - 1; i >= 0; i++) if (!page_at (i).is_empty ()) -return page_map[i].major * page_t::PAGE_BITS + page_at (i).get_max (); +return page_map[(unsigned) i].major * page_t::PAGE_BITS + page_at (i).get_max (); return INVALID; } ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-0.ttf |binary test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-Missing.ttf |binary 2 files changed New commits: commit 1a182e97ee71de0e78a70ff823ae17fa93a31830 Author: Behdad Esfahbod Date: Thu Nov 29 12:39:52 2018 -0500 [test/text-rendering-tests] Update from upstream diff --git a/test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-0.ttf b/test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-0.ttf new file mode 100644 index ..07e68821 Binary files /dev/null and b/test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-0.ttf differ diff --git a/test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-Missing.ttf b/test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-Missing.ttf new file mode 100644 index ..58dd961c Binary files /dev/null and b/test/shaping/data/text-rendering-tests/fonts/TestGVAR-Composite-Missing.ttf differ ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
src/hb-ot-shape-complex-khmer.cc | 15 +--
src/hb-ot-shape.cc |6 +++---
2 files changed, 12 insertions(+), 9 deletions(-)
New commits:
commit 000d4b128eba58677acdc3b361829ff2f9a257b1
Author: Behdad Esfahbod
Date: Thu Nov 29 12:32:47 2018 -0500
Make shaper's override_features() override user features as well
The override_features is used to override features that are normally
discretionary features, but in a specific shaper are for various
reasons desired to be bolted on or off, because they've been used
for inherent shaping. As such, it makes sense that they also
override user features. Ie. if user turned 'liga' on, we don't
want Khmer shaping to become broken... Or turn 'clig' off...
Fixes https://github.com/harfbuzz/harfbuzz/issues/1310
diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index ef974357..e0074d53 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -309,9 +309,6 @@ hb_ot_shape_collect_features (hb_ot_shape_planner_t
*planner,
map->enable_feature (HB_TAG ('v','e','r','t'), F_GLOBAL_SEARCH);
}
- if (planner->shaper->override_features)
-planner->shaper->override_features (planner);
-
for (unsigned int i = 0; i < num_user_features; i++)
{
const hb_feature_t *feature = _features[i];
@@ -330,6 +327,9 @@ hb_ot_shape_collect_features (hb_ot_shape_planner_t
*planner,
aat_map->add_feature (feature->tag, feature->value);
}
}
+
+ if (planner->shaper->override_features)
+planner->shaper->override_features (planner);
}
commit a95d9d8c8465ebc927bc2194dffe4ea95542e54c
Author: Behdad Esfahbod
Date: Thu Nov 29 12:30:14 2018 -0500
[khmer] Move 'clig' to overrides
Prerequisite for https://github.com/harfbuzz/harfbuzz/issues/1310
diff --git a/src/hb-ot-shape-complex-khmer.cc b/src/hb-ot-shape-complex-khmer.cc
index 497891ea..8b6ec51d 100644
--- a/src/hb-ot-shape-complex-khmer.cc
+++ b/src/hb-ot-shape-complex-khmer.cc
@@ -127,22 +127,25 @@ collect_features_khmer (hb_ot_shape_planner_t *plan)
for (; i < KHMER_NUM_FEATURES; i++)
map->add_feature (khmer_features[i]);
-
- map->enable_feature (HB_TAG('c','a','l','t'));
- map->enable_feature (HB_TAG('c','l','i','g'));
-
}
static void
override_features_khmer (hb_ot_shape_planner_t *plan)
{
+ hb_ot_map_builder_t *map = >map;
+
+ /* Khmer spec has 'clig' as part of required shaping features:
+ * "Apply feature 'clig' to form ligatures that are desired for
+ * typographical correctness.", hence in overrides... */
+ map->enable_feature (HB_TAG('c','l','i','g'));
+
/* Uniscribe does not apply 'kern' in Khmer. */
if (hb_options ().uniscribe_bug_compatible)
{
-plan->map.disable_feature (HB_TAG('k','e','r','n'));
+map->disable_feature (HB_TAG('k','e','r','n'));
}
- plan->map.disable_feature (HB_TAG('l','i','g','a'));
+ map->disable_feature (HB_TAG('l','i','g','a'));
}
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master'
src/hb-null.hh | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
New commits:
commit 282ce7230b8bd8ad65c408cdaf1499504038247d
Author: Behdad Esfahbod
Date: Thu Nov 29 12:18:14 2018 -0500
Fix "typename outside template" issues
Nothing an extra template class wouldn't fix...
Fixes https://github.com/harfbuzz/harfbuzz/issues/1419
diff --git a/src/hb-null.hh b/src/hb-null.hh
index 1583d5b9..dde4b2e9 100644
--- a/src/hb-null.hh
+++ b/src/hb-null.hh
@@ -77,6 +77,7 @@ struct hb_static_size
/*
* Null()
*/
+
extern HB_INTERNAL
hb_vector_size_impl_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof
(hb_vector_size_impl_t) - 1) / sizeof (hb_vector_size_impl_t)];
@@ -86,7 +87,13 @@ static inline Type const & Null (void) {
static_assert (hb_null_size (Type) <= HB_NULL_POOL_SIZE, "Increase
HB_NULL_POOL_SIZE.");
return *reinterpret_cast (_hb_NullPool);
}
-#define Null(Type) Null ()
+template
+struct NullHelper
+{
+ typedef typename hb_remove_const (typename hb_remove_reference (QType)) Type;
+ static inline const Type & get_null (void) { return Null (); }
+};
+#define Null(Type) NullHelper::get_null ()
/* Specializations for arbitrary-content Null objects expressed in bytes. */
#define DECLARE_NULL_NAMESPACE_BYTES(Namespace, Type) \
@@ -129,17 +136,23 @@ static inline Type& Crap (void) {
memcpy (obj, (Type), sizeof (*obj));
return *obj;
}
-#define Crap(Type) Crap ()
+template
+struct CrapHelper
+{
+ typedef typename hb_remove_const (typename hb_remove_reference (QType)) Type;
+ static inline Type & get_crap (void) { return Crap (); }
+};
+#define Crap(Type) CrapHelper::get_crap ()
template
-struct CrapOrNull {
+struct CrapOrNullHelper {
static inline Type & get (void) { return Crap(Type); }
};
template
-struct CrapOrNull {
- static inline Type const & get (void) { return Null(Type); }
+struct CrapOrNullHelper {
+ static inline const Type & get (void) { return Null(Type); }
};
-#define CrapOrNull(Type) CrapOrNull::get ()
+#define CrapOrNull(Type) CrapOrNullHelper::get ()
/*
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 2 commits
NEWS | 35 +++
configure.ac |2 +-
src/hb-aat-layout.cc |6 +++---
src/hb-aat-layout.h |4 ++--
src/hb-deprecated.h |4 ++--
src/hb-icu.cc|4 ++--
src/hb-ot-var.cc |8
src/hb-ot-var.h |4 ++--
src/hb-version.h |6 +++---
9 files changed, 54 insertions(+), 19 deletions(-)
New commits:
commit dc41ecef85b094b30c612113606597b91c55351c
Author: Behdad Esfahbod
Date: Thu Nov 29 11:53:53 2018 -0500
2.2.0
diff --git a/NEWS b/NEWS
index 9bfe99a2..ff4f6e29 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,38 @@
+Overview of changes leading to 2.2.0
+Thursday, November 29, 2018
+
+- Misc shaping bug fixes.
+- Add font variations named-instance API.
+- Deprecate font variations axis enumeration API and add replacement.
+- AAT shaping improvements:
+ o Fixed 'kern' table Format 2 implementation.
+ o Implement 'feat' table API for feature detection.
+ o Blacklist 'GSUB' table of fonts from 'MUTF' foundry that also have 'morx'.
+
+New API:
++hb_aat_layout_feature_type_t
++hb_aat_layout_feature_selector_t
++hb_aat_layout_get_feature_types()
++hb_aat_layout_feature_type_get_name_id
++hb_aat_layout_feature_selector_info_t
++HB_AAT_LAYOUT_NO_SELECTOR_INDEX
++hb_aat_layout_feature_type_get_selector_infos()
++hb_ot_var_axis_flags_t
++hb_ot_var_axis_info_t
++hb_ot_var_get_axis_infos()
++hb_ot_var_find_axis_info()
++hb_ot_var_get_named_instance_count()
++hb_ot_var_named_instance_get_subfamily_name_id()
++hb_ot_var_named_instance_get_postscript_name_id()
++hb_ot_var_named_instance_get_design_coords()
+
+Deprecated API:
++HB_OT_VAR_NO_AXIS_INDEX
++hb_ot_var_axis_t
++hb_ot_var_get_axes()
++hb_ot_var_find_axis()
+
+
Overview of changes leading to 2.1.3
Friday, November 16, 2018
diff --git a/configure.ac b/configure.ac
index e9db42a7..06494643 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
AC_PREREQ([2.64])
AC_INIT([HarfBuzz],
-[2.1.3],
+[2.2.0],
[https://github.com/harfbuzz/harfbuzz/issues/new],
[harfbuzz],
[http://harfbuzz.org/])
diff --git a/src/hb-aat-layout.cc b/src/hb-aat-layout.cc
index 727da42a..fae67800 100644
--- a/src/hb-aat-layout.cc
+++ b/src/hb-aat-layout.cc
@@ -318,7 +318,7 @@ _hb_aat_language_get (hb_face_t *face,
*
* Return value: Number of all available feature types.
*
- * Since: REPLACEME
+ * Since: 2.2.0
*/
unsigned int
hb_aat_layout_get_feature_types (hb_face_t*face,
@@ -336,7 +336,7 @@ hb_aat_layout_get_feature_types (hb_face_t
*face,
*
* Return value: Name ID index
*
- * Since: REPLACEME
+ * Since: 2.2.0
*/
hb_ot_name_id_t
hb_aat_layout_feature_type_get_name_id (hb_face_t*face,
@@ -358,7 +358,7 @@ hb_aat_layout_feature_type_get_name_id (hb_face_t
*face,
*
* Return value: Number of all available feature selectors.
*
- * Since: REPLACEME
+ * Since: 2.2.0
*/
unsigned int
hb_aat_layout_feature_type_get_selector_infos (hb_face_t
*face,
diff --git a/src/hb-aat-layout.h b/src/hb-aat-layout.h
index 5912e012..696e9033 100644
--- a/src/hb-aat-layout.h
+++ b/src/hb-aat-layout.h
@@ -39,7 +39,7 @@ HB_BEGIN_DECLS
* hb_aat_layout_feature_type_t:
*
*
- * Since: REPLACEME
+ * Since: 2.2.0
*/
typedef enum
{
@@ -92,7 +92,7 @@ typedef enum
* hb_aat_layout_feature_selector_t:
*
*
- * Since: REPLACEME
+ * Since: 2.2.0
*/
typedef enum
{
diff --git a/src/hb-deprecated.h b/src/hb-deprecated.h
index a74431f0..9ceb2648 100644
--- a/src/hb-deprecated.h
+++ b/src/hb-deprecated.h
@@ -247,7 +247,7 @@ typedef unsigned int hb_ot_name_id_t; /* Since is in
hb-ot.h */
* HB_OT_VAR_NO_AXIS_INDEX:
*
* Since: 1.4.2
- * Deprecated: REPLACEME
+ * Deprecated: 2.2.0
*/
#define HB_OT_VAR_NO_AXIS_INDEX0xu
@@ -255,7 +255,7 @@ typedef unsigned int hb_ot_name_id_t; /* Since is in
hb-ot.h */
* hb_ot_var_axis_t:
*
* Since: 1.4.2
- * Deprecated: REPLACEME
+ * Deprecated: 2.2.0
*/
typedef struct hb_ot_var_axis_t
{
diff --git a/src/hb-ot-var.cc b/src/hb-ot-var.cc
index 56d24817..e327fb76 100644
--- a/src/hb-ot-var.cc
+++ b/src/hb-ot-var.cc
@@ -79,7 +79,7 @@ hb_ot_var_get_axis_count (hb_face_t *face)
* hb_ot_var_get_axes:
*
* Since: 1.4.2
- * Deprecated: REPLACEME
+ * Deprecated: 2.2.0
**/
unsigned int
hb_ot_var_get_axes (hb_face_t*face,
@@ -94,7 +94,7 @@ hb_ot_var_get_axes (hb_face_t*face,
* hb_ot_var_find_axis:
*
* Since: 1.4.2
- * Deprecated: REPLACEME
+ * Deprecated: 2.2.0
**/
hb_bool_t
hb_ot_var_find_axis (hb_face_t*face,
@@ -108,7 +108,7 @@ hb_ot_var_find_axis (hb_face_t*face,
/**
* hb_ot_var_get_axis_infos:
*
- * Since: REPLACEME
+ * Since: 2.2.0
**/
HB_EXTERN unsigned int
hb_ot_var_get_axis_infos (hb_face_t *face,
@@ -122,7
[HarfBuzz] harfbuzz: Changes to 'refs/tags/2.2.0'
Tag '2.2.0' created by Behdad Esfahbod at 2018-11-29 16:54 + 2.2.0 -BEGIN PGP SIGNATURE- iHAEABECADAWIQQid2UKTovf5Lf2vkGf7gTl01MRFQUCXAAZrRIcYmVoZGFkQGJl aGRhZC5vcmcACgkQn+4E5dNTERU+6wCgofmjrmGBV5Gfhsld9Sp+jG9MEpwAoK2W L0na9jTmUsEAi+GYxTYiKFBi =7Z7H -END PGP SIGNATURE- Changes since 2.1.3-185: --- 0 files changed --- ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] harfbuzz: Branch 'master' - 7 commits
docs/usermanual-getting-started.xml |3 + src/hb-icu.cc |3 + test/shaping/data/in-house/Makefile.sources |1 test/shaping/data/in-house/fonts/e39391c77a6321c2ac7a2d644de0396470cd4bfe.ttf |binary test/shaping/data/in-house/tests/kern-format2.tests |3 + test/shaping/data/in-house/tests/macos.tests | 16 ++ 6 files changed, 18 insertions(+), 8 deletions(-) New commits: commit 0bcb1de1265368a27e53c6d935c965cbcb4130a0 Merge: e0307de8 a85886fc Author: Behdad Esfahbod Date: Thu Nov 29 10:39:18 2018 -0500 Merge pull request #1418 from gvictor/replace_icu_deprecated Replace @Deprecated ICU API - USCRIPT_CODE_LIMIT commit e0307de818ad1f70ef96938642bda61d7a62532a Author: Ebrahim Byagowi Date: Thu Nov 29 11:36:05 2018 +0330 [test][aat.kern] More (#1427) diff --git a/test/shaping/data/in-house/tests/macos.tests b/test/shaping/data/in-house/tests/macos.tests index 8bce2530..9fb46e8c 100644 --- a/test/shaping/data/in-house/tests/macos.tests +++ b/test/shaping/data/in-house/tests/macos.tests @@ -1,4 +1,4 @@ -# 10.12.6 +# 10.12.6 https://gist.github.com/ebraminio/1704341fa16b06979e605aafd88198cf /System/Library/Fonts/Helvetica.dfont@c7bec2785a4c402b7809b5e35337c3d24c18e281:--shaper ot --font-funcs ot:U+006D,U+0300:[m=0+1706|gravecmb=0@-284,10+0] /System/Library/Fonts/LucidaGrande.ttc@d89a9d7e57767bfe3b5a4cfd22bb1e9dbe03a062:--shaper ot --font-funcs ot:U+006D,U+0300:[mgrave=0+1912] /System/Library/Fonts/Times.dfont@39c954614d3f3317b28564db06d5b7b7a6ff0e39:--shaper ot --font-funcs ot:U+0066,U+0069:[fi=0+1139] @@ -7,14 +7,16 @@ /System/Library/Fonts/Times.dfont@39c954614d3f3317b28564db06d5b7b7a6ff0e39:--shaper ot --font-funcs ot:U+0041,U+0066,U+0300,U+0066,U+0069,U+005A:[A=0+1479|f=1+682|gravecmb=1@-480,588+0|fi=3+1139|Z=5+1251] /System/Library/Fonts/LucidaGrande.ttc@d89a9d7e57767bfe3b5a4cfd22bb1e9dbe03a062:--shaper ot --font-funcs ot:U+05E1,U+05B0:[shevahebrew=0@-7,0+0|samekhhebrew=0+1361] /Library/Fonts/Apple Chancery.ttf@5fc49ae9bce39e2105864323183b68ea34c9e562:--shaper ot --font-funcs ot:U+0054,U+0068,U+0020,U+0074,U+0068,U+0020,U+006C,U+006C,U+0020,U+0074,U+0065,U+0020,U+0074,U+006F,U+0020,U+0074,U+0072,U+0020,U+0066,U+0072,U+0020,U+0066,U+0075,U+0020,U+0066,U+006A:[T_h=0+2308|space=2+569|t_h=3+1687|space=5+569|l_l=6+1108|space=8+569|t_e=9+1408|space=11+569|t_o=12+1531|space=14+569|t_r=15+1385|space=17+569|f_r=18+1432|space=20+569|f_u=21+1733|space=23+569|f_j=24+1098] +/Library/Fonts/Apple Chancery.ttf@5fc49ae9bce39e2105864323183b68ea34c9e562:--shaper ot --font-funcs ot:U+0054,U+0065,U+0020,U+0041,U+0056,U+0020,U+0054,U+0072,U+0020,U+0056,U+0061,U+0020,U+0072,U+0054,U+0020,U+0065,U+0054,U+0020,U+0054,U+0064:[T=0+1497|e=1@-62,0+699|space=2+569|A=3+1431|V=4@-37,0+1377|space=5+569|T=6+1510|r=7@-50,0+803|space=8+569|V=9+1376|a=10@-37,0+1014|space=11+569|r=12+853|T=13+1560|space=14+569|e=15+761|T=16+1560|space=17+569|T=18+1515|d=19@-45,0+1006] /System/Library/Fonts/GeezaPro.ttc@f43ee7151c2e9f1dddfbc26cfc148609eb5c5820:--shaper ot --font-funcs ot:U+0627,U+0644,U+0623,U+064E,U+0628,U+0652,U+062C,U+064E,U+062F,U+0650,U+064A,U+064E,U+0651,U+0629,U+0640,U+0627,U+0644,U+0639,U+064E,U+0631,U+064E,U+0628,U+0650,U+064A,U+064E,U+0651,U+0629:[u0629.final.tehMarbuta=26+713|u064e_u0651.shaddaFatha=23@0,-200+0|u064a.medial.yeh=23+656|u0650.kasra=21@80,290+80|u0628.initial.beh=21@-80,0+576|u064e.fatha=19@200,-570+200|u0631.final.reh=19@-200,0+702|u064e.fatha=17@200,-200+200|u0639.medial.ain=17@-200,0+738|u0644.initial.lam=16+515|u0627.final.alef=15+647|u0640.tatweel=14+449|u0629.final.tehMarbuta=13+713|u064e_u0651.shaddaFatha=10@0,-200+0|u064a.initial.yeh=10+656|u0650.kasra=8@80,570+80|u062f.final.dal=8@-80,0+822|u064e.fatha=6@290,-160+290|u062c.medial.jeem=6@-290,0+1069|u0652.sukun=4@0,-200+0|u0628.initial.beh=4+656|u064e.fatha=1@-252,120+-252|u0644_u0623.isolated.lamHamzaOnAlef=1@120,0+1282|u0627.alef=0+647] /System/Library/Fonts/GeezaPro.ttc@f43ee7151c2e9f1dddfbc26cfc148609eb5c5820:--shaper ot --font-funcs ot:U+0628,U+064A,U+064E,U+0651,U+0629:[u0629.final.tehMarbuta=4+713|u064e_u0651.shaddaFatha=1@0,-200+0|u064a.medial.yeh=1+656|u0628.initial.beh=0+656] /System/Library/Fonts/GeezaPro.ttc@f43ee7151c2e9f1dddfbc26cfc148609eb5c5820:--shaper ot --font-funcs ot:U+0631,U+0628:[u0628.beh=1+1415|u0631.reh=0@-202,0+700] /System/Library/Fonts/GeezaPro.ttc@f43ee7151c2e9f1dddfbc26cfc148609eb5c5820:--shaper ot --font-funcs ot:U+0628,U+064F:[u064f.damma=0@250,-250+250|u0628.beh=0@-250,0+1165] -/System/Library/Fonts/SFNSDisplay.ttf@92787c30716672737e9059bc367c15d04fbc1ced:--shaper ot --font-funcs ot:U+0056,U+0041,U+0056,U+0041:[gid265=0+1227|gid4=1@-65,0+1162|gid265=2@-65,0+1162|gid4=3@-65,0+1227] +/System/Library/Fonts/SFNSDisplay.ttf
