Re: [ft-devel] Speeding up PNG loading

On Mon, Aug 14, 2017 at 11:52 PM, Werner LEMBERG wrote: > > Check the branch now: > > https://github.com/behdad/freetype/commit/40112725e9041a5e3f2878e71bdd08 > 249beaa743 > > > > I think this is good enough to go in. What do you think? > > Committed, thanks, with some additional

Re: [ft-devel] Loading empty bitmap fails?

On Fri, Aug 11, 2017 at 12:36 AM, Werner LEMBERG wrote: > > >> ??? How shall I map GID 3 to a space glyph if there isn't an > >> advance width or height? Not returning an error for a glyph > >> without any metrics smells very fishy. > > > > As it happens, hmtx / vmtx tables

Re: [ft-devel] Speeding up PNG loading

On Mon, Aug 14, 2017 at 12:32 AM, Werner LEMBERG wrote: > > > I thought I see if I can speed up PNG loading by vectorizing alpha > > premultiplication, and it actually does give a nice speedup: [...] > > Nice! > > > The code is rather terse but readable. I can add comments. > >

Re: [ft-devel] Speeding up PNG loading

Check the branch now: https://github.com/behdad/freetype/commit/40112725e9041a5e3f2878e71bdd08249beaa743 I think this is good enough to go in. What do you think? On Mon, Aug 14, 2017 at 11:56 AM, Behdad Esfahbod <beh...@behdad.org> wrote: > On Mon, Aug 14, 2017 at 12:32 AM, Werner L

Re: [ft-devel] New `slight' auto-hinting mode

Thanks Werner for the detailed message! On Thu, Apr 27, 2017 at 10:46 PM, Werner LEMBERG wrote: > > What do you think? Shall I remove (3c), enforcing (3a) to all users? > Or shall the new mode stay? It's easy to revert the changes, if you > can convince me :-) > I prefer you

Re: [ft-devel] Loading empty bitmap fails?

On Fri, Aug 4, 2017 at 9:52 PM, Werner LEMBERG wrote: > > > With color fonts, I'm finding that loading space character is > > failing with FreeType even though there's cmap entry in the font. > > It should result in empty glyph bitmap IMO. NotoColorEmoji > > reproduces for me, as

Re: [ft-devel] Major bug with varfonts named instances when avar table present

On Tue, Aug 1, 2017 at 3:13 PM, Werner LEMBERG wrote: > >> It's fully OK to restrict the possible indices *for this specific > >> case* to 6, 256-32767, and 0x. > > > > What do you mean "fully OK to restrict"? Do you think the spec > > saying so stops font developers from

Re: [ft-devel] Major bug with varfonts named instances when avar table present

On Tue, Aug 1, 2017 at 11:31 AM, Werner LEMBERG wrote: > >> This is not necessary, AFAICS. `psid' defaults to zero (this happens > >> during allocation of the structure), which isn't a valid value. I've > >> documented that properly. > > > > Humm?? Nameid zero is very valid... >

[ft-devel] OT 1.8.2 defines hidden axes in fvar...

Not sure how to expose that, or don't. ;) -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Major bug with varfonts named instances when avar table present

Werner, If avar is present, loading of named instances goes wrong. Patch attached. Also fixes what I think was an unset psid for named instances. This is a major issue for varfonts. Would be great if you can get it in a release ASAP. Thanks, -- behdad http://behdad.org/ diff --git

Re: [ft-devel] OT 1.8.2 defines hidden axes in fvar...

On Tue, Aug 1, 2017 at 7:13 AM, Werner LEMBERG wrote: > > > Not sure how to expose that, or don't. ;) > > Yeah, I'm thinking about this issue already since two weeks... > > IMHO, it should be exposed. The most straightforward way would to > break backwards compatibility,

[ft-devel] Speeding up PNG loading

Hi, I thought I see if I can speed up PNG loading by vectorizing alpha premultiplication, and it actually does give a nice speedup: commit d7d592b0acb25ad8084b1d60459dd40bfd9c3356 (HEAD -> png-faster, github/png-faster) Author: Behdad Esfahbod <beh...@behdad.org> Date: Tue Aug 8 21:2

Re: [ft-devel] Loading empty bitmap fails?

On Sun, Aug 6, 2017 at 3:27 AM, Werner LEMBERG wrote: > >> Indeed. Can you give me pointers to the OpenType specification where > >> this situation is covered? Currently, I don't find it... > > > > I cannot, because as it happens nowhere it says that it is an error > > if a

Re: [ft-devel] Loading empty bitmap fails?

On Sun, Aug 6, 2017 at 10:44 PM, Werner LEMBERG wrote: > > >> Mhmm. I would like to have this formalized. Let's have a closer > >> look at NotoColorEmoji.ttf. The `cmap' table references glyph > >> index 3 for character code 0x20 (ttx calls this glyph `space'). > >> GID 3 is

Re: [ft-devel] problems with synthetic cmaps

Please, don't add more magic to FreeType. Just remove old magic... On Wed, Aug 16, 2017 at 7:11 AM, Werner LEMBERG wrote: > > Alexei, > > > there is a bug report > > https://bugs.chromium.org/p/chromium/issues/detail?id=754574 > > that directly affects synthesized cmaps. The

Re: [ft-devel] Freetype 2.8 bitmap font no linear advance

Not all formats have the concept of units-per-EM, so the non-scaled advance is not well-defined. On Tue, Aug 22, 2017 at 11:55 AM, J Decker wrote: > On the font 'c:/windows/fonts/c8514fix.fon' > > This is basically the code I used... > > FT_Library library; > FT_Face face; >

Re: [ft-devel] gasp table support

No more states in the library please (ie. driver property). Why not another load flag? To me, what matters most is that bytecode is NOT run if the gasp says it shouldn't be run. On Sat, May 20, 2017 at 8:10 AM, Nikolaus Waxweiler wrote: > > This is exactly the question.

Re: [ft-devel] FontVal 2.2 plan and the enums

On Sat, Sep 16, 2017 at 6:52 AM, Hin-Tak Leung wrote: > Hi Werner and others, > > I am going to just say it once - I am not happy that somebody tries to > create a incompatable fork of Font Validator''s backend code, breaking it > up, while contributing nothing code

Re: [ft-devel] Duplicate default instance as named-instance

On Tue, Sep 19, 2017 at 5:35 PM, Adam Twardoch (List) < list.a...@twardoch.com> wrote: > FreeType should not rely on the presence of named instances. > It doesn't. > > Sent from my mobile phone. > > On 19. Sep 2017, at 21:50, Behdad Esfahbod <beh...@behdad.org>

[ft-devel] Duplicate default instance as named-instance

Werner, I just want to say that I don't like this commit: commit 27fee7f8c6ae75e066b5a23472b33925c6e8b1e0 Author: Werner Lemberg Date: Mon Mar 6 20:45:44 2017 +0100 [sfnt, truetype] Always provide default instance. The default instance does NOT need a named instance.

Re: [ft-devel] glyph metrics don't match bitmap size (2.8.1)

On Mon, Sep 18, 2017 at 10:33 PM, Werner LEMBERG wrote: > > > I've managed to render text correctly now using LCD filtering (the > > new 2.8.1 version). I was able to do it by ignoring the glyph > > metrics and using the bitmap size itself. This works well enough for > > now, and

Re: [ft-devel] glyph metrics don't match bitmap size (2.8.1)

On Wed, Sep 20, 2017 at 10:15 AM, Behdad Esfahbod <beh...@cs.toronto.edu> wrote: > On Mon, Sep 18, 2017 at 10:33 PM, Werner LEMBERG <w...@gnu.org> wrote: > >> >> > I've managed to render text correctly now using LCD filtering (the >> > new 2.8.1 version).

Re: [ft-devel] Problem with FT_Get_MM_Var

Just checking. Matthias, you have the latest FreeType, right? On Tue, Sep 19, 2017 at 4:35 AM, Matthias Clasen wrote: > On Tue, Sep 19, 2017 at 5:04 AM, Werner LEMBERG wrote: > >> >> > The cairo code I see this problem with essentially does: >> > >> >

Re: [ft-devel] glyph metrics don't match bitmap size (2.8.1)

On Wed, Sep 20, 2017 at 2:10 PM, Nicolas Jinchereau < nicolas.jincher...@gmail.com> wrote: > What about adding FT_RENDER_MODE_NONE = -1 to FT_Render_Mode_? > The enum should still be representable by the same size int. > > Or maybe a better name than FT_RENDER_MODE_NONE that specifies the >

Re: [ft-devel] Problem with FT_Get_MM_Var

Too old. You need this fix that went into 2.8.1: https://github.com/behdad/freetype/commit/55bbb98f5c5a89230127d6b998a6e23e634b5d0e On Wed, Sep 20, 2017 at 2:59 PM, Matthias Clasen wrote: > Using freetype-2.8-5.fc27.x86_64 here. > > > > -- behdad

[ft-devel] Wrong postscriptname for base font

Hi Werner, If I call FT_Set_Var_Design_Coordinates (face, 0, NULL), I expect postscriptname to revert to the one for the base font. But I seem to be getting a different name. Eg.: 21c20 < postscriptname: "VotoSerifGX"(s) --- > postscriptname: "VotoSerifGX-129100"(s) Looks like there's

[ft-devel] postscriptname changes if FT_Get_MM_Var() is called

I have a font, postscriptname returned by FreeType is NotoSansArabic-Regular (correct). As soon as I call FT_Get_MM_Var(), then postscriptname returned changes to NotoSansArabic. -- behdad http://behdad.org/ ___ Freetype-devel mailing list

[ft-devel] Speeding up afshaper.c

turn 3; if (FT_Done_Face (face)) return 4; } return 0; } commit 2c2df60405260094d8f73abd79175ca83946c372 Author: Behdad Esfahbod <beh...@behdad.org> Date: Fri Oct 13 12:06:09 2017 +0200 [afshaper] Delay creating hb_set objects until needed In runs on Noto Naskh Arabic,

Re: [ft-devel] Rounding issue

Thanks for checking. On Fri, Oct 13, 2017 at 9:17 AM, Werner LEMBERG wrote: > > > Please see https://github.com/behdad/harfbuzz/issues/551 > > > > With this font (I *think* it was Noto Sans Bengali), > > No, it's `Lohit Assamese' (according to the font's `name' table entry). > > >

Re: [ft-devel] Upstreaming freetype diagnostics patches

Dude. Stop being a jerk! We're all friends here. On Sep 11, 2017 8:44 AM, "Hin-Tak Leung" wrote: > a couple of things. > > - the symbol export list needs to be optional also. (conditional on a > configure flag or something) > > - in general, if you want to upstream

Re: [ft-devel] Patent info for LCD subpixel filter

On Sat, Sep 2, 2017 at 5:16 PM, Werner LEMBERG wrote: > > > At least in the English that I learned, two things that are not the > > same are different. So I find the claim that "they are more same > > than different, as such are not different" to be patently false. > > ??? What

Re: [ft-devel] TrueType kern table subtable format ignored?

On Sun, Sep 10, 2017 at 5:53 AM, Werner LEMBERG wrote: > > > To be exact, tt_face_get_kerning() "handles" Format 2 by ignoring > > it. It's tt_face_load_kern() that does not check format at all. > > > >> Am I right in reading ttkern.c, that the subtable format is ignored > >> and

Re: [ft-devel] TrueType kern table subtable format ignored?

To be exact, tt_face_get_kerning() "handles" Format 2 by ignoring it. It's tt_face_load_kern() that does not check format at all. On Sun, Sep 10, 2017 at 5:03 AM, Behdad Esfahbod <beh...@behdad.org> wrote: > Hi, > > Am I right in reading ttkern.c, that the s

[ft-devel] TrueType kern table subtable format ignored?

Hi, Am I right in reading ttkern.c, that the subtable format is ignored and always assumes to be Format 0? Sounds wrong to me. -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] TrueType kern table subtable format ignored?

On Sun, Sep 10, 2017 at 11:49 AM, Werner LEMBERG wrote: > > >> Give me a format 2 kerning table, and I'm going to add support for > >> it immediately. > > > > I'm working on it! > > Great! However, I wonder whether there exist *real* fonts with such a > kerning table... > I want

Re: [ft-devel] TrueType kern table subtable format ignored?

On Sun, Sep 10, 2017 at 11:18 PM, Werner LEMBERG wrote: > >> Indeed. So... Awaiting your demo font :-) > > > > I'm not going to make demo fonts, but *real* fonts. > > Hmm. Why? Kerning table format 2 is not supported on Windows, > AFAIK. Why not directly using GPOS kerning? >

[ft-devel] Rounding issue

Hi Werner, Please see https://github.com/behdad/harfbuzz/issues/551 With this font (I *think* it was Noto Sans Bengali), font has upem 769, and a glyph has advance of 520. In hb-ft, I'm asking FreeType for size 769/64.; the end result is the advance I get back from FreeType is 519 on some

Re: [ft-devel] Patent info for LCD subpixel filter

At least in the English that I learned, two things that are not the same are different. So I find the claim that "they are more same than different, as such are not different" to be patently false. On Sep 1, 2017 11:47 PM, "Werner LEMBERG" wrote: > > > I am contacting you to have

Re: [ft-devel] Arabic font

Implementing your own text rendering system is a huge task. I suggest you start with incorporating libraqm. On Sat, Nov 25, 2017 at 6:42 AM, Nikolaus Waxweiler wrote: > Hey Ivan, > not sure you posted to the correct mailing list. You probably better > ask on the Harfbuzz

[ft-devel] Minor FT_Set_Var_Design_Coordinates() request

Hi Werner, Is there any chance you can modify FT_Set_Var_Design_Coordinates() to detect when the set face coordinates are not changed and shortcircuit out early? Currently, if one calls that function too often (say, for every glyph load, which is how we want to call it in cairo), it causes font

Re: [ft-devel] completed CPAL/COLR support

30, 2018 at 12:19 AM, Behdad Esfahbod wrote: > I haven't got time to fully review the API. But just taking a look now, in > the example in freetype.h: >* if ( palette && layer_glyph_index ) >* { >* do >* { >*

Re: [ft-devel] completed CPAL/COLR support

I haven't got time to fully review the API. But just taking a look now, in the example in freetype.h: * if ( palette && layer_glyph_index ) * { * do * { * FT_Color layer_color = palette[layer_color_index]; * * * // Load and render glyph

[ft-devel] Fwd: completed CPAL/COLR support

Forwarding using my correct address, so it makes it to the list. On Sat, Jun 30, 2018 at 1:55 AM, Werner LEMBERG wrote: > > > I haven't got time to fully review the API. But just taking a look > > now, in the example in freetype.h: > > > > if ( palette && layer_glyph_index ) > > { > >

Re: [ft-devel] Fwd: completed CPAL/COLR support

On Sat, Jun 30, 2018 at 3:03 AM, Werner LEMBERG wrote: > > >> > Third, "palette[layer_color_index]" is recipe for invalid memory > >> > access. > >> > >> Is it? The code checks that `layer_color_index' is not out of > >> bound. Do you have a better idea? > > > > What does the code do if the

Re: [ft-devel] completed CPAL/COLR support

On Sat, Jun 30, 2018 at 1:55 AM, Werner LEMBERG wrote: > > > I haven't got time to fully review the API. But just taking a look > > now, in the example in freetype.h: > > > > if ( palette && layer_glyph_index ) > > { > >do > >{ > > FT_Color layer_color =

[ft-devel] Disable ROUND_XY_TO_GRID in not hinting

Hi, I believe FreeType should disable ROUND_XY_TO_GRID processing if hinting is disabled. Likewise, maybe disable the X rounding if hinting mode does not apply to X direction. WDYT? Came across this as part of https://github.com/googlei18n/noto-fonts/issues/1009 -- behdad http://behdad.org/

[ft-devel] How to free FT_MM_Var?

Hi Werner, The docs say return value of FT_Get_MM_Var() should be freed by calling "free()". But given this is allocated using FT_ALLOC(), shouldn't caller use FT_FREE()? Thanks, -- behdad http://behdad.org/ ___ Freetype-devel mailing list

Re: [ft-devel] FreeType DLL support (Re: Freetype-devel Digest, Vol 156, Issue 12)

Hin-Tak: You don't have to be rude to people. It's ok to be wrong. Stick to the technical point. Thanks. On Fri, Jan 12, 2018 at 10:34 PM, Hin-Tak Leung wrote: > > > On Sat, 13/1/18, Martin Gieseking

Re: [ft-devel] LD version script

e can > mitigate the hassle. > > And, now for another idiom: that's just my two cents. > > Regards, > > Tom > > On Tue, Jan 30, 2018 at 3:03 PM, Behdad Esfahbod <beh...@cs.toronto.edu> > wrote: > >> I know what symbol versioning is used for (I was also packag

Re: [ft-devel] LD version script

I know what symbol versioning is used for (I was also package maintainer at Red Hat for four years). But don't see how it applies to FreeType. FreeType never changes ABI in backward-incompatible way. Its build system is already adhoc enough. I don't want to see more complexity added unnecessarily.

Re: [ft-devel] LD version script

If none of us know what problem this is fixing, maybe you shouldn't make any changes. On Sun, Jan 28, 2018 at 1:43 PM, Werner LEMBERG wrote: > > >>> I would consider, maybe, providing the version mapfile in the > >>> builds/unix/ folder, with regular upgrades as a part of the >

Re: [ft-devel] LLP64 model outside Win64

On Feb 11, 2018 8:15 PM, "Alexei Podtelezhnikov" wrote: (void *)(((char *)0) + (x)) > > Wow! Very cool! > > > I'm fairly sure that's undefined in C standard as well. (void *)((char *)NULL + (x)) ?? Yes. C99 has: """ 8 When an expression that has integer

Re: [ft-devel] LLP64 model outside Win64

On Feb 11, 2018 7:53 PM, "Alexei Podtelezhnikov" wrote: >>> >>> (void *)(((char *)0) + (x)) >>> Wow! Very cool! I'm fairly sure that's undefined in C standard as well. ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] How to determine if horizontal hinting is happening?

On Tue, Feb 20, 2018 at 11:04 AM, Alexei Podtelezhnikov wrote: > >> > >> > I think Skia does, by default, a 4x1 subpixel grid. > >> > >> ... which is almost the same as 3x1, which you would get for free from > >> LCD rendering with 3 channels shifted by 1/3.. 4x1 is such a

Re: [ft-devel] How to determine if horizontal hinting is happening?

Hi Alexei, Chromium, on many configurations, does do subpixel positioning. Just because we say that, doesn't mean it doesn't cache bitmaps. I think Skia does, by default, a 4x1 subpixel grid. That's implementation details though. On Tue, Feb 20, 2018 at 9:01 AM, Alexei Podtelezhnikov

Re: [ft-devel] How to determine if horizontal hinting is happening?

On Tue, Feb 20, 2018 at 10:35 AM, Alexei Podtelezhnikov wrote: > Adam, Behdad, thank you... > > > Chromium, on many configurations, does do subpixel positioning. > > Indeed I now see beautiful variations in LCD glyph images in the bug > report. You would not want to ruin that

Re: [ft-devel] Head table upem value from FT_Face for (color) bitmap fonts?

Exposing it sounds right to me, for the same reasons you identify. On Fri, Feb 16, 2018 at 5:23 AM, Dominik Röttsches wrote: > Hi, > > When instantiating FT_Face's from sbix or cbdt/cblc color fonts, the > units_per_EM value on FT_Face is 0, which currently seems to be

Re: [ft-devel] New FreeType release within a week

On Sat, Dec 30, 2017 at 1:41 PM, Werner LEMBERG wrote: > > Folks, > > > I want to make a new FreeType release within a week, if possible. > Some issues. > > . Behdad, please provide a problematic example w.r.t. conversion of > design to blend coordinates. > Set blend

[ft-devel] FT_[SG]et_Var_Design_Coordinates() / FT_[SG]et_Var_Blend_Coordinates() interactions

Hi again, I'm hitting a problem with FreeType / HarfBuzz / Cairo interaction for variable fonts that is easiest solved in FreeType. Currently, if one sets Blend coordinates, then gets Design coordinates, the returned design coordinates do not reflect the set blend coordinates. Can you please

Re: [ft-devel] [freetype2] master 6a97c95: [pcf] Revert massive unsigning.

Any comments on why? What failed? (Not that I think massive sign changes are sane..) On Wed, Aug 8, 2018 at 7:17 PM, Alexei Podtelezhnikov wrote: > branch: master > commit 6a97c95800e8a76e9595791042d74dd3fbf02f50 > Author: Alexei Podtelezhnikov > Commit: Alexei Podtelezhnikov > > [pcf]

Re: [ft-devel] COLR/CPAL

Looks like my config thinks TT_CONFIG_OPTION_COLOR_LAYERS is disabled... On Mon, Jul 16, 2018 at 12:31 PM, Behdad Esfahbod wrote: > On Sat, Jul 14, 2018 at 9:15 PM, Werner LEMBERG wrote: > >> >> > Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL >> &g

Re: [ft-devel] COLR/CPAL

Why does builds/unix/ftoption.h not have TT_CONFIG_OPTION_COLOR_LAYERS? I also never understood why there are three ftoption.h files... On Mon, Jul 16, 2018 at 12:37 PM, Behdad Esfahbod wrote: > Looks like my config thinks TT_CONFIG_OPTION_COLOR_LAYERS is disabled... > > On Mon, Jul

Re: [ft-devel] COLR/CPAL

On Sat, Jul 14, 2018 at 9:15 PM, Werner LEMBERG wrote: > > > Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL > > fonts. Any idea? > > How do you come to this impression? There is the following code in > `sfobjs.c' around line 1405: > > if ( face->sbit_table_type ==

Re: [ft-devel] COLR/CPAL

On Mon, Jul 16, 2018 at 1:51 PM, Werner LEMBERG wrote: > > > Why does builds/unix/ftoption.h not have > > TT_CONFIG_OPTION_COLOR_LAYERS? > > There is no such file in the git repository; it's a generated file... > Ok, then the build system is broken and not updating that one... > > I also

Re: [ft-devel] COLR/CPAL

After a minor cairo patch, I can now see Segoe UI Emoji rendered with hb-view (and I suppose rest of GNOME). On Mon, Jul 16, 2018 at 1:56 PM, Behdad Esfahbod wrote: > On Mon, Jul 16, 2018 at 1:51 PM, Werner LEMBERG wrote: > >> >> > Why does builds/uni

[ft-devel] COLR/CPAL

Hi, Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL fonts. Any idea? -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] master 300da33 1/2: * src/truetype/ttgxvar.c (ft_var_get_item_delta): Optimized.

@584,0|C@1196,0] 1 tests failed. FAIL tests/HVAR-1.tests (exit status: 1) On Thu, Nov 1, 2018 at 6:24 PM Behdad Esfahbod wrote: > And you broke it. Four of the > harfbuzz/test/shaping/data/text-rendering-tests fail with this. > > I actually appreciate if you don't touch that code. I

Re: [ft-devel] [freetype2] master 300da33 1/2: * src/truetype/ttgxvar.c (ft_var_get_item_delta): Optimized.

And you broke it. Four of the harfbuzz/test/shaping/data/text-rendering-tests fail with this. I actually appreciate if you don't touch that code. It's been put in place *very* carefully. On Wed, Oct 31, 2018 at 10:02 PM Alexei Podtelezhnikov wrote: > branch: master > commit

Re: [ft-devel] [freetype2] master 300da33 1/2: * src/truetype/ttgxvar.c (ft_var_get_item_delta): Optimized.

tiplies together. Thanks. If you really care about excessive rounding error though, bug report about not rounding deltas to FUnits is much more "immediate". On Fri, Nov 2, 2018 at 9:25 AM Behdad Esfahbod wrote: > On Thu, Nov 1, 2018 at 9:59 PM Alexei Podtelezhnikov > wrote: >

Re: [ft-devel] [freetype2] master 300da33 1/2: * src/truetype/ttgxvar.c (ft_var_get_item_delta): Optimized.

On Thu, Nov 1, 2018 at 9:59 PM Alexei Podtelezhnikov wrote: > > And you broke it. Four of the > harfbuzz/test/shaping/data/text-rendering-tests fail with this. > > I made it more accurate with less rounding error while still > standard-compliant and faster too. > This doesn't sound like

Re: [ft-devel] some ClearType patents expired

All Micrsofot patents are free to use as of four weeks ago: https://azure.microsoft.com/en-us/blog/microsoft-joins-open-invention-network-to-help-protect-linux-and-open-source/ On Wed, Nov 7, 2018 at 4:37 PM Alexei Podtelezhnikov wrote: > Hi guys, > > Most ClearType patents had 1998-10-07 as

Re: [ft-devel] Logging library proposal

Werner, Please don't use an external library. Logging in FreeType is for developers only, and some parts maybe for font designers. Clients who just want to render text don't need the logging capabilities. Just keep it simple. On Mon, Jan 21, 2019 at 4:35 PM Yash Khasbage wrote: > Hi > I

Re: [ft-devel] Logging library proposal

On Tue, Jan 22, 2019 at 11:47 AM Werner LEMBERG wrote: > > Of course. Only if some preprocessor macros are defined at configure > time, this feature is available – I won't change that. In other > words, it will stay as a developer-only feature. Right. Which makes using en external library

Re: [ft-devel] color framework

On Tue, Dec 11, 2018 at 11:49 PM Alexei Podtelezhnikov wrote: > Hi all, > > I have just pushed out a new branch called color. This is a framework > and renderer for color glyphs, which Werner and I discussed offline. > The basic idea is to supplement outlines with color information for > each

Re: [ft-devel] color framework

As long as you don't break cairo and Chrome, I don't care what you do. On Thu, Dec 13, 2018 at 10:04 AM Alexei Podtelezhnikov wrote: > >> Once the TrueType loader learns to combine > >> all layers into a single outline and fill color information, it is > >> good to go. Just load and render

Re: [ft-devel] color framework

On Thu, Dec 13, 2018 at 10:27 AM Alexei Podtelezhnikov wrote: > On Thu, Dec 13, 2018 at 10:23 AM Behdad Esfahbod > wrote: > > > > As long as you don't break cairo and Chrome, I don't care what you do. > > > > That is not how it works. Please help up to make Free

Re: [ft-devel] color framework

On Thu, Dec 13, 2018 at 12:28 PM Alexei Podtelezhnikov wrote: > > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into > the bitmap, cairo/Chrome will work fine and I have no problem with that. > > This is just unfair. FreeType is not paid by or owned by Google. Did I imply

Re: [ft-devel] color framework

On Fri, Dec 14, 2018 at 8:25 AM Alexei Podtelezhnikov wrote: > >> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered > into the bitmap, cairo/Chrome will work fine and I have no problem with > that. > > > >> You started to use unreleased features. > > > > FT_LOAD_COLOR has been

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

On Tue, Dec 18, 2018 at 11:43 AM Nikolaus Waxweiler wrote: > Thanks Alexei for chiming in at > https://github.com/googlei18n/fontmake/issues/492#issuecomment-448249543. > > > The following seems to be different: hhea does not seem to be used in > VF. Compare and decide which one is correct. > >

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

On Thu, Dec 20, 2018 at 6:02 AM Nikolaus Waxweiler wrote: > > This is certainly the most convenient solution for me since I have > > nothing to do on the FreeType side :-) > > (As an aside, GTK/Pango seem to make the same mistake as TextEdit then, > putting the line gap at the bottom instead of

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

On Thu, Dec 20, 2018 at 5:32 AM Werner LEMBERG wrote: > > > I just tested the static and variable fonts in macOS 10.14 TextEdit. > > For the static instances, it presumably takes the hhea metrics, for > > the VF, it always takes typo metrics. (It also adds the line gap at > > the bottom, making

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

On Sat, Dec 22, 2018 at 8:43 AM Nikolaus Waxweiler wrote: > > There's also the question of whether MVAR tags should apply to > > whatever was used for ascent/descent. I think yes. And I'll > > implement that in HB. > > What would you do when > > 1. the typo metrics are modified by the MVAR

Re: [ft-devel] color framework

On Sat, Dec 15, 2018 at 11:10 PM Alexei Podtelezhnikov wrote: > > FreeType is about to make a major leap into color rendering. Is it? Color rendering was the news before variable-fonts were news. So 2013. The world has moved on. > It is > possible to make it right while keeping rendering

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

On Sat, Dec 22, 2018 at 11:23 AM Nikolaus Waxweiler wrote: > > > The thinking within the working group was that no one uses win > > metrics, so we didn't encode their variations. Indeed, the only time > > one uses them these days is if typo and hhea metrics are not set... > > > > But MVAR tags

Re: [ft-devel] color framework

On Thu, Dec 13, 2018 at 11:55 AM Werner LEMBERG wrote: > > >> > As long as you don't break cairo and Chrome, I don't care what > >> > you do. > > > > [...] and annoyed that you change things without caring about > > breaking things. > > ??? What do we break? COLR/CPAL support will be *new* in

[ft-devel] RC

I'm trying to cross-compile FreeType for win32/64 using mingw32/64 on Linux. However, I get build fail with libtool not understanding "RC": behdad:winbuild 0$ make /home/behdad/ft/winbuild/libtool --tag=RC --mode=compile @RC@ -o /home/behdad/ft/winbuild/ftver.lo /home/behdad/ft/src/base/ftver.rc

Re: [ft-devel] RC

On Fri, Sep 14, 2018 at 12:22 AM, Alexei Podtelezhnikov wrote: > On Thu, Sep 13, 2018 at 5:29 PM Behdad Esfahbod wrote: > > > > I'm trying to cross-compile FreeType for win32/64 using mingw32/64 on > Linux. However, I get build fail with libtool not understanding "

Re: [ft-devel] color framework

On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov wrote: > FT_Render_Glyph used to be democratic. The renderers were chosen based > on the match between the glyph format and the rendering mode. The only > way to keep it this way is either FT_RENDER_MODE_BGRA or > FT_GLYPH_FORMAT_LAYERED.

Re: [ft-devel] color framework

On Tue, Dec 18, 2018 at 5:35 AM Werner LEMBERG wrote: > > >> FreeType is about to make a major leap into color rendering. > > > > Is it? Color rendering was the news before variable-fonts were > > news. So 2013. The world has moved on. > > You completely misunderstood. Alexei talks about

Re: [ft-devel] color framework

On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov wrote: > On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov > wrote: > > > Alexei, I think we miscommunicate. > > > > I struggle to get your attention to FT_Glyph_To_Bitmap. > > I just discovered that, while ignoring the FT_Glyph

[ft-devel] Savannah downloads broken?

When trying to download this: http://download.savannah.gnu.org/freetype/freetype-2.9.tar.bz2 which is linked from: http://download.savannah.gnu.org/releases/freetype/ I get a 404. Our HarfBuzz CI bots are hitting this. Any idea? -- behdad http://behdad.org/

Re: [ft-devel] Savannah downloads broken?

On Thu, Apr 4, 2019, 12:40 AM Werner LEMBERG wrote: > > Hello Behdad! > > > > When trying to download this: > > > > http://download.savannah.gnu.org/freetype/freetype-2.9.tar.bz2 > > > > which is linked from: > > > > http://download.savannah.gnu.org/releases/freetype/ > > Is it? It was

Re: [ft-devel] what FT_Color

Skia has been rendering color fonts to billions of devices for over five years now, based on existing FreeType. Patches existed for cairo for the same time and were finally integrated last year. This idea that something big in FreeType has happened re color recently sounds detached from reality

Re: [ft-devel] Potential Timing Side-channel in Freetype Library

On Tue, Feb 19, 2019 at 2:27 AM Werner LEMBERG wrote: > > > We're a group of researchers from University of California > > Riverside. We recently discovered that the outline processing (font > > translation/decomposition) subroutine in the Freetype version 2.9.1 > > takes variable amount of time

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

.png > https://i.postimg.cc/PJjQhWrT/Bildschirmfoto-vom-2019-01-31-00-09-56.png > > Text becomes compressed. > Am Do, 31. Jan, 2019 um 12:38 A. M. schrieb Behdad Esfahbod > : > > That's what line-gap is: gap between consecutive lines. There is no > > line before the first line, an

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

That's what line-gap is: gap between consecutive lines. There is no line before the first line, and as such, no gap. On Wed, Jan 30, 2019 at 4:37 PM Nikolaus Waxweiler wrote: > Even more testing. > > ftview and Qt actually do the same GTK does: they don't add the line > gap to the top, so text

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

Fully agree. Thanks Nikolaus and Ben. On Mon, Feb 4, 2019, 3:06 PM Ben Wagner wrote: > So, to summarize, the new behavior is sTypo (if UseTypoMetrics), then hhea > (if not 0), then sTypo (if not 0), then usWin. This is now consistent > across all fonts; variable fonts do not have a different

Re: [ft-devel] Modification in FT_Gzip_Uncompress

Note that OT-SVG only allows gzip-wrapper compressed documents, not zlib-wrapped. On Sat, Jun 8, 2019 at 1:57 AM Moazin Khatri wrote: > Hi, > > In OpenType fonts, SVG documents can be either in plain text or gzip > encoded. > > While writing the code to read these documents I looked for a

Re: [ft-devel] [ft] Three GSoC projects for FreeType

On Wed, May 8, 2019 at 10:19 PM Werner LEMBERG wrote: > > >> It's not completely off the table, but it seems to me that > >> `svgnative' is preferable. > > > > Given that we want a pluggable renderer, the whole discussion is > > moot. > > It's not moot at all IMHO. I want to have a default that

Re: [ft-devel] The criterion for comparing SVG Rendering libraries

On Tue, May 14, 2019 at 9:42 AM Werner LEMBERG wrote: > > >> Could you tell me more about "all the current energye is going in > >> the wrong direction"? Do you think "spending much energy for the > >> discussion which is not so much important"? Or, do you think > >> "trying to implement

<    1   2   3   4   5   >