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
> >
> 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.
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
> 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
> 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 approaches as a
search chooses and which
order qsort puts them in.
What should be done in these cases?
On Tue, Sep 26, 2023 at 11:17 PM Craig White wrote:
> > 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 h
> 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
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 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
individual
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
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:
> > Righ
characters to test on yet.
On Wed, Aug 2, 2023 at 6:29 PM Craig White wrote:
> 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 calculati
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.
I can tell by measuring the height of the tilde after each step of the
latin hinting
> 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
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
> 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
> 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
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
> After pressing the (uppercase) 'P' key, an image called `ftview.png`
> is stored in the current directory – at least on my GNU/Linux box.
I still can't find the ftview image, so instead I'm going to write the code
to generate the images myself.
I recently made code to do the opposite case of
Thanks for the feedback on the algorithm!
I'm trying to use ftview to get some more sample images, but I can't find
the image produced by the "print png" feature. Where is it saved?
In the benchmark file, is a higher number better or worse? In either case,
the performance hasn't changed much.
Hello,
I have recently created a prototype of a system that will fix rendering
issues for a few characters in autohinting mode. This prototype can be
found in the gsoc-craig-2023 branch. The system consists of 3 parts:
- The adjustments database, containing what should be done for each
Would you mind addressing the other approaches given, and why yours will
work the best?
To me, simply looking up the characters that need adjustments beforehand to
get their glyph indices makes the most sense.
On Wed, May 24, 2023 at 12:29 AM Werner LEMBERG wrote:
>
> > Will it be necessary to
23, 2023 at 12:55 PM Craig White wrote:
> The reason I wanted this reverse mapping is because I am trying to
> implement adjustments for specific glyphs to improve rendering in the
> auto-hinter, such as "i", where the dot merges with the stem at low ppem.
> I need
ng
whether or not the glyph being rendered is "i", or another similarly
affected glyph.
Mapping glyphs to character codes would make this easy.
On Tue, May 23, 2023 at 12:40 PM Hin-Tak Leung
wrote:
> On Tuesday, 23 May 2023, 17:19:46 BST, Craig White
> wrote:
>
> > I was looki
I was looking into how freetype maps character codes to glyph indices, and
learned that there are many different formats the character map can be in,
not to mention the one-to-many and many-to-one mappings that Werner
mentioned.
Will it be necessary to implement the reverse mapping separately for
Thanks, I got it working
On Sun, May 21, 2023 at 12:49 AM Werner LEMBERG wrote:
>
> > (3) Go to directory `subprojects/freetype2/include/freetype/config`
> > and modify file `ftoption.h`; you need to comment out options
> > `FT_DEBUG_LEVEL_ERROR` and `FT_DEBUG_LEVEL_TRACE`.
>
> Oops! I
context: https://summerofcode.withgoogle.com/proposals/details/6CaOVRhz
I want to share my idea for the database format and get feedback on it.
I am assuming that the list of character adjustments is small enough to
store in-memory without issues. This changes completely if a file was
needed
Thanks for the tip about using ftgrid for testing. The breaking point of i
and j is similar in my case. As for the settings, I just made sure to
press f to force auto-hinting mode.
On Fri, May 19, 2023 at 9:50 AM Werner LEMBERG wrote:
>
> > [...] it seems that characters ⟨ij⟩ in DejaVu Sans
I am trying to look at the trace output using the FT_Trace_Set_Level
function. I read that FT_DEBUG_LOGGING macro must be set for this to work,
so I tried doing this by passing:
-Dc_args='-D FT_DEBUG_LOGGING'
to meson setup.
After this, it complained about not finding dlg headers, so I stuffed
I have been told that under auto-hinting mode, sometimes the dot of the i
and j merge with the stem. I used the settings given in the freetype
tutorial to test the rendering of these characters, and unsurprisingly, the
letters looked just fine. To reproduce it, I'll probably need to pass in
Thanks for the help! re-cloning and hiding libpng in a directory inside of
/usr/local worked.
On Wed, May 10, 2023 at 2:57 AM Werner LEMBERG wrote:
> >> I use meson 0.59.4, you have version 0.61.2, maybe this makes a
> >> difference?
> >
> > I vaguely remember there were some issues with newer
I'm subscribed already and getting emails from the mailing list.
https://hastebin.com/share/gejakiluli.yaml
Here's the output of meson setup.
I did not set --prefix
I ran ldconfig with no arguments and it gave no output. I also confirmed
that `usr/local/lib/` is mentioned in `/etc/ld.so.conf`.
I am trying to compile the freetype demo programs using meson, and I get
this linker error:
https://hastebin.com/share/utuhanafik.bash
it appears to be complaining about cairo. I am running ubuntu 22 LTS and
have the latest "libcairo2-dev" installed. How can I fix this?
Thanks
Hi, I'm Craig White, a student at Florida Polytechnic University
After doing Google Summer of Code last year, I want to participate again
this year.
The project idea about making a capability database for the
auto-hinter caught my eye. I have a few questions about it though:
- What
38 matches
Mail list logo
