Hello Werner,
do I understand this correctly:
1. The new engine only works for .otf fonts with included hints and does
nothing for .ttfs
2. Setting the new engine as the default like in your mail sets it up
automatically for all .otf fonts regardless of hinting settings in
fontconfig, meaning
Thanks for the clarification :) Say, are there parts or tricks in the
new engine that could be carried over to .ttf rendering or the
auto-hinter? I would love to see improvements to typeface fidelity with
hintslight :)
Regards,
Nikolaus
___
Hello Werner,
while testing the fantastic new engine, I found that much prefer to turn
off stem darkening, because it really makes CFF fonts stand out compared
to (autohinted) Truetype fonts... It's jarring to switch between
websites and alternate between fat and thin looking text. I'm
The most important dependency is on linear blending (or gamma
correction) in the compositing of glyph images onto the screen. The stem
darkening function assumes blending with a gamma close to 1.8. If linear
blending is not used (e.g., gamma 1.0) then black text will appear too
dark. This might
Neither does mine (Ubuntu 13.10), but I copypasted this from somewhere:
$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/bzip2.pc
prefix=/usr/__arch__
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libbz2
Description: high-quality library for compression and
Hello list,
I'm following git master and just noticed that evince refuses to start
with the above error. I'm on Ubuntu 13.10 x86_64. Anything I can do to
help track down the bug?
Regards,
Nikolaus
___
Freetype-devel mailing list
Hello devs,
I just compiled master and got what's in the attached picture. I was on
8a94b1efd6cfe76ffbd66e9315542c9438a34722 before I think and all was fine.
Regards,
Nikolaus
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hello list,
I just found my old bookmarklet for readability.com:
https://www.readability.com/bookmarklets. I wanted to look at some
article and set the font to Mercury in the second-lowest size (Aa-menu
on the left). Lots of over- and/or undershoot, see:
Yes, I'm on master (5f18a0c...). I'll send you a file, but I'm not sure
I extracted it correctly.. Maybe have a look at it yourself with the
bookmarklet? No extension necessary, just drag it to your favorites and
invoke it on a page you want to read-ify.
I'm not sure... it displays fine on a Mac.
I found something better, have a look at
http://www.typography.com/fonts/mercury-text/webfonts/ and
http://www.typography.com/fonts/mercury-text/webfonts/mercuryssm-book.
The example text at 18px demonstrates what I reported, other sizes look
fine.
Unfortunately, FreeType's source code is not sufficiently documented.
It would be great if you could add comments while walking over the
various functions that I can then further massage and commit.
Alright, will get back to you once I understand.. something ;)
Speaking of understanding, I'm
I need to figure out where to best place the darkening calculations
so they are done just once per face/size. And how to obtain
stdVW/stdHW.
Yes :)
Thanks for your helping along so far :) I spend the day looking for a
good place to do and store the calculations and am stumped again. I want
I forgot to attach the patch. Duh.
diff --git a/include/freetype/ftautoh.h b/include/freetype/ftautoh.h
index cf7b76f..68d59e7 100644
--- a/include/freetype/ftautoh.h
+++ b/include/freetype/ftautoh.h
@@ -439,6 +439,36 @@ FT_BEGIN_HEADER
*/
+
Hi list,
so I just finished a very rough prototype for stem darkening for the
autohinter. This is not meant for inclusion into master but rather as a
starting point for discussion. Apply patch against master.
The code has numerous problems:
1. The function to compute how much darkening to
I just noticed that the darkening calculation might be off, making stuff
excessively bold. Here's a new patch. Sorry :(
diff --git a/include/freetype/ftautoh.h b/include/freetype/ftautoh.h
index cf7b76f..68d59e7 100644
--- a/include/freetype/ftautoh.h
+++ b/include/freetype/ftautoh.h
@@ -439,6
Would be easier if you push a tree to github.
Done.
https://github.com/madig/freetype2/tree/stem-darkening-autohinter
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
As soon as you switch to a new size, simply recompute the values.
Done! I'm almost there. I have extended AF_FaceGlobals to hold:
...
FT_UShort stem_darkening_for_ppem;
FT_Posdarken_x;
...
and modified af_loader_load_g() to do:
...
error = FT_Load_Glyph( face, glyph_index, flags );
I'll invite to have a look at the auto-hinter implementation, probably
coming up with a patch!
Ok, so I'm still trying to wrap my head around FT's internals and how it
all works (anybody got some recommendations on how to explore an unknown
codebase and getting a feeling for it?) and stumbled
Hello Dave,
your response has motivated me to spend some time looking into linear
blending :) It turns out that other people had the same idea before, I
found https://bugs.freedesktop.org/show_bug.cgi?id=28549 but the
discussion there seems to have died quickly and the bug reporter told me
he
(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 the patch to the bug report; maybe
this helps move the dinosaurs...
The author noted that CAIRO_DEBUG=xrender-version=-1
I'll take a look soon... It's a hard problem. There's no easy answer..
Thanks :)
I just saw that Markus Trippelsdorf posted two patches to this list for
Qt5 and Skia to enable proper blending. It was even on by default in Qt5
when someone complained that fonts looked different and too thin
Hello list,
I've been playing around with the CFF renderer again because font
rendering is a dear topic to me. What immediately stands out is that
rendered fonts are much thicker than what the autohinter puts out. This
creates a somewhat strong contrast between local .otfs and web fonts
when
001
From: Nikolaus Waxweiler <madig...@gmail.com>
Date: Sat, 24 Oct 2015 16:04:24 +0200
Subject: [PATCH 5/5] Implement the actual emboldening in af_loader_load_g().
---
src/autofit/afloader.c | 103 +++--
1 file changed, 99 insertions(+), 4 deletions
There is a cool image attached to this bug report:
https://bugreports.qt.io/browse/QTBUG-41590
Gamma correction makes black text lighter and white text heavier,
i.e., has opposite effects, i.e., you cannot use one universal value.
Hold on, that's intended: "Gamma 1.8, darkened" is *exactly*
Yes, please! This makes review (now and in the future) much easier.
Alright :) I'll look for some tutorial on how to best do this in git.
Out of curiosity, how do you develop new features to be merged to
master? Experimental/chaotic branches followed by a second clean-room
branch?
My monitor is sRGB. Yours is likely too. We are looking at the corrected glyphs.
No we aren't, precisely because of our sRGB monitors. The bitmaps
FreeType produces wouldn't need to be corrected if our monitors had a
gamma curve of 1.0 (= linear space), where 1 + 1 = 2. But sRGB describes
a
On my Eizo EV2736 with a color profile, the moire pattern is least
visible between 2.2 and 2.4.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Perhaps, this is the explanation I was looking for. You are basically
saying that sRGB imposed by the monitor is not a good idea for high
contrast text rendering and has to be undone. I can buy that. So when
you talk about gamma of about 2 you actually mean power of about 1/2.
I was confused.
- I think stem darkening should be tested without gamma applied for
many reasons. Your monitor might have additional gamma correction
settings, which might be different from mine. Gamma correction works
against you when you render light text on dark background (I wish
ftview could do that). I
Welcome to the One True Belief, brother. The world needs more linear alpha
blending and gamma correction. Spead the gospel!
The effect is also nicely visible at 40ppem with all the other glyphs -- they
just look smoother overall.
___
Freetype-devel
FreeType should offer blending! I think the API is there but needs to
be massaged.
FT_Bitmap_Convert could be the function that does blending on top of
its current narrow use.
FT_Bitmap structure has many wonderful fields like palette and
palette_mode already reserved
You mean rendering libs
> OK. To summarize: `slight mode' would mean stem darkening for CFFs
> but no stem darkening for auto-hinted fonts, right?
Aah, wait! Light mode should not imply stem darkening for anything. Only
when the lib specifies an additional i-want-to-do-LAB+GC load flag should
stem darkening be
Thanks for the comments :)
You might consider a brief mention of cases that are not black-on-white.
Ah, yes, I forgot that.
I don't understand the lines at the bottom, where I see "I don't want
this" and "---". Is something missing here?
It's supposed to be a heading. Will change it.
Hey list,
so I've been discussing some proposed font configuration changes in
#gnome-design on IRC. Someone insisted that my aim of removing all
opinionating about hinting in the layers above fontconfig is misguided
(@Behdad: https://bugs.freedesktop.org/show_bug.cgi?id=11838).
After some back
I'm also running Jan's patch and have disabled stem darkening. And I
think this approach is actually a good idea.
1. Fontconfig's hintslight is translated to FT_LOAD_TARGET_LIGHT by
cairo and probably also Qt. And so far, hintslight meant the autohinter
regardless of the "autohint" property.
I was thinking along the lines of leaving no_stem_darkening=false in and
using a new load flag to indicate that you really want darkened stems. But
if you put it that way, maybe it's much more elegant to tell
toolkits/renderlibs to set the appropriate properties beforehand. You
should want it for
I think the smooth rasterizer already produces coverage maps in
linear space? How does gamma-correct rendering (not blending)
work right now?
It doesn't, at least not in the common toolkits ;) The freetype-demos do
it however, but I haven't looked at the source code.
Good, thanks :) Then I'll work on stem darkening soon.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Thanks! Telling people to switch to slight hinting will be much easier than
telling them to mess with fontconfig.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Hm, so how about the following:
* FT_LOAD_TARGET_LIGHT is changed to mean "Use native Y-only-snapping
with linear advances if driver and font supports it and Y-only
autohinter with linear advances otherwise". That's broadly comparable to
what happens on Windows with DirectWrite.
*
I know it's a long ways out, but a compile time option shouldn't be a
problem. Qt can check at compile time if FT delivers and distro packagers
control Qt and FT version and compilation options anyway.
___
Freetype-devel mailing list
Wait, this is an optional flag that libs have to use explicitly. So perfect
backwards compatibility :)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
PS: As native ClearType fonts are supported already, they should be a
good target for FT_LOAD_TARGET_LIGHT. So the responsible function should
check if a CFF font contains hints and if a TrueType font contains the
"I'm a native ClearType font!"-flag. If those are present, poke the
native
True, but they achieve LIGHT's goal and are a start. Someone wrote a
patch to trigger native CFF hinting in LIGHT already and will send it
here shortly :)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hi List,
so I'm currently trying to figure out which hinting paths a glyph can
take from the perspective of fontconfig. So far I found:
TrueType:
- hintslight, autohint true/false: autohinter, fits to Y-axis
- hintmedium, autohint false: native, hintfull without X-fitting?
- hintmedium,
I have attached my personal fonts.conf, it enables native (Y-axis)
grid-fitting for CFF fonts and the Y-axis autohinter-grid-fitting for
everything else. Also, RGB subpixel rendering if compiled in and the
light LCD filter to counter the blurriness of non-gamma-corrected glyphs
somewhat.
Would it be possible to implement TrueType stem darkening without
using hinting like in the CFF case? I really think that darkening and
hinting should be orthogonal.
I think so, too. Currently, stem darkening is basically a proof of
concept bolted on to the autohinter. My idea is to turn stem
It's actually Liberation Sans -- so ClearType rendering. And switching
to light and turning on the warper gives a different look.. mh. I'll
simply avoid medium in my proposed fontconfig confs.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Firefox defaults to GDI-style rendering for a handful of TrueType fonts.
The first thing I do when I set up a new Firefox instance on Windows or
fiddling with other people's computers when they aren't looking is setting
gfx.font_rendering.cleartype_params.force_gdi_classic_for_families = ""
Any progress, Alexei? :)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
One peculiarity to note: If in `native ClearType' mode, a modification
of a glyph's advance width is properly executed by the MS hinter.
However, the MS rasterizer ignores it, always using linear advance
widths in modern Windows versions. Previous versions supported a
`compatible-width
gfx.font_rendering.cleartype_params.force_gdi_classic_for_families
indeed contained something by default, I tried to reset to empty string,
no change. Also if it really applies to specific family my guess would
be that RasterInfo font won't be affected, as it's never on the list by
default.
Did
Hey list,
I figured I should write about the new changes before they hit the
unsuspecting world in a future release. Here's a first draft I just
wrote. Please comment.
It is supposed to go on the main news page of freetype.org (Werner? :)).
I'll also try to spread it to LWN.net, Phoronix and
Hi list,
I'm using my autohinter stem darkening patches daily and so far only
have stumbled over a minor rendering difference and one major fault:
DroidSansFallback.ttf renders excessively bold after
FT_Outline_EmboldenXY treatment, meaning, the same emboldening values
lead to a much stronger
I fixed the excessive emboldening bug by modifying the last step of
computing the emboldening amount: divide by the emRatio, as
FT_Outline_EmboldenXY or at least emboldening inside the autohinter
apparently depends on the units per EM of the font. This also fixed
something else: fonts with
The look of the function is documented and it blows my mind. I want to
know what they smoked. You simply cannot find such beasts in nature
short of quantum mechanics. I simply cannot trust that it was
optimized rationally by looking at the rendering results, because
optimizing in 8-dimensional
OK, how do I get at the CFF-PrivateDict SFNT table? FT_Sfnt_Tag doesn't
define anything. Do I have to instantiate a CFF_Decoder?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
The simplest is to check if you see any difference with this set of
parameters:
Thanks. Quick comparison shot:
http://postimg.org/gallery/2x7v9bhde/f0fbee3e/. The difference here is
subtle. It seems to make Source Sans Pro lighter (Adobe CFF engine)
while not changing Linux Libertine
I pushed some changes to
https://github.com/madig/freetype2/tree/stem-darkening-autohinter. I
have that branch installed system-wide for proper dog-fooding ;)
I changed the strategy to get the standard_width of a face. Instead of
relying on the hard-to-follow workings of the style analyzers,
Where's the problem? The auto-hinter provides different standard
width values depending on the script. It tries up to three characters
(cf. the last three arguments to the `SCRIPT' macro in file
`afscript.h') in function `af_latin_metrics_init_widths' for finding a
standard width. As soon as
I'm awaiting your patches :-)
Heh ;)
Why `once per size'? The auto-hinter computes the standard widths in
*font units*, this is, the values are unscaled!
Ah, yes, thinko. I meant once as opposed to several times due to lazy
evaluation.
___
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.
If not, I will need to rethink my approach ;)
Thanks a lot for your input, it helps to understand what the code is
doing :) Maybe I'll add your comments as comments somewhere in the code ;)
I now have a few ideas:
- If font has OS/2 weight class, use that for stdHW/VW. See if that
maybe is good enough for our purposes.
- If not, use
So let's stay with what we have, for the sake of a uniform interface
to stem darkening.
Well, if we need different parameters for horizontally snapped outlines
like Dave said? More experimentation is necessary I think...
___
Freetype-devel mailing
I had a quick look at various fonts and darkening seemed fine, but CJK
glyphs (SourceHanSansCN-Regular.otf) appeared a bit thin compared to the
CFF engine. Will investigate... some other time.
I think I figured it out. Reverted commit
c5b5e469b34ddc87fa379bfa0a5379835191ee23.
Turns out my
I just left the house and suddenly realized that the conversion from font
to device pixel units could be wrong. Emboldening by at most 0.4 Pixels
translates to at most 26 times 1/64th of a device pixel (ft_pos). I think I
saw bigger numbers. Gah! Will check the code tomorrow and feel stupid in
the
Very nice, thanks! Unfortunately, I currently don't have sufficient
time to review the code; probably in the beginning of October.
Sure, what matters is that it finds its' way to master and to the masses
eventually :) I'll test out Dave's 300,250,250,0 parameters in the mean
time and maybe
I'm a giant dunce. I forgot to convert character space to device
space... No wonder FT_Outline_Embolden produced garbage, especially at
small sizes. Emboldening looks good now with the default CFF parameters
without any tweaking!
http://postimg.org/gallery/vgi21eka (all with gamma correction,
Don't use .jpg for screen shots. The compression hinders analysis of the
rendered pixels. I recommend lossless .png.
That's what I uploaded, click the image ;)
Are you missing a units-per-em normalization somewhere? I.e., 1000 CFF
vs. 2048 TTF? Could that be causing too much darkening?
Hm,
I used a zoom-in tool to examine the pixels in your before and after
screen shots. The left sides of the stems were unchanged while the right
sides were darker.
Ah, okay ;)
Alexei has explained how this is the result of using the existing
emboldener. I don't think it is a problem. It only
Question: I see the extra weight is applied only to the right hand side
of the vstems. Is this because of the way the emboldening function
works? Have you noticed any issues with the sub-pixel translation that
this causes? (I don't think so, and they are unhinted anyway)
How did you see that?
I was going to write a long mail and moan about how complicated FreeType
is and how my stem darkening just wasn't pleasing to look at.
Then I fiddled around some to prove a point and suddenly LOOK AT THIS:
http://postimg.org/image/el0egghrl/full (no emboldening)
After a bit of testing, I think I know where the glitches come from.
They are usually digits (0, 2, 8), overshoots (C) or other parts (lower
belly of R, see the last two comparison shots) being snapped to 1 pixel
above where they should be. Emboldening probably lands the top of the
stems
I've been using the patch since yesterday and spotted no anomalies so
far in my daily routine. Anything specific to look for?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
While testing Alexei's scaling trick, I rediscovered an old source of
irritation (apart from the barely visible dot on the "i").
1. Download https://www.google.com/fonts#UsePlace:use/Collection:Open+Sans
2. Load OpenSans-Regular.ttf in ftview, look at sizes 10, 13, 15, 19
3. Press A and B and
(repost to the list because I forgot to correct the addressee)
> This `fix' is purely accidental, unfortunately. There is no guarantee
that you get similar well-looking results with other fonts.
I noticed already, Open Sans Bold likes to snap 1 pixel too high.
You might convert metric
Emboldening changes the outline but not the metrics or blue zones. It
is up on you to deal with it. Here is an idea to brush it aside
gracefully: embolden and scale back. Yes, emboldenig changes the
bounding box predictably, so that you can restore it by scaling back.
This will eat away some of
I'm currently running Dave's filter on my crappy laptop screen, will
see how it goes.
Quick status report: I find Dave's filter quite pleasing actually on
both crappy laptop screen and my calibrated entry-level Eizo monitor.
It's fuzzier than the current default filter, yeah, but some of the
Headings are better, nice :) And I like the TOC. But please re-add the
note that Graham Asher proof read the text! And I apparently forgot one
instance of "toggable" that should be "toggleable".
___
Freetype-devel mailing list
Hey,
so I was wondering what work exactly is left to support TT interpreter
v38 and up? I'm interested in adding native ClearType to the definition
of slight and Jan says, we need v38 and up for that. If I remember
correctly, that is what Infinality set out to do and Behdad mentioned
that
2nd revision of my post. Reorganized headings and tried to better
explain the blending examples.
diff --git a/index.html b/index.html
index c92d541..e4493a0 100644
--- a/index.html
+++ b/index.html
@@ -106,71 +106,9 @@
FreeType 2.6.2 ships with three interesting details for
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 and has nice
If the entire text could be made available in a formatted and readable
form, I would be happy to proof-read it for typos, grammar and correct
English.
Gladly! Love must be spread correctly (old German sentiment). Thanks :)
freetype-262-blog.odt
Description:
It must
(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
Regarding the freetype.org documentation stuff, I don't have the time
(and admittedly the interest) to do a move. Nikolaus, do you
volunteer to set up everything? If yes, could you give an outline of
the necessary steps?
Yes :) Neither ETAs nor outlines yet because I actually have no idea ;)
3rd revision, proof-read by Graham Asher, to be applied to the 1st
revision.
@Graham: Thanks a lot, I applied your corrections whole-sale :) Scream
if I overlooked something. And thanks for the compliment ;)
diff --git a/index.html b/index.html
index c92d541..ef6450e 100644
--- a/index.html
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?
I personally do not like how this is done. Also the truth remains that
ClearType patents will prevent this
MS created too many buzzwords :-(
`Native ClearType ' means `no ClearType backwards-compatibility
mode'
`natural ClearType mode' is DWrite talk for subpixel positioning
`natural ClearType widths' is GDI talk for integer pixel positioning
with subpixel rendering.
Now I'm more
There are a whole bunch of improvements for the auto-hinter not yet
integrated, but this doesn't affect the TT engine.
Mhm, sounds like a job for me. I'll put it somewhere on my todo list :P
There is a misunderstanding, see above. `Native' ClearType doesn't do
y-only hinting! It's simply
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 threadsafe eventually.
How would you implement custom parameters?
___
Freetype-devel
Hey list,
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
Hey Werner,
I know you don't find this important, but I like cleaning up. ;) Does
GUESS_VECTOR() in ttinterp.c do anything now? As in
if ( opcode < 4 )
{
exc->GS.projVector.x = AA;
exc->GS.projVector.y = BB;
exc->GS.dualVector.x = AA;
exc->GS.dualVector.y = BB;
Hey list,
Please have a look at
https://git.gnome.org/browse/cantarell-fonts/plain/otf/Cantarell-Regular.otf?id=06bd50f988bcdf0c428a2d4be38f424b8e6596df
at 14ppem with the light autohinter. Since this is an .otf and you can't
force the autohinter in light rendering mode (bug), temporarily
> 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,
> is the SetLcdFilter API.
Hm. So you would only move the
I find the top-to-bottom thing curious. Do you have an explanation why it
works better for these scripts?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
So Alexei, how about you flip the direction for the latin hinter in an
experiment and show us some rendering results? ;)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
__
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
From e9b3098dbbcfe7a313982cb47ab8689eb331e2df Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler <madig...@gmail.com>
Date: Thu, 26 Nov 2015 22:52:19 +0
> Please leave the light one alone. Dave's filter should be default.
That's what I thought, too. I will update the documentation on Friday
hopefully, am abroad right now and forgot to take my working directory
with me ;)
I'm currently running Dave's filter on my crappy laptop screen, will
see
Here's my promised documentation including the filter change. Please review.
>From b1d0881d06bda44f090053dc90cd2a6a75271799 Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler <madig...@gmail.com>
Date: Fri, 27 Nov 2015 19:26:00 +0100
Subject: [PATCH] Change default LCD filter to normaliz
Ah, I forgot something.
diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index c0e5112..de276d1 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -3068,7 +3068,7 @@ FT_BEGIN_HEADER
/* and apply gamma to get them in a linear space,
1 - 100 of 467 matches
Mail list logo
