Mactype: Build Questions / Issues

[Infinality]

How do I include my compiled Freetype directory into Visual Studio? It's been a long time since I've used these development tools. :)

[snowie2000]

Configure your VS with correct freetype information in VC++ directory property page:
https://msdn.microsoft.com/en-us/library/ee855621.aspx

[Infinality]

I'm not seeing "VC++ Directories" as specified in the link. (I'm running VS 2017 Community edition, FWIW)

[snowie2000]

Maybe Microsoft has decided to move this property page again (they moved it from main menu to solution property in vs2013).

[Infinality]

I found it in project properties and was able to get past the freetype compile issues. I'm having linker issues now though. I've compiled, referenced, and moved the wow64ext.lib and .dll files, however I seem to get this no matter what:

Error LNK2019 unresolved external symbol _InitWow64ext referenced in function _DllMain@12 MacType C:cygwin64homeuserDownloadsmactypehook.obj 1
Error LNK2019 unresolved external symbol "public: __thiscall CParseIni::CParseIni(void)" (??0CParseIni@@QAE@XZ) referenced in function "void __cdecl `dynamic initializer for 'private: static class CParseIni CGdippSettings::m_Config''(void)" (??__E?m_Config@CGdippSettings@@0VCParseIni@@A@@YAXXZ) MacType C:cygwin64homeuserDownloadsmactypesettings.obj 1

[Infinality]

Ok, got past all previous errors, but I'm getting stuck at the linking phase, because Freetype is making external references that it doesn't know about, like "getenv" and other stdlib stuff:

Error LNK2019 unresolved external symbol __imp__getenv referenced in function _FT_Set_Default_Properties MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftinit.obj) 1
Error LNK2001 unresolved external symbol __imp__getenv MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftbase.obj) 1
Error LNK2001 unresolved external symbol __imp__getenv MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftdebug.obj) 1
Error LNK2019 unresolved external symbol __imp__strncpy referenced in function _raccess_make_file_name MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftbase.obj) 1
Error LNK2019 unresolved external symbol __imp____stdio_common_vsscanf referenced in function __vsscanf_l MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftbase.obj) 1
Error LNK2019 unresolved external symbol _strcasecmp referenced in function _bool_val MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftbase.obj) 1
Error LNK2019 unresolved external symbol __imp__fseek referenced in function _FT_Stream_Open MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftsystem.obj) 1
Error LNK2019 unresolved external symbol __imp__ftell referenced in function _FT_Stream_Open MacType C:cygwin64homeuserDownloadsmactypefreetype.lib(ftsystem.obj) 1
Error LNK2019 unresolved external symbol __except_handler4_common referenced in function __except_handler4 MacType C:cygwin64homeuserDownloadsmactypeMSVCRTD.lib(_chandler4gs_.obj) 1
Error LNK1120 8 unresolved externals MacType C:cygwin64homeuserDownloadsmactypeDebugMacType.Core.dll 1

[snowie2000]

I think maybe you are building freetype or mactype with /MD? All files should be compiled with /MT.

[Infinality]

That worked! Thanks!

[Infinality]

So, I have replaced the MacType.Core.dll in "C:program filesmactype" with the version I compiled, and unfortunately it crashes when I try to load it. I get an application error: "Exception EAccessViolation in module MacTray.exe at 00000000. Access violation at address 00000000. Read of address 00000000." Any thoughts?

[Infinality]

My patch is here for anyone who wants to play around with compiling MacType with it:

https://github.com/Infinality/mactype-infinality

[snowie2000]

That means the dll is fail to be loaded by mactray.exe.
You have to debug to find out why it fails.

[Infinality]

:)

[snowie2000]

Here comes the file:
http://www.mactype.net/station/MacType_CTP_171017.rar
(Due to the CDN cache, you cannot see this file from station page directly)
I changed the version number and file description so that it will easier to distinguish from other versions.

[snowie2000]

To the honest, the rendering effect with your patch is quite interesting and very different from freetype.
I may need some time to get used to it, and I think the horizontal line rendering is a little too thin compared to freetype. Sometimes it's hard to see the horizontal line with some fonts.

[Infinality]

You can use the LCD filter to make stems thicker or thinner. It's
different from Freetype.  I'm trying to get the stem alignment from
Windows, but the /natural /rendering of Freetype.

[snowie2000]

I played with LCD filter for a little time and looks like it works mainly with the vertical lines. For horizontal lines, I didn't see many differences.

[Infinality]

The following environment variables also need to be set, from System Properties / Advanced / Environment Variables in order to cause the additional alignment code to turn on. I believe a logout / login is necessary after these are set in order for things to pick them up.

[snowie2000]

This looks as if the hinting is forced on.

[Infinality]

This file should explain all the available environment variables. Probably the only ones that will do anything in MacType would be the ones that start with "INFINALITY_". I still haven't gotten a chance to test out the new dlls you posted.

https://github.com/Infinality/mactype-infinality/blob/master/infinality-settings.sh

EDIT: It's important that the FREETYPE_PROPERTIES is also set to "truetype:interpreter-version=38" (without quotes). Version 40 is faster but not as good.
FREETYPE_PROPERTIES=truetype:interpreter-version=38

[IceMan81]

Weren't some of these environment variables rendered obsolete by the
changes from infinality absorbed into freetype 2.7?
On Tue, Oct 17, 2017 at 05:49 Infinality [e-mail] wrote:

This file should explain all the available environment variables. Probably
the only ones that will do anything in MacType would be the ones that start
with "INFINALITY_". I still haven't gotten a chance to test out the new
dlls you posted.

https://github.com/Infinality/mactype-infinality/blob/master/infinality-settings.sh

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/snowie2000/mactype/issues/366#issuecomment-337220755,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABCwkqfqvNYdj4sSDp0jZKQtUqGHrCnBks5stKJygaJpZM4PzShZ
.

[Infinality]

Most of them should still have an effect, at least in an installation / configuration on Linux systems. I haven't fully wrapped my head around how MacType interacts with freetype, so some of the environment variables may or may not have an effect.

[Infinality]

After playing around with the new DLLs, it doesn't seem as though the settings in the environment variables are making it into execution of Freetype. It's entirely possible that the mechanism that environment variables get read in freetype doesn't support however Windows presents them, or there might be some other problem. (Really, using environment variables in my patch was never meant to be a permanent solution; It was more a solution of convenience at the time, but it would be interesting to get it working in MacType, and at least get on par with how it renders on Linux).

[IceMan81]

Before some of the infinality changes made it into freetype, I used to
compile freetype dlls on Windows using the infinality patches that were
being maintained by boohomil (
https://github.com/bohoomil/fontconfig-ultimate?files=1). And when using
those patches I've successfully configured free type using the infinality
environment variables. So the environment variables used to work.
On Tue, Oct 17, 2017 at 16:43 Infinality [e-mail] wrote:

After playing around with the new DLLs, it doesn't seem as though the
settings in the environment variables are making it into execution of
Freetype. It's entirely possible that the mechanism that environment
variables get read in freetype doesn't support however Windows presents
them, or there might be some other problem. (Really, using environment
variables in my patch was never meant to be a permanent solution; It was
more a solution of convenience at the time, but it would be interesting to
get it working in MacType, and at least get on par with how it renders on
Linux).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/snowie2000/mactype/issues/366#issuecomment-337411228,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABCwkgZiSmkYs2o2m70faTvXChlfJLdPks5stTuOgaJpZM4PzShZ
.

[IceMan81]

@Infinality Are you seeing any improvements with the infinality patched mactype over default mactype?
What settings are you using for HintingMode and AntiAliasMode with patched mactype?

[Infinality]

I haven't been able to see any improvements with the patched MacType, and I'm not sure whether it's related to environment variables or something else. These are the values I use on my Linux systems. It produces glyph shapes like Windows but the alignment and filtering are much, much better IMO.

FREETYPE_PROPERTIES=truetype:interpreter-version=38
INFINALITY_FT_CHROMEOS_STYLE_SHARPENING_STRENGTH=0
INFINALITY_FT_CONTRAST=0
INFINALITY_FT_STEM_FITTING_STRENGTH=25
INFINALITY_FT_AUTOFIT_ADJUST_HEIGHTS=true
INFINALITY_FT_AUTOHINT_SNAP_STEM_HEIGHT=100
INFINALITY_FT_GRAYSCALE_FILTER_STRENGTH=0
INFINALITY_FT_GAMMA_CORRECTION="0 100"
INFINALITY_FT_WINDOWS_STYLE_SHARPENING_STRENGTH=20
INFINALITY_FT_BRIGHTNESS=0
INFINALITY_FT_USE_VARIOUS_TWEAKS=true
INFINALITY_FT_AUTOHINT_HORIZONTAL_STEM_DARKEN_STRENGTH=10
INFINALITY_FT_FILTER_PARAMS="11 22 38 22 11"
INFINALITY_FT_STEM_ALIGNMENT_STRENGTH=25
INFINALITY_FT_AUTOHINT_VERTICAL_STEM_DARKEN_STRENGTH=25
INFINALITY_FT_FRINGE_FILTER_STRENGTH=0
FREETYPE_PROPERTIES=truetype:interpreter-version=38

EDIT:
This is the Mactype profile I'm using:
[General]
HintingMode=0
AntiAliasMode=2
NormalWeight=0
BoldWeight=0
ItalicSlant=0
EnableKerning=0
GammaMode=0
LcdFilter=1
BolderMode=0
TextTuning=0
TextTuningR=0
TextTuningG=0
TextTuningB=0
GammaValue=1.0
Contrast=1.0
RenderWeight=1.0
Fontlink=1
HookChildProcesses=1
FontLoader=0
FontSubstitutes=0
LcdFilterWeight=28,56,98,56,28
Shadow=1,1,0,0x0,0,0x0
MaxBitmap=0
DirectWrite=0
HintSmallFont=0
CacheMaxFaces=256
CacheMaxSizes=12554432
CacheMaxBytes=12108864
Name=infinality
[UnloadDll]
[exclude]
[FontSubstitutes]
[Individual]
[ExcludeSub]
[DirectWrite]

Cleartype Settings:
Windows Registry Editor Version 5.00

[HKEY_USERSS-1-5-21-64500032-400834601-3560707841-1116SoftwareMicrosoftAvalon.GraphicsDISPLAY1]
"ClearTypeLevel"=dword:00000064
"EnhancedContrastLevel"=dword:00000064
"GrayscaleEnhancedContrastLevel"=dword:00000064
"TextContrastLevel"=dword:00000001
"GammaLevel"=dword:0000076c

[snowie2000]

You'd better expose your settings via standard API, or via the FreeType offical property API FT_Property_Set/Get

[IceMan81]

So I tried this out. I think the environment variables are being read. I say so because when I first setup the variables, I did not use quotes for INFINALITY_FT_FILTER_PARAMS="11 22 38 22 11" and the rendering was kind of weird. After I added the quotes, there are a change in the rendering quality.

Now I'm not sure if I like this better than the previous mactype rendering or not. I've come across one issue which I'm seeing with some page in FireFox and in Intellij (java IDE) at some font sizes.

See screenshot from Firefox.

I tried various combinations of HintingMode, AntiAliasMode, INFINALITY_FT_FILTER_PARAMS. But not luck getting rid of the clipping

[IceMan81]

@Infinality I'm starting to enjoy the new build now. The following are the environment variables I've defined. Its a combination of the ones you listed above plus a few that I was using before when building freetype with your Infinality patches (the ones maintained by boohomil).

INFINALITY_FT_AUTOFIT_ADJUST_HEIGHTS=true
INFINALITY_FT_AUTOHINT_HORIZONTAL_STEM_DARKEN_STRENGTH=10
INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS=true
INFINALITY_FT_AUTOHINT_SNAP_STEM_HEIGHT=100
INFINALITY_FT_AUTOHINT_VERTICAL_STEM_DARKEN_STRENGTH=25
INFINALITY_FT_BRIGHTNESS=0
INFINALITY_FT_CHROMEOS_STYLE_SHARPENING_STRENGTH=0
INFINALITY_FT_CONTRAST=0
INFINALITY_FT_FILTER_PARAMS="20 20 30 20 20"
INFINALITY_FT_FRINGE_FILTER_STRENGTH=0
INFINALITY_FT_GAMMA_CORRECTION="0 100"
INFINALITY_FT_GRAYSCALE_FILTER_STRENGTH=0
INFINALITY_FT_STEM_ALIGNMENT_STRENGTH=25
INFINALITY_FT_STEM_DARKENING_AUTOFIT=true
INFINALITY_FT_STEM_DARKENING_CFF=true
INFINALITY_FT_STEM_FITTING_STRENGTH=25
INFINALITY_FT_STEM_SNAPPING_SLIDING_SCALE=0
INFINALITY_FT_USE_KNOWN_SETTINGS_ON_SELECTED_FONTS=true
INFINALITY_FT_USE_VARIOUS_TWEAKS=true
INFINALITY_FT_WINDOWS_STYLE_SHARPENING_STRENGTH=0

Some relevant mactype settings

; this lcdfilterweight is based on recommendations in the latest freetype docs for balanced results.
LcdFilterWeight=08,77,86,77,08
; sometimes I use HintingMode=2 
HintingMode=0 
AntiAliasMode=4
RenderWeight=1.3
TextTuningR=3
TextTuningG=3
TextTuningB=3
NormalWeight=10

Now if I could get rid of the clipping issue mentioned before, then this is really good.

[Infinality]

So, I can verify that at least some of the environment variables do have an effect. However, I'm still not able to see the stem snapping working. The first is Tahoma 8pt (11px) on Fedora 26 with infinality patch. The second is the same thing on MacType with those settings. I'm wondering if some of the functions that I had to replace in the patch in order for it to compile (like strcasestr) are behaving differently with their Windows equivalents, so some variables aren't being picked up.

[Infinality]

@snowie2000 - That is definitely a better way of doing it, but I would only want to do that if the code becomes part of freetype. In the patch's current state that is very unlikely.

[snowie2000]

@Infinality The clipboxfix is not working in this test build because I am trying some new thoughts on it.
It's not related to your patch.

[IceMan81]

@snowie2000 That explains it! Thanks for clarifying. Look forward to using a Infinality patched mactype with the new clipbox fix in place!

[IceMan81]

@Infinality the stem darkening variables made a big difference for me.
INFINALITY_FT_STEM_DARKENING_AUTOFIT=true
INFINALITY_FT_STEM_DARKENING_CFF=true

[IceMan81]

@Infinality How did you arrive at LcdFilterWeight=28,56,98,56,28, is that by trial and error or is there some reasoning behind those numbers.

[Infinality]

@IceMan81 Those are the 256-based equivalents of the 100-based 11,22,38,22,11 in my original settings.

(11,22,38,22,11) * (256/100) = (28,56,98,56,28)

And, I just found that 11,22,38,22,11 was the most visually pleasing to me.

[IceMan81]

@Infinality Interesting. My understanding from the freetype documentation was that the 100 is actually 0x100 = 256 decimal.

https://www.freetype.org/freetype2/docs/reference/ft2-lcd_filtering.html#FT_LcdFilter

[Infinality]

That's correct. I scaled most of the values in the INFINALITY_FT_ environment variables so that they were on a scale of 0-100, for consistency and simplicity. Internally it converts back into scale of /256. Granted, you lose some granularity, but for the amount of perceptible difference in 1% change of a subpixel intensity I figured it was negligible.

[IceMan81]

@snowie2000 Any chance you might have a infinality patched mactype build with ClipBoxFix included?

[snowie2000]

Clipboxfix needs a good polish and I think @Infinality may have something to do with his patch too. I'll build it for testing once Infinality thinks he is ready.

[Infinality]

@snowie2000 - My thoughts:

• I'm still not able to see the stem snapping working on the patched version, and I'm not sure exactly why, given that the environment variables have been set on my system. However, if other people are noticing a benefit from the patches already, then I'd say by all means to release it with the patch, with the understanding that it's still in a "testing" phase.

• Obviously the environment variables aren't the best way to do this (for a few reasons) and it would be better for simplicity to have the options directly in the .ini files. Perhaps you could create options inside the .ini file that correspond to environment variables, and then have the mactype code set the environment variables in the execution environment?

• I've recently become more interested in getting the unmerged parts of the patch (stem snapping / alignment, emboldening, thickening, etc.) rewritten to be faster and more accurate. I don't know how long this would take because I haven't looked as specifics yet. I think the general approach I have is good, and maybe good enough to actually make it into Freetype natively if it works like how I'm planning. So, the code (and the way you'd call it in mactype) may change eventually.

[IceMan81]

@snowie2000 Are you in the process of poilishing the clipboxfix implementation?

[IceMan81]

@snowie2000 Any chance you can put out a build for the infinality patch which also includes the ClipBoxFix patches?

[snowie2000]

Some days later.

[IceMan81]

@snowie2000 Would you consider including the latest freetype with that build?
In freetype 2.8.1,

By default, FreeType now offers high quality LCD-optimized output without resorting to ClearType techniques of resolution tripling and filtering. In this method, called Harmony, each color channel is generated separately after shifting the glyph outline, capitalizing on the fact that the color grids on LCD panels are shifted by a third of a pixel. This output is indistinguishable from ClearType with a light 3-tap filter.

[IceMan81]

@Infinality Do you have updated patches that work with freetype 2.9?

[snowie2000]

@Infinality I have replaced all your "getenv" calls with my version and now they can be changed via profile, but so far as I tried, most of your parameters have no effect at all. I'm wondering if I should publish a version with your last mod.

[snowie2000]

@Infinality I have recompiled the freetype with gcc and succeed in linking with MacType, but still got no luck.
Any parameter besides "INFINALITY_FT_USE_VARIOUS_TWEAKS" has no effect.

[IceMan81]

@snowie2000 Could you try if these variables
https://github.com/snowie2000/mactype/issues/366#issuecomment-338984581 here
make a difference? Previously I had found that these variables along with some others that @Infinality had provided made a difference.

INFINALITY_FT_STEM_ALIGNMENT_STRENGTH=25
INFINALITY_FT_STEM_FITTING_STRENGTH=25

For example, if you change these two to 100, you should see some difference.

[snowie2000]

No, absoultely no difference as I can tell.

[IceMan81]

That's Interesting. Maybe it depends on the profile we are using... - especially the lcd filters.

[snowie2000]

I've debugged the source and I'm 100% sure that it (FreeType) indeed got the assigned value from the profile, it just doesn't make any difference for some reason.

[IceMan81]

I'm speculating here...

Wondering if the sensitivity of the values associated with these env variables depends on the value of the lcd filters, rendering weights etc., among other things. For example, if the weights are high, resulting in thicker fonts, then maybe the changes from these variables are not so visible.

INFINALITY_FT_STEM_DARKENING_AUTOFIT=true
INFINALITY_FT_STEM_DARKENING_CFF=true
INFINALITY_FT_STEM_ALIGNMENT_STRENGTH=25
INFINALITY_FT_STEM_FITTING_STRENGTH=25

Do you mind sharing your build?

[snowie2000]

Absolutely not.
Here you go: ifinality-patch-pre-pre-alpha.zip
(together with a simple instruction file)

Also, it is compiled with the latest source with my latest clipboxfix implementation and other bugfixes.

[snowie2000]

Environments are not required at all, nor will them be read. (even the standard "FREETYPE_PROPERTIES=truetype:interpreter-version=38" is not required, it is already hardcoded).

[IceMan81]

Is the default value for INFINALITY_FT_FILTER_PARAMS set to "1 1 1 1 1" to avoid conflict with LcdFilterWeight?

[snowie2000]

@IceMan81 No, it's just a mistake of the demo.txt file. The actual default value is the same as the value suggested by @Infinality : "11 22 38 22 11"

[IceMan81]

@snowie2000 So I tried out the build, and as before it makes a difference. The fonts are sharper (better clarity), so I definitely feel that those VARIABLES are working. INFINALITY_FT_FILTER_PARAMS with corresponding values for LcdFilterWeight has noticeable impact. You may notice multipe LcdFilterWeight values commented out. They are the different values I tried with along with the corresponding values I used for INFINALITY_FT_FILTER_PARAMS.

And thanks for the new ClipBoxFix implementation - looks good so far.

The only issue I have right now is an occasional BLUE SCREEN. Its happened twice so far and I haven't been able to determine the reason for the BDOD.

This is the contents of my mactype profile ini file

[General]
Name=Win7 Opt Ges
Icon=..\mactray.exe,013
HookChildProcesses=1
HintingMode=0
;4 = Light - LCD , but I think it should be LCD
AntiAliasMode=4
;this is very very good, i.e. no shadow - DO NOT CHANGE
shadow=1,1,0,0x0,0x0,0x0
MaxHeight=150
UseMapping=1
;Windows type font linking - should be better than Freetype
;1 = FreeType character table
FontLink=1
; 2- complete replacement
FontSubstitutes=2
; 0 - needed for freetype options
FontLoader=0
GammaMode=0
GammaValue=1.0
RenderWeight=1.3
Contrast=1.0
TextTuning=0
;For LCD use the below settings for TextTuning
TextTuningR=0
TextTuningG=0
TextTuningB=0
NormalWeight=2
BoldWeight=0
ItalicSlant=1
LcdFilter=1
LoadOnDemand=1
CacheMaxFaces=256
CacheMaxSizes=33554432
CacheMaxBytes=67108864          
EnableKerning=0
BolderMode=0
MaxBitmap=0
DirectWrite=1
HintSmallFont=1

;256 - excellent
;LcdFilterWeight=08,77,86,77,08

; 266 - Infinality - 11 22 38 22 11
;LcdFilterWeight=28,56,98,56,28

; 252 - Infinality - 11 22 33 22 11
;LcdFilterWeight=28,56,84,56,28

; 262 - 15 20 32 20 15
LcdFilterWeight=38,52,82,52,38

; 256 - 15 20 30 20 15
;LcdFilterWeight=38,51,78,51,38
;LcdFilterWeight=38,52,76,52,38

; 255
;LcdFilterWeight=38,51,77,51,38

; 281 - 20 20 30 20 20
;LcdFilterWeight=51,51,77,51,51
;LcdFilterWeight=51,51,78,51,51

[ExcludeModule]
DWM.EXE
ssd.exe
WmiPrvSE.exe
mt64agnt.exe
proquota.exe
FoxitReader.exe
TelerikControlPanel.exe
atmgr.ex
protect.exe

[Experimental]
ClipBoxFix=1

[UnloadDll]
dwm.exe

[exclude]

[FontSubstitutes]

[DirectWrite]
RenderingMode=5
GammaValue=1.0
;GammaValue=1.15
Contrast=1.0
ClearTypeLevel=1

[Individual]

[excludeSub]

; Add the follow parameters to your existing profiles and modify them according to your need.
; If any of the values are missing, default values will be used (and what you see below are also their default values).
[Infinality]
INFINALITY_FT_AUTOFIT_ADJUST_HEIGHTS=true
INFINALITY_FT_AUTOHINT_HORIZONTAL_STEM_DARKEN_STRENGTH=15
INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS=true
INFINALITY_FT_AUTOHINT_SNAP_STEM_HEIGHT=100
INFINALITY_FT_AUTOHINT_VERTICAL_STEM_DARKEN_STRENGTH=30
INFINALITY_FT_BRIGHTNESS=0
INFINALITY_FT_CHROMEOS_STYLE_SHARPENING_STRENGTH=0
INFINALITY_FT_CONTRAST=0
INFINALITY_FT_FILTER_PARAMS="15 20 32 20 15"
INFINALITY_FT_FRINGE_FILTER_STRENGTH=0
INFINALITY_FT_GAMMA_CORRECTION="0 100"
INFINALITY_FT_GRAYSCALE_FILTER_STRENGTH=0
INFINALITY_FT_STEM_ALIGNMENT_STRENGTH=25
INFINALITY_FT_STEM_DARKENING_AUTOFIT=true
INFINALITY_FT_STEM_DARKENING_CFF=true
INFINALITY_FT_STEM_FITTING_STRENGTH=25
INFINALITY_FT_STEM_SNAPPING_SLIDING_SCALE=40
INFINALITY_FT_USE_KNOWN_SETTINGS_ON_SELECTED_FONTS=true
INFINALITY_FT_USE_VARIOUS_TWEAKS=true
INFINALITY_FT_WINDOWS_STYLE_SHARPENING_STRENGTH=0

[snowie2000]

I've found that it crashed my webstorm when I scrolled through the font list in the setting dialog.

I'll fix it soon and release a beta.

Plus, the mactray is ready too.

[IceMan81]

@snowie2000 fyi, so far I've seen the BSOD only once.

[IceMan81]

@snowie2000 I'm seeing some memory issues, where my Win 7 is running out of memory after a long period of time. Quite hard to say that this has got something to do with the build, but this is probably the only significant change I have made on my system.

Just passing along any information that might be useful.

[snowie2000]

Okay... Thanks and I'll look through all the changes.

[Infinality]

I'm testing out the alpha as well. I can definitely tell that it's working on certain fonts, like Segoe UI, but still not sure on ones like Consolas. I might just need to reboot though to freshen everything up. Thanks for incorporating this!

[Infinality]

After some more testing, I don't think the stem alignment code is being run properly. If it runs with the ENV_VARS that IceMan81 has set, It should be aligning stems. Arial 13px is a good one to test with because you can see the alignment pretty easily. Here is an example from a Linux system running freetype-infinality:

Notice the vertical stems:

I haven't looked at the code, so I don't know what needs to be done, but this at least should provide a visual cue you can check for.

[IceMan81]

@snowie2000 Do you see anything that might explain this behavior?

[IceMan81]

@snowie2000 Does the new beta release include the infinality changes as well?
https://github.com/snowie2000/mactype/releases/tag/1.2018.917.0-beta

[snowie2000]

No, it doesn't. Since there seems to be no way to make stem alignment working and there is no new version of patch comes out supporting the freetype 2.9.1, I decide to go with freetype original.

[IceMan81]

@snowie2000 Okay, are there other changes in the Beta compared to the infinality-alpha version here?

[snowie2000]

They are all listed in the release note. I mean, that's all I still remember so far.

[IceMan81]

@snowie2000 OK, I thought the stuff in the release may have already been included in the infinality-pre-alpa release

[snowie2000]

I found some bugs after that build, and I have rewritten the process capture routine for the tray app.

[IceMan81]

@snowie2000 New build works well, though I still think some of the infinality changes make it even better, esp stem darkening and stem alignment. I always felt stem alignment worked to some extent because there was a noticeable difference when changing stem alignment and stem fitting paramters.

@Infinality Would you have a infinality patch for freetype 2.9.1 ?

[Infinality]

I don't have a patch currently for 2.9.1, but I know some others out there have been keeping up on it. I'll see if I can find one, otherwise I'll try to patch it myself, because I'd like to see the stem alignment code on Windows too. :)

[IceMan81]

@Infinality if you could provide a patch for 2.9.1, that would be awesome! Yes, if infinality stem alignment would work on Windows like on Linux, it would be fantastic. Look forward to it.

[Infinality]

I haven't actually tested this, but it appears there is a patch that works with 2.9.1 here:
https://github.com/archfan/infinality_bundle/tree/master/01_freetype2-iu

[Infinality]

There was a tweak I needed to make in order to get it to patch freetype. Attached.

0001-infinality-2.9.1-2018.06.21.fixed.patch.txt

[snowie2000]

Ok, I'll give it a try then.

[snowie2000]

@Infinality So, there are apparently two patches. Which one should I use? Or should I use them both?

[IceMan81]

@Infinality Thanks for posting the patch.
@snowie2000 I think its the second patch file, the one that's attached.

[IceMan81]

@snowie2000 does the patch work?

[snowie2000]

@IceMan81 patch applied, but the project can't be built with MSVC anymore.
There is still a lot of work to do.

[IceMan81]

@snowie2000 that's painful. Did the freetype Windows build change?

[snowie2000]

It introduced some headers that msvc doesn't include out-of-box