On Tue, Dec 19, 2023 at 1:02 PM Skef Iterum wrote:
> CFF2 is released, has been for years. As far as I know there's no solid
> convention for ignoring unrecognized operators in a CharString, so this
> would be CFF2 minor 1 at best. Which would be years out in terms of
> support.
>
> Practically s
>
> I think I agree with this - the spec should not bend on
> limitations/quirks/bugs in freetype. It isn't the role of the spec to
> recommend fonts to be built in with special "hints", just because one
> implementation, in its current state, can't render satisfactorily without
> those "hints"
> What you're suggesting, if I understand correctly, is that the existing flags
> available in the glyf implementation, and a new flag made available in the
> CFF2 implementation, be maintained not on the basis of whether a glyph has
> overlap, but by the designer based on whether the FreeType r
I think I agree with this - the spec should not bend on
limitations/quirks/bugs in freetype. It isn't the role of the spec to recommend
fonts to be built in with special "hints", just because one implementation, in
its current state, can't render satisfactorily without those "hints".
And, we mu
The better angels of my nature tell me to just leave this as it is, as
this is archived and may be referenced in the future ...
What you're suggesting, if I understand correctly, is that the existing
flags available in the glyf implementation, and a new flag made
available in the CFF2 implemen
> The 4-fold speed difference is not an optimization, it is a liability
which should be taken explicitly. Some overlaps at single points are not
that noticeable. Only long runs along the axes are bad. So I disagree with
default oversampling even for variation fonts.
Let me explain that not all ove
CFF2 is released, has been for years. As far as I know there's no solid
convention for ignoring unrecognized operators in a CharString, so this
would be CFF2 minor 1 at best. Which would be years out in terms of
support.
Practically speaking I don't think this could wind up being a "this
glyp
I'm afraid the horse has left the barn as far as that goes.
Skef
On 12/19/23 04:23, Alexei Podtelezhnikov wrote:
I would suggest that CFF2 invent a special charstring to mark overlaps
with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement
it in FreeType.
>
> CFF2 is released, has been for years. As far as I know there's no solid
> convention for ignoring unrecognized operators in a CharString, so this would
> be CFF2 minor 1 at best. Which would be years out in terms of support.
We can do it in days for FreeType, then it is a matter of upgra
Why? The sequence 0x0c 0x40 is reserved and not used for example.
> I'm afraid the horse has left the barn as far as that goes.
>
> Skef
>
>> On 12/19/23 04:23, Alexei Podtelezhnikov wrote:
>> I would suggest that CFF2 invent a special charstring to mark overlaps
>> with FT_OUTLINE_OVERLAP
Hi Behdad
>>
>>> Note that freetype does not use the overlap flags to determine the path
>>> fill rule (winding vs even-odd), it always uses winding for TT or CFF2
>>> variable fonts, as the spec mandates; the discussion here is about freetype
>>> using the (TT glyf only) overlap flags to ena
On Tue, Dec 19, 2023 at 11:25 AM Alexei Podtelezhnikov
wrote:
>
> Note that freetype does not use the overlap flags to determine the path
> fill rule (winding vs even-odd), it always uses winding for TT or CFF2
> variable fonts, as the spec mandates; the discussion here is about freetype
> using
>
> Note that freetype does not use the overlap flags to determine the path fill
> rule (winding vs even-odd), it always uses winding for TT or CFF2 variable
> fonts, as the spec mandates; the discussion here is about freetype using the
> (TT glyf only) overlap flags to enable what Alexei call
Note that freetype does not use the overlap flags to determine the path
fill rule (winding vs even-odd), it always uses winding for TT or CFF2
variable fonts, as the spec mandates; the discussion here is about freetype
using the (TT glyf only) overlap flags to enable what Alexei calls "4x4
bilevel
CFF was even-odd. CFF2 is non-zero winding.
behdad
http://behdad.org/
On Tue, Dec 19, 2023 at 9:50 AM Hin-Tak Leung
wrote:
> This is the same as the winding rule concept (overlap once = wounded
> twice) ... I seem to remember one of them is even-odd and the other is
> non-zero, and quite funda
This is the same as the winding rule concept (overlap once = wounded twice)
... I seem to remember one of them is even-odd and the other is non-zero, and
quite fundamental difference between truetype and cff.
On Tuesday, 19 December 2023 at 13:54:21 GMT, Alexei Podtelezhnikov
wrote:
>
>>
>> It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a
>> CFF2 font. Whether that makes sense is one thing I'd like advice about.
>> There's currently no such code.
>
> I would suggest that CFF2 invent a special charstring to mark overlaps
> with FT_OUTLINE_OVERLAP only
> It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a
> CFF2 font. Whether that makes sense is one thing I'd like advice about.
> There's currently no such code.
I would suggest that CFF2 invent a special charstring to mark overlaps
with FT_OUTLINE_OVERLAP only when necessary. Le
> It seemed like the simplest answer to this was to mark all outlines
> extracted from a CFF2 font as FT_OUTLINE_OVERLAP, because there's no
> inexpensive method of detecting it. And so I added code to do that and
> verified it was heeded in ftsmooth.c -- but the ftgrid output didn't
> look any dif
I'm not necessarily looking for a "fix", I just want to verify that the
CFF2 side is doing what it can and should be.
I did run into the thread Cosimo links to in my research, but of course
CFF doesn't have either of the glyf flags or any equivalent.
It's easy enough to add FT_OUTLINE_OVERLAP
> I'm afraid I don't have an exact overlap-less example handy because
> the equivalent static font also hints a bit differently, hiding the
> issue. But I'm referring to the fact that the upper serifs cover the
> upper parts of the stems but the pixels above the stems are darker, so
> the overlap
Hey Skef,
This thread might be of interest to you
https://github.com/fonttools/fonttools/issues/2059
On Tue, Dec 19, 2023 at 10:58 AM Skef Iterum wrote:
> I'm afraid I don't have an exact overlap-less example handy because the
> equivalent static font also hints a bit differently, hiding the is
I'm afraid I don't have an exact overlap-less example handy because the
equivalent static font also hints a bit differently, hiding the issue.
But I'm referring to the fact that the upper serifs cover the upper
parts of the stems but the pixels above the stems are darker, so the
overlapping are
> I've been looking into various FreeType issues related to the
> combination of CFF2 and hinting. As part of that I ran into the
> phenomenon represented in the attached capture of ftgrid. Which, to
> summarize, has a rendering artifact caused by overlap.
What exactly is the artifact? I don't
Hello -
I've been looking into various FreeType issues related to the
combination of CFF2 and hinting. As part of that I ran into the
phenomenon represented in the attached capture of ftgrid. Which, to
summarize, has a rendering artifact caused by overlap.
It seemed like the simplest answer
25 matches
Mail list logo
