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

>> But I think signing is a good thing - not from the security point >> of view, but of making font designers (or rather, font modifiers) >> less callous about doing ad hoc modification of fonts. I think >> requiring signing - or even just *showing* the DSIG status - of >> fonts would improve the

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

>> So Alexei noted that he found stem darkening too strong. Me too. >> And it got me thinking again. As long as cairo/Qt5/Skia and others >> don't ship with LAB+GC... > > Yes, I am afraid stem darkening is premature until gamma correction > is available. Hmm. Given that we now have a patch to

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

> I noticed that Liberation Sans/Serif/Mono and Open Sans looked > pretty ClearType-y with hintfull but I wasn't sure about the advance > widths. Is there any way to detect this from within FT_Load_Glyph > or something so that native ClearType fonts with linear advance > widths can be send to the

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

> Has anyone tried those fonts (Liberation, Open Sans, Segoe UI, > Consolas) on Windows 98? Would be nice to know if it shows the same > results, since it has the version 35 engine FreeType is trying to > emulate. Unfortunately, browserstack doesn't offer Win98... > Also, isn't a version 35 engi

Re: [ft-devel] [PATCH] Allow native CFF hinter in FT_RENDER_MODE_LIGHT

> This is, excepting whitespace adjustments, a pretty minimal patch > that makes Freetype use the native CFF hinter in > FT_RENDER_MODE_LIGHT, since these now have a very similar rendering > style. Applied, thanks! Werner ___ Freetype-devel mailin

Re: [ft-devel] strict aliasing

> Compilers are beginning to embrace more aggressive optimization > techniques. One of these directions is that of strict aliasing. We > have experienced crashes on some ARM embedded devices in some code > that was flagged with the “strict aliasing” warning. We have been > going through our cod

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

> So, for now I propose: 1. set no_stem_darkening = true for both > autohinter and cff driver. I've done this right now in the git repository. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listi

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

> I suppose we still have time to add the suggested LOAD flag before > the 2.7 release? Well, I would like to do a release very soon, perhaps 2.6.2, preferably within a week. There are zillions of bugfixes due to fuzzing, and some people urgently need a new version. > IMO it should: > > 1) Swi

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

> In other words, if you want to modify a property, you have to close > all faces, do the change, then reload everything. To be more precise, I mean ... to close all faces affected by the font driver (e.g., `cff') or FreeType module (e.g., `autofit'). Werner __

Re: [ft-devel] Sharpness rendering of Noto font at small font sizes

> What should be done to make the hinted NotoSans-Regular.ttf as clear > as the unhinted one? Currently, I'm working on improving the hinting for all Noto fonts using ttfautohint. Have a look at https://rawgit.com/lemzwerg/noto-hinted/master/index.html Werner __

Re: [ft-devel] strict aliasing

>> Soo... Do you get crashes in FreeType? > > I don’t believe that we do get crashes in Freetype. Good to know :-) > Something like: > AFunc(const DB *db, const void **result) { > const DirectoryEntry *dir = NULL; > GetDirectoryEntry(db, (const void**)(&dir));

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

> You should want it for everything that comes out of a ft_library, > not just for a single face or glyph. Exactly. > But that might make it necessary to centralize the darkening > property somehow so toolkits don't have to enable it for every > possible driver/module. That was my idea behind a

Re: [ft-devel] rendering speedup

> After doing a few speed measurements to a Qt based program I found > that freetype was producing a few hotspots, two of them in > src/smooth/ftsmooth.c Aah, your code is a fix for the `Infinality' patch set! > With the patch attached the time spent there was reduced some 50% > (by block re-all

Re: [ft-devel] rendering speedup

> However, there is a person maintaining the Infinality patch-set > > https://github.com/bohoomil/fontconfig-ultimate > > and that integrates cleanly on 'master'. Aah, good to know! > The main issues with it (besides the inner workings on font > rendering which are black-box for me) were perform

Re: [ft-devel] rendering speedup

> Indeed, he even opened a dedicated website (http://bohoomil.com) but > I can't find an e-mail address to include him in this > discussion... I can't speak of him and his interest but I can make > these patches public to anyone with a desire for them. Maybe you can add a github issue for his rep

Re: [ft-devel] rendering speedup

> I guess there's still the option of passing the setup/file selection > also through the API but having to handle them all is tiresome... There is no reason why you can't pass a single structure with all Infinality options to FT_Property_Set... The question is whether this makes sense. We

Re: [ft-devel] rendering speedup

> [...] Many other low-level libraries use envvars. HarfBuzz and glib > are examples. On systems that don't support them, we just: > > #define getenv(name) NULL > > That's very widespread. To categorically reject envvars, in > exchange for properties (that need code modifications), is not > w

Re: [ft-devel] register keyword

> The 1ec98b29ec0b9cd6ab138aac44e34562706b0016 removed use of the > register keyword. A newer commit introduced four instances in > ftcalc.h. Can you please remove? Done. Thanks for the report. Werner ___ Freetype-devel mailing list Freetype-d

[ft-devel] new release this week

Folks, I tried to make a release this weekend, however, some minor documentation bits are not there yet (and I'm abroad also), so I'm delaying it until next weekend, but then I *definitely* release 2.6.2 :-) So please bring forward any final changes you would like to see in the next release – e

Re: [ft-devel] gamma correction demo images

>> I did some experimentation with my crazy patterns. I firmly >> believe now that simple box filter aka FT_LCD_FILTER_LIGHT is not >> just good but in fact the best in reducing color fringes IFF used >> with correct gamma. All color-balanced filters with gamma >> eliminate color fringes complet

Re: [ft-devel] gamma correction demo images

> It is true that the 5-wide filters (e.g., [0x8, 0x4D, 0x56, 0x4D, > 0x8] that are color balanced are not quite as sharp. However, I > found empirically they produce less color fringing on a slightly > uncalibrated display. [...] This sounds like a good compromise, thanks. Can we all agree on

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

> When do you expect to release 2.6.2? This weekend. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] docs: multiple identifiers with identical names [solved]

I've updated FreeType's documentation generator to handle identifiers with identical names. For disambiguation, you have to append something in brackets. Example: darkening-parameters[autofit] darkening-parameters[cff] This becomes darkening-parameters (autofit) darkening-parameters (

Re: [ft-devel] gamma correction demo images

>> This sounds like a good compromise, thanks. >> >> Can we all agree on this filter as the default for `light_filter'? >> >> Alexei, what value should `default_filter' have? > > Please leave the light one alone. Dave's filter should be default. So *what* shall I change? Werner

Re: [ft-devel] cmake improvements

> I've made some CMake-related improvements. Please review the > patches, let me know if you need this or if I should I change > something. Thanks a lot, I've applied them (with slight modifications, please check). Werner ___ Freetype-devel maili

Re: [ft-devel] gamma correction demo images

> Here's my promised documentation including the filter change. Please > review. Thanks a lot! This is now in the git repository, please re-check. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/

Re: [ft-devel] gamma correction demo images

> Ah, I forgot something. Thanks! Applied, with some modifications (I don't like future tense in documentation). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Announcing FreeType 2.6.2

FreeType 2.6.2 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file. Enjoy!

Re: [ft-devel] Announcing FreeType 2.6.2

> Nice :) I think 2.6.2 packs quite a punch. Maybe users will see it > at work in 2 years or so when distros upgrade ;) Hehe :-) > So have you had time to look over my blog post thing that I want on > freetype.org? I think users and (Linux) news outlets such as > Phoronix might care. The text

Re: [ft-devel] Announcing FreeType 2.6.2

> I don't have a blog, I wrote this for freetype.org :) Aah! OK, your stuff is highly welcome. To proceed, please clone the freetype-web repository and provide real HTML files :-) http://cgit.freedesktop.org/freetype/freetype-web/ Werner ___

Re: [ft-devel] Announcing FreeType 2.6.2

> So how about moving freetype.org from bare HTML files to some fancy > static site generator first and then reworking the content? :B Basically, I don't object. Here a bunch of things that come to my mind. (a) I have no idea about such site generators. (b) I *hate* working with HTML :-) On th

Re: [ft-devel] State of TrueType interpreter v38 and up?

>> Infinality patches are integrated. See in ttinterp.c under |#ifdef >> TT_CONFIG_OPTION_SUBPIXEL_HINTING > > Ah, okay, so ClearType support is theoretically complete? What about > v39 and v40? ClearType consists of multiple parts. The first one is the interpretation of the hints, which is com

Re: [ft-devel] State of TrueType interpreter v38 and up?

> I'm interested in adding native ClearType to the definition `Native' ClearType is implemented. > If I remember correctly, that is what Infinality set out to do and > Behdad mentioned that it's slow. Yes, it's slow. Improvements welcome. > How far did the integration go? What work remains?

Re: [ft-devel] State of TrueType interpreter v38 and up?

>> There is a misunderstanding, see above. `Native' ClearType doesn't do >> y-only hinting! It's simply that advance width modifications are >> ignored in Windows at a later stage, namely in the rasterizer. > > I'm confused. Is this "native ClearType" actually called "Natural > ClearType" or "n

Re: [ft-devel] State of TrueType interpreter v38 and up?

> I thought one of the core ideas of ClearType is that glyphs are > snapped to the pixel grid only on the Y-axis? No. This is what *effectively* happens, due to the strongly increased horizontal resolution. However, at least in `native' mode, you can still enforce non-integer positions along th

Re: [ft-devel] State of TrueType interpreter v38 and up?

> Mostly as note to my future self, to summarize those rendering modes > in DWrite terms, please correct me if I got anything wrong: [...] All what I know is taken from information from https://msdn.microsoft.com/en-us/library/windows/desktop/dd368118(v=vs.85).aspx You certainly are aware of

Re: [ft-devel] State of TrueType interpreter v38 and up?

>> (a) ignore changes of the horizontal advance widths due to hinting >> instructions (not implemented yet), and >> >> (b) ensure that all instructions behave correctly even if the >> horizontal resolution is increased (this is ClearType >> compatibility mode, already implemented). > >

Re: [ft-devel] Announcing FreeType 2.6.2

>> Would you be willing to host the site on Github Pages? >> >> http://pages.github.com > > Is this addressed to Werner? I personally would vote in favor of > moving the FreeType site and main code repository to GitHub, simply > because it's the most popular service with the largest user base an

Re: [ft-devel] Announcing FreeType 2.6.2

> 3rd revision, proof-read by Graham Asher, to be applied to the 1st > revision. Thanks a lot! Now committed, with minor changes. I've also added a small TOC for better navigation. Please check. Werner ___ Freetype-devel mailing list Freetype-

[ft-devel] auto-hinter support for Khmer

Folks, I've almost completely rewritten the interface to the HarfBuzz library to support character clusters as used by Khmer and other scripts, where some blue zones can't be represented with a single Unicode character. Please test! I'll soon port the Khmer support to ttfautohint; the next ste

[ft-devel] Khmer support in ttfautohint

I've now updated ttfautohint to handle Khmer. For testing, the `noto-hinted' github repository has been extended with NotoSansKhmer and NotoSerifKhmer. https://rawgit.com/lemzwerg/noto-hinted/master/ Enjoy! Werner ___ Freetype-devel mailing l

[ft-devel] Myanmar support

Both FreeType and ttfautohint can now handle Myanmar. For testing, the `noto-hinted' github repository has been extended with NotoSansMyanmar. https://rawgit.com/lemzwerg/noto-hinted/master/ Enjoy! Werner ___ Freetype-devel mailing list Freet

Re: [ft-devel] Stance on X-and-Y-axes autohinter?

> so I wanted to look at tt*.* and then I remembered that the > autohinter can do both X-and-Y and "light" Y-only hinting. My > impression is that X-and-Y is the lesser of the two. Is there > anything that would speak against a theoretical removal of X-and-Y > and crowning of Y-only as the one t

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

>> 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 to > make FT_Library fully threadsaf

Re: [ft-devel] Build Process Issues | freetype-2.5.2

Since I don't use MSYS, I can't directly help. However... > I also tried to build the projects provided in builds/windows > directory without success. ... this surprises me. I assume that for a VS project the files in `builds/windows/vs2010' are the right ones. Note that I don't use VS either

[ft-devel] Bengali support in FreeType ttfautohint

I've now extended both FreeType and ttfautohint to handle the Bengali script. To get good hinting results, it was necessary to implement top-to-bottom hinting – up to now, FreeType only supported bottom-to-top hinting, this is, starting with the lowest blue zone, searching serifs and stems while

Re: [ft-devel] Bengali support in FreeType ttfautohint

> I find the top-to-bottom thing curious. Do you have an explanation > why it works better for these scripts? A typical Bengali text string looks like this. সমস্ত মানুষ স্বাধীনভাবে সমান মর্যাদা এবং অধিকার নিয়ে জন্মগ্রহণ করে Attached is a larger rendering with HarfBuzz, using the `Sagar' font

Re: [ft-devel] Bengali support in FreeType ttfautohint

>> I find the top-to-bottom thing curious. Do you have an explanation >> why it works better for these scripts? > > I now think that bottom-to-top for Latin is questionable: L and J > seem to be the only letters with important features at the > bottom. Many more letters are heavy at the top. I di

Re: [ft-devel] Bengali support in FreeType ttfautohint

>> I disagree. Hinting as done by the auto-hinter should start at the >> zone that is most common – and that is definitely the normal >> baseline for Latin (and Cyrillic) > > You learned to write on top of the line. Me too. This is a totally > arbitrary tradition. We could have learn to write

Re: [ft-devel] Bengali support in FreeType ttfautohint

> So Alexei, how about you flip the direction for the latin hinter in > an experiment and show us some rendering results? ;) This should be easy, BTW: In `src/autofit/afscript.h', simply change SCRIPT( latn, LATN, "Latin", HB_SCRIPT_LATIN, HINTING_BOTTOM_TO_TOP

Re: [ft-devel] Bengali support in FreeType ttfautohint

> I tried HINTING_TOP_TO_BOTTOM for Latn. The results are obvious: it > changes the position of any middle stem quite dramatically: > sometimes for better, sometimes for worse. e's with top diacritics > suffering the most as they loose consistency. So yeah, years of > tweaking for BOTTOM_TO_TOP s

Re: [ft-devel] cff driver bug

> I'm including both the original code and the code we used to fix the > bug: [...] Applied, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

> What if the autohinter was reworked to be a front-end for the CFF > grid-fitting machinery? Yes, this is a long-term plan, together with using the CFF engine for hinting Type 1 fonts (which is something I would like to have rather soon). > I have not looked closely at the source yet, but what

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

> > However, there's an alternative approach I've been talking about: > > take the Adobe autohinter from AFDKO and plant it into FreeType. I can't remember this, probably getting old :-) However, it's an interesting idea. > > Does the AFDKO autohinter support the same scripts as the current > >

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

>> I would model my stem darkening property after your proposal. > > Werner has to make the call. What about the following model, which tries to harmonize the various suggestions. . In `FT_Library', we have default properties, to be set with functions like `FT_Set_Property' or `FT_Library

Re: [ft-devel] lame FT_SetLcdFilterWeights

> I committed the change. Ok? Looks, ok, thanks. Note, however, if you ask a question w.r.t. to committing or not, you should wait, say, two days at least if you expect an answer... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org

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

>> For high-quality output with gamma correction, I think I need both: >> (1) native hinting for TrueType fonts -- otherwise tricky CJK fonts >> fail >> (2) stem darkening -- otherwise the text is too light after gamma >> correction What you want doesn't exist yet, sorry, but I think th

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

> Unfortunately, I don't think it will be possible to detect the > tricky fonts. 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 an

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

> I just looked through the code and found > tt_check_trickyness_sfnt_ids -- I assume that's the code you're > referring to. Yep. > I didn't trace through the code; do I need to do anything special to > enable those checksum tests? Assuming that the family name for subsetted fonts in PDF files

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

>> I didn't trace through the code; do I need to do anything special >> to enable those checksum tests? > > Assuming that the family name for subsetted fonts in PDF files is > not reliable, you should temporarily set `face->family_name' to NULL > so that the check for the font's family name is sk

Re: [ft-devel] Removing the unpatented hinter code

> @Werner: ping :) Uh, oh, not there yet, sorry. Will still take some time, so please don't hesitate to send another ping in the not too distant future just to be sure :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://

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

>> To make `FT_Open_Face' skip the family name test, I would have to >> add an FT_PARAM_TAG_TRICKY_CHECKSUMS flag. This is not a big deal, >> but I wonder whether it really solves your issue, so please do some >> experiments. > > I don't think that's necessary. The FreeType code appears to alwa

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

> The cvt and prep checksums match DFKaiShu, but the fpgm checksum and > length are different. This might easily happen in case the font's bytecode gets revised to fix a buglet, say. > And here's a patch: Applied, thanks! Werner ___ Freetype-de

Re: [ft-devel] SetLcdFilter docs

> "If this feature is activated, the dimensions of LCD glyph bitmaps > are either larger or taller than the dimensions of the corresponding > outline with regards to the pixel grid. For example, for > FT_RENDER_MODE_LCD >

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

>> 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. Ditto >> for `fpgm'. I dare to say that eve

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

> oh my god. now the detection of tricky fonts is becoming something > like a discussion for anti-virus software... :) I think that handling of tricky fonts should stay as-is in FreeType. Today, almost all fonts avoid overlapping contours for various reasons, and I'm not aware of recently create

Re: [ft-devel] ABI in detail

> I'm working on a new project for high-detailed binary compatibility > analysis of C libraries (alternative for the abi-compliance-checker > project) and I've got interesting results for FreeType 2.6.2. Thanks, but what exactly are the `interesting results'? Please elaborate. Werner ___

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

>> I'm not aware of recently created tricky fonts. > > RasterInfo.ttf comes to mind. :) FontForge complains about > self-intersecting contours. Then FontForge is wrong, or rather, it doesn't correctly handle the border case of collapsing an outline to a line to make it disappear. Werner _

Re: [ft-devel] SetLcdFilter docs

> I see: > > width += 3 * extra; > pitch= FT_PAD_CEIL( width, 4 ); > > where extra = 2 for FIR filters. So we add 3 *subpixels* on each > side plus rounding. So on one hand, the docs say something > different. On the other hand, the filter actually needs just 2 > extra *subpixels* on each

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

>> +#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' statement. Toshiya-san, shall I completely remove this code?

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

>> The `default' case is redundant, since all possible enum values are >> covered in the `switch' statement. > > I personally prefer having code in front of me that I can prove > correct, than having to go fish for all the places that value in the > switch statement is set to convince myself that

Re: [ft-devel] ABI in detail

>>> I'm working on a new project for high-detailed binary >>> compatibility analysis of C libraries (alternative for the >>> abi-compliance-checker project) and I've got interesting results >>> for FreeType 2.6.2. >> >> Thanks, but what exactly are the `interesting results'? Please >> elaborate. >

Re: [ft-devel] ABI in detail

> The report can be used as the reference for the FreeType API at > binary level. You can view how parameters are passed to API > functions (calling conventions) and memory layouts of data types in > the report. Looking at http://abi-laboratory.pro/tracker/compat_report/freetype/2.4.11/2.4.12

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

> My best guess is that something got changed somewhere in > 'freetype/fterrors.h'. It does look like something got done (about > a week ago) to remove underscores from some macro names but I'm not > sure why that would cause this problem. Can anyone hazard a guess > at what might be wrong? Tha

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

> Yeah - precompiled headers are turned off for both pango and > freetype2. Hopefully some other MSVC user can confirm if they see > the same problem. Can you call the preprocessor only, then checking the expanded source code for the problem? Werner ___

Re: [ft-devel] error: conflicting types for 'af_shaper_get_coverage'

> freetype/san_cov/src/autofit/afshaper.c:577:3: error: conflicting > types for 'af_shaper_get_coverage' [...] Fixed in git, thanks for the report! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman

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

> The following change essentially changed FreeType API in an > incompatible way. [...] Fixed in git. Thanks for both the report and the analysis. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman

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

> The variable, gxvalid->statetable.entry_glyphoffset_fmt, it is set > by gxv module internally not imported from external font file (thus, > malicious input data cannot set the value to the undefined > value). So it is OK to remove the default case. Done. Werner __

Re: [ft-devel] ABI in detail

> I've checked the code regarding this issue and seems that these two > symbols are present in the header files of freetype 2.4.12 but > missed in the shared object. > > These commands return empty output: > > readelf -Wa freetype-2.4.12/lib/libfreetype.so.6.10.1 | grep > FTC_Manager_Lookup_Fac

[ft-devel] Announcing ttfautohint version 1.5

ttfautohint 1.5 has been released. The source tarball, statically-linked binaries for Win32 (TTY and GUI) and OS X (TTY only) are available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ttfautohint/1.5 Instructions to build the GU

Re: [ft-devel] Announcing ttfautohint version 1.5

> I can't compile git master, it gives me loads of: Please install current git of FreeType and test again; I think this has been fixed with commit 24fbed052fbacb690f62bc4b0abfa29f668a35c2 Author: Werner Lemberg Date: Wed Jan 20 21:10:41 2016 +0100 Still handle `__FTER

Re: [ft-devel] ABI in detail

>>>  I've checked the code regarding this issue and seems that these two >>>  symbols are present in the header files of freetype 2.4.12 but >>>  missed in the shared object. >>> >>>  These commands return empty output: >>> >>>  readelf -Wa freetype-2.4.12/lib/libfreetype.so.6.10.1 | grep >>> FTC

Re: [ft-devel] Removing the unpatented hinter code

>> Uh, oh, not there yet, sorry. Will still take some time, so please >> don't hesitate to send another ping in the not too distant future >> just to be sure :-) > > You asked for it ;) Hehe, yes :-) While looking at your patch I've found some issues. (1) The patch doesn't cleanly apply to ma

Re: [ft-devel] Removing the unpatented hinter code

> I left FT_UNPATENTED_HINTING_H unchanged, otherwise > FT_PARAM_TAG_UNPATENTED_HINTING is unreachable. > > I also made SetUnpatented... just return false, I don't know how > FreeType's 'throw' would interfere with old code that's not > expecting it. Thanks for the patch! I've applied it, with s

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

Just starting to have a look, but I stopped immediately: > #ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING > TT_Driver driver = (TT_Driver)FT_FACE_DRIVER( face ); > #endif > +TT_Driver driver = (TT_Driver)FT_FACE_DRIVER( face ); What's this? If the #ifdef is true, you declare and set `dri

Re: [ft-devel] Autohinter, Cantarell-Regular, 14ppem: dot on i and j on different grids, ascenders of d not snapped to zone

> Since this is an .otf and you can't force the autohinter in light > rendering mode (bug). Care to provide a fix? It was you who made the auto-hinter use the new CFF engine in light hinting mode :-) > The dot on the i and j are snapped to different heights Alas, this is such a common problem

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

> It is incompatible with TT_CONFIG_OPTION_SUBPIXEL_HINTING. OK, I was missing this point. >> I suggest that we allow advance width changes in native ClearType >> hinting mode, being `better' than MS :-) Applications like web >> browsers can still override this by using the unchanged advance >> w

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

> Classical in the sense that it was originally (super)hinted for > black-and-white display, e.g. Arial, Times New Roman, Verdana, > Georgia. The spacing they do looks off when stopping movement on > the x-axis. Fonts developed with ClearType in mind do this a lot > less and sometimes even react

Re: [ft-devel] Autohinter, Cantarell-Regular, 14ppem: dot on i and j on different grids, ascenders of d not snapped to zone

> That was easy. Apply to freetype2-demos. Committed, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] vcproj and vcxproj bloat

> Do you know that freetype source contains 1.4 Mb (10%) of Visual > studio project files? Yes. IMHO, it doesn't matter. > Do we need the threaded configurations or are they just redundant? I don't know. I've never used VS, and I'm rather confident that this will not change :-) The VS files a

Re: [ft-devel] CFF divide operator

> I've run into some CFF fonts that use the divide operator, which is > unimplemented in the new CFF interpreter. Interesting. Please send me a sample privately for my collection. Can you find out which CFF generator created the fonts? Or are the fonts even `native' CFF? > I was going to inclu

Re: [ft-devel] CFF divide operator

>> Can you find out which CFF generator created the fonts? Or are the >> fonts even `native' CFF? > > I'll send you a font file. Thanks. > The fonts are from a PDF file, which claims: > > Creator:Adobe InDesign CS6 (Macintosh) > Producer: DALiM Software Applications OK. > I'm no

Re: [ft-devel] CFF divide operator

>> And freetype's FT_DIV_MOD is likely the right starting point. > > No. We do not need 'mod'. At most we need FT_DivFix. Yep. I'm working on it. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/

Re: [ft-devel] CFF divide operator

>>> And freetype's FT_DIV_MOD is likely the right starting point. >> >> No. We do not need 'mod'. At most we need FT_DivFix. > > Yep. I'm working on it. All CFF operators except `random' are now implemented. Please test! Werner ___ Freetype-de

Re: [ft-devel] Peculiar Hinting / Rendering Behavior

>> Here's another recipe to see the artifact even better (I'm using >> msmincho.ttc from Windows 7): >> >> ftgrid -f 4420 19 msmincho.ttc >> >> (value 4420 is the glyph index of U+56DB in this font). After >> pressing key `a', a vertical line on the left is missing in the >> outline. Interestin

[ft-devel] Announcing FreeType version 2.6.3

FreeType 2.6.3 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file. Enjoy!

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

>> +case cff_op_blend: ... this is for the old CFF engine. The new engine doesn't cover the `blend' operator at all, but it should be trivial to add it. > Actually I have had wanted to propose implementing a "bypassing" blend > instead. [...] > > The "2" is the number of operands to b

[ft-devel] Fw: Kudos to FreeType 2.6.3 development

:-) --- Begin Message --- I've now completed successful builds and installs of FreeType 2.6.3 in all 77 machines in our test lab, each with a different version of Unix. There was not a single machine on which the package could not be built, which is a pretty rare occurrence. Great job on the part

Re: [ft-devel] First skeleton of my freetype.org-restructuring effort online

> https://madig.github.io/freetype-web/ Looks promising, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ftgrid] Display rendered bitmap (new feature).

> I have added a new feature to ftgrid that now can display rendered > scaled bitmap, so that you do not have to use FontForge as a viewer. > Comments and suggestions are welcome. This is really great, thanks a lot! Trying it on arial.ttf, I see some greenish artifacts at the pixel borders; simi

  1   2   3   4   5   6   7   8   9   10   >