> Any progress on this front? I'd like to tinker with an emboldening
> property so at least Qt and Skia can use it at some point and start
> rendering fonts properly :)
No progress... Patches, please.
Werner
___
Freetype-devel mailing list
Freet
> Any progress on this front? I'd like to tinker with an emboldening
property so at least Qt and Skia can use it at some point and start
rendering fonts properly :)
Ping!
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/
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.
Any progress on this front? I'd like to tinker with an emboldening
property so at least Qt and Skia can use it a
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 Qt, or any other
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 Qt, or any other large-enough
>> platform, there's no global setting, the
>> 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
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,
>> i
> 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
On 15-12-15 05:08 PM, 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 t
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
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 mailin
>> 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
> 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
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.
_
On Thu, Nov 12, 2015 at 11:14 PM, Werner LEMBERG wrote:
>> 1) Switch on stem darkening
>
> This is non-trivial. I've always considered properties of a driver as
> global – consequently, they reside directly in the driver module,
> being part of an `FT_Library' object, and *not* being part of
> `F
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 e
> 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
__
> 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
On Wed, Nov 11, 2015 at 8:42 PM, Nikolaus Waxweiler wrote:
> Thanks! Telling people to switch to slight hinting will be much easier than
> telling them to mess with fontconfig.
I suppose we still have time to add the suggested LOAD flag before the
2.7 release? IMO it should:
1) Switch on stem da
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
http
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
> 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
> 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
> 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 happening.
> 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
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 p
On Tue, Nov 10, 2015 at 7:43 AM, Jan Alexander Steffens
wrote:
> On Tue, Nov 10, 2015 at 1:32 PM, Markus Trippelsdorf
> wrote:
>> The big problem is that enabling linear blending is a compile time
>> option for Qt 5. There is no way to control it at runtime AFAIK.
>
> Isn't this is exactly what w
On Tue, Nov 10, 2015 at 2:03 PM, Nikolaus Waxweiler wrote:
> 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.
On Tue, Nov 10, 2015 at 2:06 P
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
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
Freetype-devel@nongnu
On 2015.11.10 at 13:43 +0100, Jan Alexander Steffens wrote:
> On Tue, Nov 10, 2015 at 1:32 PM, Markus Trippelsdorf
> wrote:
> > The big problem is that enabling linear blending is a compile time
> > option for Qt 5. There is no way to control it at runtime AFAIK.
>
> Isn't this is exactly what we
On Tue, Nov 10, 2015 at 1:32 PM, Markus Trippelsdorf
wrote:
> The big problem is that enabling linear blending is a compile time
> option for Qt 5. There is no way to control it at runtime AFAIK.
Isn't this is exactly what we want? A Qt built this way should pass
FT_LOAD_INTEND_LINEAR... to FreeT
On 2015.11.10 at 13:06 +0100, Nikolaus Waxweiler wrote:
> 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
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.
* FT_LOAD_INTEN
On Nov 10, 2015 09:24, "Nikolaus Waxweiler" wrote:
> Ideally, could this be controlled by an optional FT_LOAD_STEM_DARKENING
flag to FT_Load_Glyph?
Or perhaps a FT_LOAD_LINEAR to express an intent to do antialiasing in
linear color space?
___
Freetype-d
On Tue, Nov 10, 2015 at 9:24 AM, Nikolaus Waxweiler wrote:
> I noticed that Liberation Sans/Serif/Mono and Open Sans looked pretty
> ClearType-y with hintfull
I think that is because they just choose not to do any (or much)
Y-snapping, even though they could, since they were designed with
FreeTyp
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. C
>> 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
On Mon, Nov 9, 2015 at 4:12 PM, Nikolaus Waxweiler wrote:
> So Alexei noted that he found stem darkening too strong. 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.
__
So Alexei noted that he found stem darkening too strong. And it got me
thinking again. As long as cairo/Qt5/Skia and others don't ship with
LAB+GC by default on their X11/Wayland backends, maybe enabling it by
default for the CFF driver and autohinter just creates angry users and
more work for
40 matches
Mail list logo
