[ft-devel] undocumented hook to activate the latin2 writing system

Werner, Do you know what the latin2 thing is about? Is the distinction relevant? Still there even? I ran across this piece of code: #ifdef FT_OPTION_AUTOFIT2 /* XXX: undocumented hook to activate the latin2 writing system */ if ( load_flags ( 1UL 20 ) ) options =

Re: [ft-devel] undocumented hook to activate the latin2 writing system

On 15-01-02 09:51 PM, Werner LEMBERG wrote: Do you know what the latin2 thing is about? Not yet. Is the distinction relevant? Still there even? I still have to investigate. The thing is that I simply don't know what latin2 is doing exactly, due to lack of time. Maybe there are

Re: [ft-devel] commit 8dc863587440 causes Chromium rendering issues.

On 15-01-23 06:42 AM, octoploid wrote: Hi,

Re: [ft-devel] commit 8dc863587440 causes Chromium rendering issues.

On 15-01-23 09:46 AM, Werner LEMBERG wrote: since commit 8dc863587440 (Remove 5-level gray AA mode from monochrome rasterizer) the Chromium browser has font rendering issues on certain webpages. See the attached screenshots. -webkit-font-smoothing: antialiased; depends on the removed

Re: [ft-devel] commit 8dc863587440 causes Chromium rendering issues.

I can reproduce this. Debugging now. On 15-01-23 10:03 AM, Behdad Esfahbod wrote: On 15-01-23 06:42 AM, octoploid wrote: Hi

Re: [ft-devel] commit 8dc863587440 causes Chromium rendering issues.

Author: Behdad Esfahbod beh...@google.com Date: Fri Jan 23 11:44:26 2015 -0800 Fix breakage caused by 8dc863587440d0a1d2eec2a7973a8eda99d2767d As reported on ft-devel. diff --git a/src/raster/ftraster.c b/src/raster/ftraster.c index 65ba454..23aa53c 100644 --- a/src/raster/ftraster.c

Re: [ft-devel] [PATCHSET] Multithread-safe FreeType

On 15-01-03 09:16 PM, Behdad Esfahbod wrote: On 14-12-30 10:25 PM, Werner LEMBERG wrote: The patchset mainly removes use of singleton buffers in favor of stack or per-face allocated ones. In all cases this has no down side. [...] Thanks! I'll have a look next year :-) I've now

Re: [ft-devel] Cleaning up ttinterp

On 15-01-11 04:14 AM, Werner LEMBERG wrote: Will have a look whether I can follow your patch, doing the reduction by myself. This is done now. Looks great! Thanks. I've rebased the ftthread branch on top of this. -- behdad http://behdad.org/

Re: [ft-devel] [PATCHSET] Multithread-safe FreeType

On 14-12-30 10:25 PM, Werner LEMBERG wrote: The patchset mainly removes use of singleton buffers in favor of stack or per-face allocated ones. In all cases this has no down side. [...] Thanks! I'll have a look next year :-) I've now pushed many more commits out, that fix a couple of

Re: [ft-devel] ftgrid now supports MM (and GX) fonts

On 15-03-03 04:20 AM, Werner LEMBERG wrote: In git, I've added Multiple Masters (and GX) font support to ftgrid, mostly copying the relevant code from `ftmulti.c'. F2 selects the axis, F3 and F4 changes the current axis values. Enjoy! Thanks Werner; that's great! Any chance you can add

[ft-devel] Glyph with in OTF fonts

Hi, CFF encodes glyph advance widths. OpenType CFF fonts as such encode glyph advance widths in two places: the hmtx table, and the 'CFF ' table. Previous versions of the OpenType specification required that the advance widths specified in the two tables be equal. This was changed in the newly

Re: [ft-devel] GX support now working

by emitting similar PostScript for some test font? I guess we'd have to build some custom font for stress-testing 'gvar', but this shouldn't be so hard. Best, -- Sascha On Mon, Jun 1, 2015 at 9:20 AM, Behdad Esfahbod beh...@behdad.org mailto:beh...@behdad.org wrote: Thanks Werner. Seems

Re: [ft-devel] GX support now working

On 15-06-04 01:52 PM, Alexei Podtelezhnikov wrote: Looking more, looks like both TrueType and Type 1 / CFF use non-zero winding rule. (I'm relieved!) TrueType *recommends* that the outer-most outline be clockwise (solid-to-the-right / fill-right), while Type 1 / CFF recommend the

Re: [ft-devel] GX support now working

orientation is counter-clockwise, causing the same kind of artifact as with Oslash. Again, this shows both in the outline returned by the MacOS API, and in the rasterized glyphs displayed eg. by TextEdit. -- Sascha On Thu, Jun 4, 2015 at 9:53 PM, Behdad Esfahbod beh...@behdad.org mailto:beh

Re: [ft-devel] GX support now working

On 15-06-04 12:19 PM, Behdad Esfahbod wrote: On 15-06-04 12:15 PM, Alexei Podtelezhnikov wrote: On Wed, Jun 3, 2015 at 4:28 PM, Behdad Esfahbod beh...@behdad.org wrote: TrueType fonts have a 'non-zero winding' fill rule, whereas Postscript has 'even-odd'. That's what causes

Re: [ft-devel] max_instructions in ttfautohint

On 15-06-08 03:57 PM, Dave Crossland wrote: On 8 June 2015 at 18:37, Werner LEMBERG w...@gnu.org mailto:w...@gnu.org wrote: is that a rethoric question? ;-) No, quite serious :) How shall this work? We have no influence on Microsoft... It would be great

Re: [ft-devel] max_instructions in ttfautohint

On 15-06-08 05:21 PM, Dave Crossland wrote: On 8 Jun 2015 8:15 pm, Behdad Esfahbod behdad.esfah...@gmail.com mailto:behdad.esfah...@gmail.com wrote: On 15-06-08 03:57 PM, Dave Crossland wrote: On 8 June 2015 at 18:37, Werner LEMBERG w...@gnu.org mailto:w...@gnu.org mailto:w...@gnu.org

Re: [ft-devel] GX support now working

On 15-06-04 12:15 PM, Alexei Podtelezhnikov wrote: On Wed, Jun 3, 2015 at 4:28 PM, Behdad Esfahbod beh...@behdad.org wrote: TrueType fonts have a 'non-zero winding' fill rule, whereas Postscript has 'even-odd'. That's what causes the artifacts. FT_OUTLINE_EVEN_ODD_FILL is never set

Re: [ft-devel] GX support now working

How did you number the points? It seems to be dropping control points, and as such the point numbers are inconsistent with glyph data. I think at this point the question is, why does the slash change orientation at certain ranges. On 15-06-04 05:46 AM, Sascha Brawer wrote: Regarding the Skia

Re: [ft-devel] Slightly modified header inclusion scheme

Werner, This is extremely problematic. Please read my original report that caused the first header file layout change: http://comments.gmane.org/gmane.comp.fonts.freetype.devel/9052 If you are changing this again, can you please just under the simplification that you did in that old thread?

Re: [ft-devel] Slightly modified header inclusion scheme

On 15-06-22 03:44 PM, Werner LEMBERG wrote: This is extremely problematic. Please read my original report that caused the first header file layout change: http://comments.gmane.org/gmane.comp.fonts.freetype.devel/9052 OK, but there's a fundamental difference: freetype.pc now has a

Re: [ft-devel] GX support now working

On 15-06-25 10:55 PM, Werner LEMBERG wrote: The threshold is 400 ppem. Below that size, a center scan algorithm is used. It is a newer algorithm than the original scan converter and produces better results. Please define `better results'. I've always thought that either rule yields a

Re: [ft-devel] Slightly modified header inclusion scheme

On 15-06-25 12:11 AM, Werner LEMBERG wrote: I'd suggest remove the '2' for the inner name. And that's exactly the layout that I proposed back in 2013. Somehow I didn't see the implications then... So, just undo the removing of the freetype2 level you did now, and undo the removing of

Re: [ft-devel] BDF extensions

Just kill it already ;) On 15-06-25 07:48 AM, Alexei Podtelezhnikov wrote: Hi All, It looks like FreeType supports BDF files with MS style bits_per_pixel but not FontForge extension. See this: http://fontforge.github.io/BDFgrey.html Should we add it? Alexei

Re: [ft-devel] Slightly modified header inclusion scheme

On 15-06-24 12:36 AM, Werner LEMBERG wrote: ... include/ freetype2/ ft2build.h freetype2/ ... all other header files ... Doing so places `ft2build.h' only into the namespace while still using an -I flag. The question is whether this layout should

Re: [ft-devel] about that C# fontval (Re: Freetype-devel Digest, Vol 125, Issue 10)

On 15-06-10 02:43 PM, Hin-Tak Leung wrote: If it works with mono, then there is a better chance of it getting contributed enhancements, than if it only works with MS C#/.net. Isn't C# now open source? Anyway, if anyone from Microsoft reads this, I highly recommend that they put the code out

Re: [ft-devel] GX support now working

Thanks Werner. Seems to work fine here! b On 15-05-31 03:38 AM, Werner LEMBERG wrote: Folks, GX support should now work in general, please test! At least with `Skia.ttf' I no longer see artifacts. Adam, I still have problems with two glyphs in `Zycon Regular', namely the cat and

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

Thanks Nikolaus for working on this. This is amazing! One thing we need to figure out before this goes out is, this will be introducing drastic weight differences between unhinted, autohinted-light, autohinted-medium+, and bytecode-hinted. That's not very good. I think at least unhinted should

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

On 15-08-21 03:17 PM, Alexei Podtelezhnikov wrote: This function still needs a bit of work around the corners, both literally and figuratively speaking. Emboldening is not affine transformation. It can introduce artifacts. The function has some crude protection against distortions, but I want

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

On 15-08-21 11:37 PM, Nikolaus Waxweiler wrote: @Werner: What keeps the subpixel hinting code from being turned on by default? It's extremely slow apparently... Needs someone to study it in detail and make it fast. ___ Freetype-devel mailing list

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

On 15-08-21 07:35 PM, Werner LEMBERG wrote: Same here! Also, it currently mishandles glyphs that have outer contours with differing directions... Example call, please. Here you go. Attached. behdad test#1.ttf Description: application/font-ttf

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

On 15-08-24 12:07 PM, Alexei Podtelezhnikov wrote: Alexei A Podtelezhnikov, PhD On Aug 24, 2015, at 6:11 AM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 15-08-23 11:29 PM, Werner LEMBERG wrote: `FT_Outline_Embolden' *does* change the advance width! You have to save

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

On 15-08-23 11:29 PM, Werner LEMBERG wrote: `FT_Outline_Embolden' *does* change the advance width! You have to save the metrics before the call, then restoring the original values. Don't you mean experimental FT_Glyph_Embolden? Oops *blush*. Please forget what I've said :-) Ok I'm not

Re: [ft-devel] Improved Arabic auto-hinting

I'll try to get back to this topic soon. On 15-08-20 03:25 PM, Alexei Podtelezhnikov wrote: This effect: https://www.flickr.com/photos/behdad/34769511/ still happens in my limited testing. This looks like a text layout problem, which was traditionally outside of FreeType's

Re: [ft-devel] Improved Arabic auto-hinting

That sounds great; Thanks Werner! Got any screenshots before / after? Cheers, behdad On 15-08-06 07:58 AM, Werner LEMBERG wrote: Folks, I've improved auto-hinter support for Arabic (both in FreeType and ttfautohint). Joining glyphs should now work much better – please test the git

Re: [ft-devel] Improved Arabic auto-hinting

On 15-08-07 04:16 PM, Werner LEMBERG wrote: Sorry, no. I've only played around with a single font from Titus, but So, what did you verity at all? I've verified that the vertical position for the joining glyphs are the same in his font... I can't reproduce any improvements so far.

Re: [ft-devel] Improved Arabic auto-hinting

On 15-08-07 05:55 AM, Werner LEMBERG wrote: Got any screenshots before / after? Sorry, no. I've only played around with a single font from Titus, but So, what did you verity at all? I can't reproduce any improvements so far. This effect: https://www.flickr.com/photos/behdad/34769511/

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

I'll take a look soon... It's a hard problem. There's no easy answer.. On 15-08-08 09:17 AM, Nikolaus Waxweiler wrote: (Repost because I forgot to click post to list, sorry Werner..) Indeed. So why doesn't get this applied? Is there a negative impact somewhere? Perhaps you should add

[ft-devel] Making Savannah email changes to devel list

I like to keep a closer eye on changes going into FreeType. Would it be possible to setup a commit hook to email the list with all changes? What do others think about that? Cheers, -- behdad http://behdad.org/ ___ Freetype-devel mailing list

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

On 15-08-25 04:30 PM, Alexei Podtelezhnikov wrote: On Tue, Aug 25, 2015 at 10:42 AM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 15-08-25 03:29 PM, Werner LEMBERG wrote: On the other hand: How many recent fonts in the wild have such misformed glyphs? I saw one when developing

[ft-devel] Minor patch

Found in my drafts. Perhaps should go in: https://github.com/behdad/freetype/commit/9b9c38ff8597f328e3ef67c802b252a6c5d49adc -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] gamma correction demo images

On 15-10-27 08:25 PM, Alexei Podtelezhnikov wrote: > On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov > wrote: >> On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler >> wrote: >>> The world needs more linear alpha blending and gamma correction.

Re: [ft-devel] Minor patch

On 15-10-26 10:13 PM, Werner LEMBERG wrote: >> Found in my drafts. Perhaps should go in: >> >> https://github.com/behdad/freetype/commit/9b9c38ff8597f328e3ef67c802b252a6c5d49adc > > Thanks. It's already in the git repository, part of commit Ah, sorry my bad. When I checked the code, I had an

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

On 15-11-10 06:44 AM, Alexei Podtelezhnikov wrote: > FreeType should offer blending! Wishful thinking... Seriously, that's not gonna be used by anyone serious. Don't waste your time on it. ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] Freetype-devel Digest, Vol 130, Issue 8

On 15-11-05 11:29 AM, Hin-Tak Leung wrote: > Also, rather strangely Si Daniels of Microsoft doesn't know that > microsoft's font signing tool package also ships a signature checking tool. That wasn't Si's point. It was that no piece of rendering software enforces the signatures, ie. reject a

Re: [ft-devel] DSIG - Re: Freetype-devel Digest, Vol 130, Issue 8

On 15-11-09 02:42 PM, Hin-Tak Leung wrote: > -- > On Mon, Nov 9, 2015 8:44 AM GMT Behdad Esfahbod wrote: > >> On 15-11-05 11:29 AM, Hin-Tak Leung wrote: >>> Also, rather strangely Si Daniels of Microsoft doesn't know that >>> microsoft

Re: [ft-devel] Support standardized CBDT/CBLC Re: Freetype-devel Digest, Vol 129, Issue 10

On 15-11-07 09:02 AM, Behdad Esfahbod wrote: > Hey, > > Here: > https://github.com/behdad/color-emoji/tree/master/examples Those are source. Pre-built fonts here: https://github.com/behdad/color-emoji/tree/master/specification/examples > Note that our sample fonts have version 2

Re: [ft-devel] Support standardized CBDT/CBLC Re: Freetype-devel Digest, Vol 129, Issue 10

that's because color glyphs is a recent (>2009) addition. > > Hin-Tak > > Message: 2 > Date: Wed, 7 Oct 2015 14:13:54 -0400 > From: Behdad Esfahbod <beh...@behdad.org> > To: "freetype-devel@nongnu.org" > <freetype-devel@nongnu.org> > Subject

Re: [ft-devel] Support standardized CBDT/CBLC

On 15-10-07 11:17 AM, Werner LEMBERG wrote: >> Apparently somewhere during the standardization, CBDT/CBLC got their >> version bumped to 3: >> >> https://www.microsoft.com/typography/otspec/cblc.htm >> https://www.microsoft.com/typography/otspec/cbdt.htm > > Ah, I've missed that. > >>

Re: [ft-devel] [freetype2] master 758d55e: [truetype] Catch infinite recursion in subglyphs (#46372).

I challenge you to implement the Tortoise-and-the-Hare algorithm for this! http://stackoverflow.com/questions/494830/how-to-determine-if-a-linked-list-has-a-cycle-using-only-two-memory-locations On 15-11-04 02:45 AM, Werner LEMBERG wrote: > branch: master > commit

Re: [ft-devel] [ft-announce] Announcing FreeType version 2.6.1

On 15-10-04 06:23 AM, Werner LEMBERG wrote: > > CHANGES BETWEEN 2.6 and 2.6.1 > > I. IMPORTANT BUG FIXES > > - It turned out that for CFFs only the advance widths should be > taken from the `htmx' table, not the side bearings. This bug, > introduced in version 2.6.0,

Re: [ft-devel] More fuzzing for freetype2?

On 15-10-08 02:50 AM, Werner LEMBERG wrote: > Support for named GX instances accessed via face indices can > also be found in `ftview'. That's probably easiest. Someone should add the loop to open all the instances to the fuzzer. I can provide a font to kcc.

Re: [ft-devel] [ft-announce] Announcing FreeType version 2.6.1

On 15-10-07 09:54 PM, Alexei Podtelezhnikov wrote: > On Wed, Oct 7, 2015 at 4:33 PM, Behdad Esfahbod > <behdad.esfah...@gmail.com> wrote: >> Can you please make more quick-and-small releases for important fixes? > > It does not matter It actually does. *Because* FreeTy

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

On 15-08-26 06:59 PM, Werner LEMBERG wrote: So let's stay with what we have, for the sake of a uniform interface to stem darkening. Or switch CFF to the new simplified one if they are close enough (my recollection of the CFF curve is that they are.)

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

On 15-08-27 11:06 PM, Werner LEMBERG wrote: But we are now constrained by compatibility. We actually aren't! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

On 15-08-28 02:43 PM, Werner LEMBERG wrote: But we are now constrained by compatibility. We actually aren't! Please explain. The rendering of CFF fonts changed drastically from one FreeType version to another. The effect of FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH changed from one version to

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

Here's a piece of Python code for whoever wants to compare curves... On 15-08-27 04:44 PM, Alexei Podtelezhnikov wrote: On Thu, Aug 27, 2015 at 10:46 AM, Nikolaus Waxweiler madig...@gmail.com wrote: The look of the function is documented and it blows my mind. I want to know what they smoked.

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

On 15-08-28 03:10 PM, Nikolaus Waxweiler wrote: You want a *global* stem width for all scripts within a font? I'm not sure whether this is a good idea. Uh, I thought that's how it works for Postscript and OpenType/CFF fonts? I'm only aware of the (face-)global dict with a face-wide stdVW.

Re: [ft-devel] smooth update

Got a new patch? Can you also summarize what it tries to do? On 15-09-23 01:58 PM, Alexei Podtelezhnikov wrote: > On Wed, Sep 23, 2015 at 5:53 AM, Nikolaus Waxweiler > wrote: >> I can't apply the patch cleanly. It seems to contain the code twice from 2 >> revisions? Did you

Re: [ft-devel] Bug 46551 about subpixel blending

On 15-11-26 10:13 PM, Alexei Podtelezhnikov wrote: > Folks, > > I filed a bug https://savannah.nongnu.org/bugs/?46551 > > I do not think this is a library bug, I hope someone has a clue what > might havegone wrong or can reproduce it/ I put my bet on underflow / wrap-around somewhere...

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

On 15-11-15 06:35 AM, Werner LEMBERG wrote: > A new function operating on FT_Library, as Jan suggests, is the way to > go, I think, cf. `FT_Library_SetLcdFilter'. I recommend against that, as it makes the FT_Library non-threadsafe. I hvae plans to replace SetLcdFilter with bits in the load_flags

Re: [ft-devel] Myanmar support

On 15-12-14 01:51 PM, Sascha Brawer wrote: > According to a Myanmar speaker here at Google, the autohinted version is > actually better (easier to read) than the manually hinted one. > Congratulations! Cool! Got screenshots? > — Sascha > > > On Sun, Dec 13, 2015 at 9:30 PM, Werner LEMBERG

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

On 15-12-31 09:50 PM, Nikolaus Waxweiler wrote: >> It's not. To you, there might be a lot of things in FT_Library. To the user >> of FreeType, none of them are relevant. A user of FreeType only cares about >> FT_Face objects. The only piece of FT_Library, so far, used by major >> clients, >>

Re: [ft-devel] rendering speedup

On 15-11-20 07:44 AM, Werner LEMBERG wrote: > Sorry, no: Environment variables must be *completely* avoided! There > are operating systems that don't have environment variables at all. This is unwarranted. Many other low-level libraries use envvars. HarfBuzz and glib are examples. On systems

[ft-devel] register keyword

Werner, The 1ec98b29ec0b9cd6ab138aac44e34562706b0016 removed use of the register keyword. A newer commit introduced four instances in ftcalc.h. Can you please remove? Thanks -- behdad http://behdad.org/ ___ Freetype-devel mailing list

Re: [ft-devel] [freetype2] master 25e82bc: [smooth] Consolidate memory management.

Cool. Thanks for doing this. On Thu, Jun 23, 2016 at 11:24 PM, Alexei Podtelezhnikov wrote: > branch: master > commit 25e82bc2b54054b1819c92bad01b623de7d380c7 > Author: Alexei Podtelezhnikov > Commit: Alexei Podtelezhnikov > >

Re: [ft-devel] Autohinter as a front-end for the CFF hinting engine?

On 16-01-11 01:50 PM, Nikolaus Waxweiler wrote: >> This is something that I would like to see as well. My motivations are >> different: to enable applying TrueType GX font variation to CFF outlines, >> then >> hinting them. > > Huh. From the TrueType engine? Oh, are you working on a secret

Re: [ft-devel] [freetype2] master 5c8a8cb: [cff] Fix some Type 2 operators in old CFF engine.

16-02-06 02:03 PM, Werner LEMBERG wrote: > +case cff_op_blend: > + /* this operator was removed from the Type2 specification */ > + /* in version 16-March-2000 */ > + FT_TRACE4(( " blend\n" )); > + > + goto Unimplemented;

Re: [ft-devel] [freetype2] master 5c8a8cb: [cff] Fix some Type 2 operators in old CFF engine.

On 16-02-10 01:35 PM, Werner LEMBERG wrote: > > Do you have an MM CFF for testing? I have a few. I started adding support for them to fonttools just now, but gave up after a few operators, as many were not even documented in the OTMM CFF spec I have lying around. So, forget about my proposal

Re: [ft-devel] Pango error due to #including FT_ERRORS_H

Indeed. The following change essentially changed FreeType API in an incompatible way. I suggest reverting it. In general, I suggest not making too many cosmetic changes to a library so widely used. commit 37412ff9f42212bcf4dd29d9762f3c35b5735768 Author: Werner Lemberg Date:

Re: [ft-devel] gamma correction and stem darkening

On 16-01-17 06:58 AM, Werner LEMBERG wrote: > I think it *is* possible. The method, as implemented by Toshiya-san, > compares various SFNT table checksums. Among them is the `cvs ' > table, and modifying this table is essentially impossible without > interpreting and changing the bytecode.

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

On 16-01-14 02:03 PM, Jan Alexander Steffens wrote: > On Thu, Jan 14, 2016 at 12:29 PM, Werner LEMBERG wrote: >>> To you and your model of the world, these might "act globally on >>> many faces". To a fontconfig-using-, or cairo, or Chrome, or >>> Firefox, or Skia, or Android, or

Re: [ft-devel] gamma correction and stem darkening

[+Patrick Lam] On 16-01-19 04:16 PM, Werner LEMBERG wrote: > >>> I think it *is* possible. The method, as implemented by >>> Toshiya-san, compares various SFNT table checksums. Among them is >>> the `cvs ' table, and modifying this table is essentially >>> impossible without interpreting and

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

On 16-01-20 12:03 PM, Werner LEMBERG wrote: > >>> +#if 0 >>>default: >>> GXV_SET_ERR_IF_PARANOID( FT_INVALID_FORMAT ); >>> goto Exit; >>> +#endif >> >> What's this?! > > The `default' case is redundant, since all possible enum values are > covered in the `switch'

Re: [ft-devel] [freetype2] master fc11af1: Various minor clang fixes.

On 16-01-19 07:16 PM, Werner LEMBERG wrote: > +#if 0 >default: > GXV_SET_ERR_IF_PARANOID( FT_INVALID_FORMAT ); > goto Exit; > +#endif What's this?! ___ Freetype-devel mailing list Freetype-devel@nongnu.org

[ft-devel] 'gvar' patch

Hi Werner, I've convinced myself that the following patch fixes a bug in FreeType's implementation of 'gvar'. I still don't have any test fonts to show it. Will have in a few days. We probably did not notice this as all fonts we tested had only tuple_coords[i] be +1 or -1 for non-intermediate

Re: [ft-devel] 'gvar' patch

I have not produced a test case yet. I suggest you commit, and I'll eventually test. On Tue, Mar 8, 2016 at 11:26 AM, Werner LEMBERG wrote: > > >> I've convinced myself that the following patch fixes a bug in > >> FreeType's implementation of 'gvar'. > > > > Thanks! > > > >> I

Re: [ft-devel] 'gvar' patch

On Tue, Mar 8, 2016 at 12:45 PM, Nikolaus Waxweiler wrote: > Hold on, I have a test now. Fixing up patch. >> > > That was fast :B > Was a two-line fix ;) > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org >

Re: [ft-devel] 'gvar' patch

Tested patch attached. On Tue, Mar 8, 2016 at 12:40 PM, Behdad Esfahbod <beh...@behdad.org> wrote: > Hold on, I have a test now. Fixing up patch. > > On Tue, Mar 8, 2016 at 11:33 AM, Behdad Esfahbod <beh...@behdad.org> > wrote: > >> I have not produced a tes

Re: [ft-devel] 'gvar' patch

Hold on, I have a test now. Fixing up patch. On Tue, Mar 8, 2016 at 11:33 AM, Behdad Esfahbod <beh...@behdad.org> wrote: > I have not produced a test case yet. I suggest you commit, and I'll > eventually test. > > On Tue, Mar 8, 2016 at 11:26 AM, Werner LEMBERG &l

[ft-devel] Another GXVar patch

Hi Werner, Here's another GXVar patch. Last one, I promise! With this, everything is working smoothly. Cheers, -- behdad http://behdad.org/ diff --git a/src/truetype/ttgxvar.c b/src/truetype/ttgxvar.c index ce4c8a0..68cf858 100644 --- a/src/truetype/ttgxvar.c +++ b/src/truetype/ttgxvar.c @@

Re: [ft-devel] "Inside the fastest font renderer in the world" - conversion started

Because it's faster to subdivide into n segments in a single loop. But yeah, that doesn't really matter here, I think you can leave that part of ftsmooth untouched. On Aug 12, 2016 7:15 AM, "Graham Asher" wrote: > Hi Werner, > > yes, I e-mailed him yesterday, and

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, Jul 17, 2016 at 2:10 PM, Werner LEMBERG wrote: > >>> Behdad says this always returns 17, so the implementation was >>> trivial. >> >> Oh, I though Behdad was just being humorous about 42 / 17? > > 42 was my suggestion to use instead of 17 :-) There actually is a way to test

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, Jul 17, 2016 at 1:11 PM, Werner LEMBERG wrote: >>> GETDATA? Never heard of. >> >> You have heard of it, from me :-). > > Ouch :-) > >> LaoUI.ttf Size 10, GETDATA, Glyph ID 263, At ByteOffset 345, > > Ah, now I remember. Faintly... > >> /* GETVAR */ PACK( 0, 0 ),

Re: [ft-devel] GETVARIATION and GETDATA

On Tue, Jul 19, 2016 at 10:08 PM, Hin-Tak Leung <ht...@users.sourceforge.net> wrote: > > On Sun, 17/7/16, Behdad Esfahbod <beh...@cs.toronto.edu> wrote: > > ...This is to make the Chinese fonts > that draw the glyph

Re: [ft-devel] desktop-wide freetype setting Re: Something in 2.6.4 broke my windows

On Jul 7, 2016 2:40 PM, "Hin-Tak Leung" wrote: > > > On Thu, 7/7/16, Werner LEMBERG wrote: > > > I disagree. The > above *is* a clean, system-wide solution. Right now, > there is no possibility by a user

Re: [ft-devel] Something in 2.6.4 broke my windows

If I may chime in: fontconfig does indeed specify rendering options. Werner is right that fontconfig itself does not prepare the FT_Face or rendering, and that is a problem, because our means adding any new config options to fontconfig requires updating all clients. But fundamentally I think it

Re: [ft-devel] Something in 2.6.4 broke my windows

On Thu, Jul 7, 2016 at 9:46 PM, Werner LEMBERG wrote: > >>> If I may chime in: fontconfig does indeed specify rendering >>> options. Werner is right that fontconfig itself does not prepare >>> the FT_Face or rendering, and that is a problem, because our means >>> adding any new

Re: [ft-devel] proposed patch for diagnostics (Re: implementing detection of hinting/rasterization errors in fonts)

The use of a global variable is not desirable. Put it on the FT_Library at least. On Jul 3, 2016 11:07 PM, "Hin-Tak Leung" wrote: > Hi Werner, > > Here is likely the final form of mod to freetype that I am putting in as > part of the next release of font validator.

Re: [ft-devel] "Inside the fastest font renderer in the world"

On Thu, Aug 4, 2016 at 1:19 PM, Alexei Podtelezhnikov wrote: > On Thu, Aug 4, 2016 at 3:42 PM, Werner LEMBERG wrote: >> >>> A first step towards making this new renderer generally useful would >>> be to convert it or compile it (using the Crust compiler) to C.

Re: [ft-devel] Minor modification of `FT_Outline_Check'?

I don't understand what the problem is. What am I missing? On Aug 25, 2016 3:18 PM, "Werner LEMBERG" wrote: > > Folks, > > > I got the following report. > > I found a .ttf file on the web whose outline->n_points and > outline->n_contours are zero. FT_Outline_Check() reports

Re: [ft-devel] Minor modification of `FT_Outline_Check'?

Still confused. What's wrong with an outline with 0 contours and points. Ie. empty? On Thu, Aug 25, 2016 at 2:26 AM, Werner LEMBERG wrote: > >>> I found a .ttf file on the web whose outline->n_points and >>> outline->n_contours are zero. FT_Outline_Check() reports success >>>

Re: [ft-devel] Minor modification of `FT_Outline_Check'?

On Wed, Aug 31, 2016 at 7:56 PM, Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > On Wed, Aug 31, 2016 at 10:45 PM, Behdad Esfahbod > <behdad.esfah...@gmail.com> wrote: >> Still confused. What's wrong with an outline with 0 contours and >> points. Ie. empty? &

Re: [ft-devel] [freetype2] master 3ec6465: Explain how to build a PIC-enabled version of FreeType.

What does mean? Shared libraries are definitely PIC code. Me not understand. On Aug 28, 2016 5:05 PM, "Werner LEMBERG" wrote: > branch: master > commit 3ec64654c49190555b8c26d18ffb91b1b766fb3f > Author: Werner Lemberg > Commit: Werner Lemberg > >

[ft-devel] Clamp variation requests to valid range instead of erring

What subject says. That's required by OpenType 1.8, and avoids rounding surprises. -- behdad http://behdad.org/ diff --git a/src/truetype/ttgxvar.c b/src/truetype/ttgxvar.c index fd00ca4..b504711 100644 --- a/src/truetype/ttgxvar.c +++ b/src/truetype/ttgxvar.c @@ -1310,26 +1310,30 @@ a =

[ft-devel] Has anything around libtool changed recently?

Hi, I know this is a stupid question for this list, but for the life of me I cannot build FreeType anymore and cannot figure out why. During make, I get: libtool: link: ranlib /home/behdad/SSD/src/savannah/freetype/freetype2/objs/.libs/libfreetype.a /bin/sed: can't read

Re: [ft-devel] Has anything around libtool changed recently?

Deleting ~/.local/lib/*.la fixed it, even though there was no freetype.la there. I suppose libtool was just trying to be way too smart, trying to update other .la files that had a (dangling) reference to freetype.la... Sigh.. Sorry for the noise. On Thu, Apr 20, 2017 at 12:18 AM, Behdad

Re: [ft-devel] [freetype2] master ce36777: [sfnt, truetype] Minor adjustments for OpenType 1.8.2.

> -if ( face->header.Units_Per_EM == 0 ) > +/* OpenType 1.8.2 introduced limits to this value;*/ > +/* however, they make sense for older SFNT fonts also */ > +if ( face->header.Units_Per_EM <16 || > + face->header.Units_Per_EM > 16384 ) > Humm. I'm pretty sure

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

On Tue, Aug 1, 2017 at 8:17 AM, Werner LEMBERG wrote: > > > If avar is present, loading of named instances goes wrong. Patch > > attached. > > Thanks, applied. > Thanks. > > Also fixes what I think was an unset psid for named instances. > > This is not necessary, AFAICS.

Re: [ft-devel] [freetype2] master ce36777: [sfnt, truetype] Minor adjustments for OpenType 1.8.2.

On Tue, Aug 1, 2017 at 7:41 AM, Werner LEMBERG wrote: > > >> +if ( face->header.Units_Per_EM <16 || > >> + face->header.Units_Per_EM > 16384 ) > >> > > > > Humm. I'm pretty sure those limits have been there for many > > years... I've had them in HarfBuzz since

<    1   2   3   4   5   >