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 b
Hi Nikolaus,
I would consider 1.8 to be "close" to 2.2. The exact value is not critical. But
failing to apply a correction is equivalent to gamma 1.0, and does not work well.
It is unfortunate that gamma correction when compositing text is not part of
FreeType. It is part of the graphics engin
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
> I looked through the demo pages he set up[1][2] and found a
> demonstration of concept in the form of a hack of pixman. I made
> the patch apply to the current version 0.32.6 and attached it here
> (I hope it's not too big for the list?). Build the patched pixman
> somewhere and test it from t
(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..
On 15-08-08 09:17 AM, Nikolaus Waxweiler wrote:
> (Repost because I forgot to click "post to list", sorry Werner..)
>
>> Indeed. So why doesn't get this applied? Is there a negative impact
>> somewhere? Perhaps you should
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
> It looks like the potential for change is there, it's just that stem
> darkening for non-CFF and autohinted fonts needs to be in place
> first before the toolkits consider enabling it. I'll have a look
> around to see if I can maybe salvage something.
I'll invite to have a look at the auto-hint
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
> 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?)
Unfortunately, FreeType's source code is not sufficiently documented.
It would be great if you could add
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 tr
> Speaking of understanding, I'm trying to understand how darkening
> works in the CFF driver. So far, I have: cf2_computeDarkening()[1]
> is called twice per font face (CF2_Font =~ FT_Face?) upon
> initialization, once for vertical, once for horizontal stems, and
> calculates by how many pixels b
> My initial idea was to do the calculations after
> af_face_globals_get_metrics() filled in
> 'AF_*Metrics->standard_weight'[1] and store them in
> AF_FaceGlobals->darken. Until I noticed that they aren't redone on
> size changes because AF_FaceGlobals doesn't deal with size stuff.
Yes, the who
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
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 );
Thanks Nikolaus for working on this. This is amazing!
One thing we need to figure out before this goes out is, this will be
introducing drastic weight differences between unhinted, autohinted-light,
autohinted-medium+, and bytecode-hinted. That's not very good. I think at
least unhinted should
>> if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
>>FT_Outline_EmboldenXY(..., ...->darken_x, 0);
This function still needs a bit of work around the corners, both
literally and figuratively speaking. Emboldening is not affine
transformation. It can introduce artifacts. The function has some
c
On 15-08-21 03:17 PM, Alexei Podtelezhnikov wrote:> This function still needs
a bit of work around the corners, both
> literally and figuratively speaking. Emboldening is not affine
> transformation. It can introduce artifacts. The function has some
> crude protection against distortions, but I wan
> On 15-08-21 03:17 PM, Alexei Podtelezhnikov wrote:
>> This function still needs a bit of work around the corners, both
>> literally and figuratively speaking. Emboldening is not affine
>> transformation. It can introduce artifacts. The function has some
>> crude protection against distortion
@Werner: What keeps the subpixel hinting code from being turned on by
default? And "stem width measured along the vertical axis" == stdHW?
Thanks Nikolaus for working on this. This is amazing!
I dream of the day where no one has to suffer crappy font rendering on
Linux. If only distros would
On 15-08-21 11:37 PM, Nikolaus Waxweiler wrote:
> @Werner: What keeps the subpixel hinting code from being turned on by default?
It's extremely slow apparently... Needs someone to study it in detail and
make it fast.
___
Freetype-devel mailing list
Fre
>> A similar argument holds for `af_latin_metrics_init_widths': Only
>> the stem width measured along the vertical axis is used for light
>> hinting.
>
> Meaning, I'd have to modify AF_*Metrics to also compute stem widths
> on the horizontal axis and use that for stemWidth?
I don't think so. Sin
> One thing we need to figure out before this goes out is, this will
> be introducing drastic weight differences between unhinted,
> autohinted-light, autohinted-medium+, and bytecode-hinted. That's
> not very good. I think at least unhinted should get the same boost,
> unless turned off explici
> "stem width measured along the vertical axis" == stdHW?
Yes.
> I was thinking about refactoring the emboldening out into a kind of
> service that font drivers can use internally when they promise to
> hint Y only. But I know too little about FT's internals yet to
> judge if this is actually a
>> No, unless FT_Outline_Embolden() does that, then yes ;)
>
> `FT_Outline_Embolden' *does* change the advance width! You have to
> save the metrics before the call, then restoring the original values.
Don't you mean experimental FT_Glyph_Embolden?
_
On 15-08-21 07:35 PM, Werner LEMBERG wrote:
>> > Same here! Also, it currently mishandles glyphs that have outer
>> > contours with differing directions...
>
> Example call, please.
Here you go. Attached.
behdad
test#1.ttf
Description: application/font-ttf
>> `FT_Outline_Embolden' *does* change the advance width! You have to
>> save the metrics before the call, then restoring the original
>> values.
>
> Don't you mean experimental FT_Glyph_Embolden?
Oops *blush*. Please forget what I've said :-)
Werner
On 15-08-24 12:07 PM, Alexei Podtelezhnikov wrote:
>
>
> Alexei A Podtelezhnikov, PhD
>
>> On Aug 24, 2015, at 6:11 AM, Behdad Esfahbod
>> wrote:
>>
>>> On 15-08-23 11:29 PM, Werner LEMBERG wrote:
>>>
> `FT_Outline_Embolden' *does* change the advance width! You have to
> save the metr
On 15-08-23 11:29 PM, Werner LEMBERG wrote:
>
>>> `FT_Outline_Embolden' *does* change the advance width! You have to
>>> save the metrics before the call, then restoring the original
>>> values.
>>
>> Don't you mean experimental FT_Glyph_Embolden?
>
> Oops *blush*. Please forget what I've said
`FT_Outline_Embolden' *does* change the advance width! You have
to save the metrics before the call, then restoring the original
values.
>>>
>>> Don't you mean experimental FT_Glyph_Embolden?
>>
>> Oops *blush*. Please forget what I've said :-)
>
> Ok I'm not following what's going
Alexei A Podtelezhnikov, PhD
> On Aug 24, 2015, at 6:11 AM, Behdad Esfahbod
> wrote:
>
>> On 15-08-23 11:29 PM, Werner LEMBERG wrote:
>>
`FT_Outline_Embolden' *does* change the advance width! You have to
save the metrics before the call, then restoring the original
values.
>>
>> FT_Outline_EmboldenXY only changes the outline and its bounding box. The
>> dimensions of the letter is changed very predictably by xstrength and
>> ystrength. The outline is shifted by half of the strengths so that the
>> bottom-left of the bounding box stays in place. Makes sense?
>
> Yes,
>>> > Same here! Also, it currently mishandles glyphs that have outer
>>> > contours with differing directions...
>>
>> Example call, please.
>
> Here you go. Attached.
Thanks. Alexei, any ideas how to fix this? Both the auto-hinter and
the TrueType driver contain code to properly handle outl
On 15-08-25 03:29 PM, Werner LEMBERG wrote:
>
> On the other hand: How many recent fonts in the wild have such
> misformed glyphs?
I saw one when developing GLyphy. Note that these are valid fonts according
to TrueType spec. They just don't follow the "recommended" outline winding...
Perhaps i
On Tue, Aug 25, 2015 at 10:42 AM, Behdad Esfahbod
wrote:
> On 15-08-25 03:29 PM, Werner LEMBERG wrote:
>>
>> On the other hand: How many recent fonts in the wild have such
>> misformed glyphs?
>
> I saw one when developing GLyphy. Note that these are valid fonts according
> to TrueType spec. The
On 15-08-25 04:30 PM, Alexei Podtelezhnikov wrote:
> On Tue, Aug 25, 2015 at 10:42 AM, Behdad Esfahbod
> wrote:
>> On 15-08-25 03:29 PM, Werner LEMBERG wrote:
>>>
>>> On the other hand: How many recent fonts in the wild have such
>>> misformed glyphs?
>>
>> I saw one when developing GLyphy. Note
I'm happy to see all of this activity on stem darkening in the past week. It
looks like excellent progress. I'm sorry it was a period when I was on vacation
and away from email. Hopefully, most questions have been answered, but please
let me know if there are outstanding issues that I can help
Hi
On Aug 25, 2015 8:21 PM, "Dave Arnold" wrote:
>
> I'm happy to see all of this activity on stem darkening in the past week.
It looks like excellent progress. I'm sorry it was a period when I was on
vacation and away from email. Hopefully, most questions have been answered,
but please let me kn
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 af_get
Hi Dave,
On 8/25/2015 8:53 PM, Dave Crossland wrote:
> As you noted, stdHW and stdVW are normally obtained from a CFF font
dictionary. For TT, we (at Adobe) estimate stem width values based on the OS/2
weight class. We use three values, light (50/1000), regular (75/1000) and bold
(110/1000).
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
41 matches
Mail list logo
