The final branch has everything it needs to now!
I would really like you or someone else who has worked a lot with freetype
to give it a code review.
Thank you.
On Mon, Oct 30, 2023 at 2:26 AM Werner LEMBERG wrote:
>
> > There was an intentional change to src/base/ftobjs.c. I made the
> >
> There was an intentional change to src/base/ftobjs.c. I made the
> function that finds the best unicode charmap public so that I could
> use it from the autofitter.
OK, I see. I was confused because the `FT_BASE_TAG` is missing for
this function in `ftobjs.c`.
Werner
> And no accidental changes to `freetype/config/ftoption.h` and
> `src/base/ftobjs,c`, please :-)
There was an intentional change to src/base/ftobjs.c. I made the function
that finds the best unicode charmap public so that I could use it from the
autofitter.
On Fri, Oct 27, 2023 at 4:26 AM
> I have added and tested type 3 lookup handling, and also added the
> comments you asked for.
Thanks. Minor nits that I've seen while skimming through:
s/indicies/indices/
s/flatenning/flattening/
> I will begin on the final branch if there's nothing else to be done.
OK. Please rebase
I have added and tested type 3 lookup handling, and also added the comments
you asked for.
I will begin on the final branch if there's nothing else to be done.
Thanks for the help!
On Mon, Oct 23, 2023 at 12:54 PM Werner LEMBERG wrote:
>
> > I need some help figuring out how to handle the type
> I need some help figuring out how to handle the type 3 lookups.
> I need to do 2 things:
> - Figure out which features contain type 3 lookups
> - Determine the number of variations the feature contains
Simply add all glyphs a type 3 lookup provides to the list of glyphs.
No further special
> OK. Minor nit: Please avoid overlong git commit messages (i.e., not
> longer than 78 characters). And there should be an empty line after
> the first line to help tools like `gitk` to properly display git
> commits. [Overlong lines should be avoided in the C code, too, both
> for comments and
>> I simply noticed that it's possible for 2 characters to map to the
>> same glyph, which means that a glyph would map to 2 characters. I
>> don't have any examples in mind for when this would actually
>> happen. I was planning on either ignoring the situation to let it
>> be resolved
> Perhaps the following?
> (1) If glyph A is in the 'cmap' table, and glyph B is not, prefer
> glyph A.
> (2) If one glyph needs X lookups and another glyph needs Y, and X < Y,
> prefer glyph X.
> I'm not sure whether (2) makes sense, though.
> Can you give one or more examples for such
> > OK. I think it is a bad side effect of the current auto-hinting
> > algorithm that there are different approaches.
>
> I just want to clarify: you understood that the reason I used
> different approaches for each letter was to compare the approaches?
> My intent is to use one of those
> OK. I think it is a bad side effect of the current auto-hinting
algorithm that there are different approaches.
I just want to clarify: you understood that the reason I used different
approaches for each letter was to compare the approaches? My intent is to
use one of those approaches as a
> > Thanks. Do you have meanwhile found an explanation why o-tilde
> > looks so bad for Times New Roman at 16ppem?
>
> All 4 letters in each row have a different approach:
>
> õ: vertical stretch, no segment removal
> ñ: no vertical stretch, segment removal
> ã: vertical stretch and segment
I have a question:
It's possible that 2 characters in the adjustment database could map to the
same glyph, which will create 2 entries in the reverse character map with
the same glyph as a key. In this case, the character that glyph maps to is
decided arbitrarily based on which one the binary
> Thanks. Do you have meanwhile found an explanation why o-tilde looks
so bad for Times New Roman at 16ppem?
All 4 letters in each row have a different approach:
õ: vertical stretch, no segment removal
ñ: no vertical stretch, segment removal
ã: vertical stretch and segment removal
all other
> Is testing all these combinations really necessary?
I don't know :-) I just wanted to point out that feature combinations
have to be considered.
> [...] My intuition says very few of these combinations actually
> matter.
Yes, I agree.
> I wrote some pseudocode for a different approach that
> So, if my understanding is correct, hb_ot_shape_glyphs_closure will
> take an input character or characters and tell me all the glyphs
> that it gets transformed into, as well as the final form.
Yes.
> I'm not sure about this interpretation, because the documentation
> uses the term
So, if my understanding is correct, hb_ot_shape_glyphs_closure will take an
input character or characters and tell me all the glyphs that it gets
transformed into, as well as the final form. I'm not sure about this
interpretation, because the documentation uses the term "Transitive
closure",
> I discovered there was an issue when I tried using a test font I created
> with the following as one of its lookups (in ttx format):
>
>
>
>
>
>
>
>
>
>
> There is one lookup here, but 2 substitutions. My program needs
I discovered there was an issue when I tried using a test font I created
with the following as one of its lookups (in ttx format):
There is one lookup here, but 2 substitutions. My program needs to iterate
through each
> As I was testing my attempt at supporting GSUB lookups, I found that
> hb_ot_layout_lookup_collect_glyphs, is actually not what I need,
> because I assumed that each lookup contains exactly one
> substitution, when it actually may contain multiple. What I really
> need is a way to get each
As I was testing my attempt at supporting GSUB lookups, I found that
hb_ot_layout_lookup_collect_glyphs, is actually not what I need, because I
assumed that each lookup contains exactly one substitution, when it
actually may contain multiple. What I really need is a way to get each
individual
On Saturday, 12 August 2023 at 17:17:47 BST, Werner LEMBERG
wrote:
> > It is one of those things I never remember - winding rule of
> > truetype and postscript are different, one is even-odd, the other is
> > non-zero. [...]
> You are on the completely wrong track here. What I'm
> It is one of those things I never remember - winding rule of
> truetype and postscript are different, one is even-odd, the other is
> non-zero. [...]
You are on the completely wrong track here. What I'm talking about is
strictly local and not (directly) related to having two different
It is one of those things I never remember - winding rule of truetype and
postscript are different, one is even-odd, the other is non-zero. That concerns
the number of times a line joining an "interior" (inked) point going to
infinity, how many times it crosses the glyph contour.
Anyway,
> I'm still missing something. Why would the direction of the contour
> matter if, in either case, it's the same set of points?
It doesn't directly matter for your code. However, FreeType's
auto-hinter handles these cases differently (namely, to detect stems),
which might in turn influence
I'm still missing something. Why would the direction of the contour matter
if, in either case, it's the same set of points?
On Fri, Aug 11, 2023 at 6:52 AM Werner LEMBERG wrote:
>
> > You said that for an i - like shape:
> >> Both contours have the same direction.
> >
> > What kind of problems
> You said that for an i - like shape:
>> Both contours have the same direction.
>
> What kind of problems does this rule protect against?
Sorry, this was sloppily formulated. It's about the *local* direction
of contours, that is, whether a horizontal contour segment goes from
left to right
I have a question about your suggestion earlier for a validation rule for
an i - like shape
You said that for an i - like shape:
> Both contours have the same direction.
What kind of problems does this rule protect against?
On Tue, Aug 8, 2023 at 1:45 PM Craig White wrote:
> > Right now I'm
> If you're testing this yourself, keep in mind that the adjustment
> will only be applied to n with tilde. Any other letter with a tilde
> can be used as a control group.
Right now I'm abroad (actually, in New York :-) – it will take some
time until I can do such tests, sorry.
Werner
> [...] I have confirmed by commenting/uncommenting steps of the
> hinting process that af_glyph_hints_align_edge_points is the
> function that snaps the tilde back to flat, so if my understanding
> is correct, the points at the top and bottom of the tilde are
> forming edges and are being
It's pushed. If you're testing this yourself, keep in mind that the
adjustment will only be applied to n with tilde. Any other letter with a
tilde can be used as a control group.
The commit also has the vertical adjustment mode that pushes the bottom
contour down, which I haven't found
Thanks for your help. I fixed the issue by marking all on-curve points
that I moved as touched (and letting IUP do the rest), setting oy = y, and
applying the stretch to fy as well. I also had some calculation errors in
the height measurement the debug prints used and the algorithm itself.
The
> I have an algorithm I'm testing for the tilde unflattening. I went
> with doing it before all steps, because it worked better with my
> idea, but the function af_glyph_hints_align_weak_points is undoing
> my changes.
Hmm. Have you checked the OpenType specification how the IUP
instruction
I have an algorithm I'm testing for the tilde unflattening. I went with
doing it before all steps, because it worked better with my idea, but the
function af_glyph_hints_align_weak_points is undoing my changes.
I can tell by measuring the height of the tilde after each step of the
latin hinting
> > Just take the extrema of *all* points – for fonts this should be
> > good enough, because it is standard to have points at the curve
> > extrema, thus making the bounding box of the curve identical to
> > the bounding box of the points (both on and off points).
>
> Ok, thanks. This is
> What exactly do you mean with 'find'? The algorithm? Just take the
extrema of *all* points – for fonts this should be good enough,
because it is standard to have points at the curve extrema, thus
making the bounding box of the curve identical to the bounding box of
the points (both on and off
Hello Craig,
again sorry for the late reply.
> During this time, I realized that knowing the bounding box of the
> tilde contour would help a lot. In fact, the logic for the other
> vertical separation adjustments assumes that it can get the bounding
> box by taking the minimum/maximum
Hey, I've been working on the tilde correction over the last few days.
During this time, I realized that knowing the bounding box of the tilde
contour would help a lot. In fact, the logic for the other vertical
separation adjustments assumes that it can get the bounding box by taking
the
>> Many-to-one: accent marks, e.g. umlauts
>> One-glyph-to-many-unicode-characters: ligatures, e.g. "ff", "fi".
>
> I don’t see how these two cases are different. An accented glyph like
> ⟨ɑ̃⟩ is made up of two Unicode characters, ɑ+◌̃ (U+0251 U+0303);
> similarly a ligated glyph like ⟨fi⟩ is
Many-to-one: accent marks, e.g. umlauts
One-glyph-to-many-unicode-characters: ligatures, e.g. "ff", "fi".
I don’t see how these two cases are different. An accented glyph like
⟨ɑ̃⟩ is made up of two Unicode characters, ɑ+◌̃ (U+0251 U+0303);
similarly a ligated glyph like ⟨fi⟩ is made up of
>> A mapping from input Unicode characters to glyph indices based on
>> the GSUB + cmap tables and not on cmap alone.
>
> Right now, the only cases where the GSUB table is helpful that I am
> aware of, for the purposes of this project, are for handling glyph
> alternates and combining characters.
On Friday, 21 July 2023 at 07:28:07 BST, Craig White
wrote:
> ...Those would be one-to-one mappings and many-to-one mappings, respectively.
> Would this general solution involve other kinds of GSUB mappings? ...
> Even sticking to just many-to-one and one-to-one mappings, ...
Having too
> Well, there are no 'unclear goals': the general solution is *exactly*
> what I was talking about all the time, and what you need for any entry
> in the adjustment database: A mapping from input Unicode characters to
> glyph indices based on the GSUB + cmap tables and not on cmap alone.
Right
> Right now, I don't understand the needs well enough to know what to
> generalize or to test whether the general solution works well
> enough. I'd rather start with specific use cases rather than a
> general solution with unclear goals.
Well, there are no 'unclear goals': the general solution
> Probably yes, but who knows. It would be nice to have a generic
> solution that completely covers the whole situation, and we never have
> to think about it again.
Right now, I don't understand the needs well enough to know what to
generalize or to test whether the general solution works well
> Since hinting glyphs that are descendants of combining characters
> will help few fonts, what other ways does the database need to use
> the GSUB table? The only other use case I'm aware of are one to one
> substitutions providing alternate forms of a glyph.
Probably yes, but who knows. It
Thanks! This even answers some questions I was thinking about, but hadn't
asked.
I was wondering why I couldn't find any GSUB entries for combining
characters. In one font I dumped with ttx, there were entries doing the
opposite: mapping 'aacute' -> 'a' + 'acute'.
Since hinting glyphs that are
> The next thing I'm doing for the adjustment database is making
> combining characters work. Currently, only precomposed characters
> will be adjusted. If my understanding is correct, this would mean
> finding any lookups that map a character + combining character onto
> a glyph, then apply
The next thing I'm doing for the adjustment database is making combining
characters work. Currently, only precomposed characters will be adjusted.
If my understanding is correct, this would mean finding any lookups that
map a character + combining character onto a glyph, then apply the
49 matches
Mail list logo
