[Freetype] Re: Freetype digest, Vol 1 #843 - 11 msgs

[Jon Harrop]

> From: "Turner David" <address@hidden>
> Well, a screenshot might be a good idea to demonstrate what you're
> speaking about.

Ok, I've put a screenshot of the same code rendering "Arial" (TrueType) 
correctly, here:

http://www.chem.pwf.cam.ac.uk/~jdh30/truetype.png

and rendering "Hershey plain duplex" (Type 1) incorrectly, here:

http://www.chem.pwf.cam.ac.uk/~jdh30/type1.png

It may just be coincidence but, to me, this result appears to have the 
control-points and end-points rotated in order along the contours. This is a 
problem which I noted with FT_Outline_Decompose. Is this function used to get 
at the contours in Type 1 fonts? Has it always been the only route to this 
information? It's just that I think it was working from within KDE a year or 
so ago when this function was still broken...

> A fact of life is that the current Postscript hinter
> (used for Type 1, CID and CFF fonts) is slightly buggy and less
> advanced than the current auto-hinter. In many cases, it will produce
> "inferior" text. There are even issues with certain fonts that contain
> "strange" hints, or normal ones (like edge snaps) that are currently
> ignored.

I am sure you are better equipped to test this than me (I currently only have 
binaries and a slow net connection) but try turning off all that and 
rendering some Type 1 fonts which contain cubic Beziers (IIRC, this is where 
the code failed). I think that when I got similar results from within Smoke I 
was using FT_Outline_Decompose directly and, so, presumably not using the PS 
hinter.

I'll have another look at the FT_Outline_Decompose but it isn't very easy to 
see what it's doing. ;)

> In other words, the Postscript hinter needs more work, and this could
> be an explanation. Do you have code to show that FT_Outline_Decompose
> doesn't work correctly though ?

I can try to dig some out but I've no idea where I left it. IIRC, I also have 
C++ code from the old C++ version of Smoke which does the same thing. It 
makes judicious use of the STL but, unlike the ocaml version, is 
completed. :)

> > I think I've got a reimplementation in ocaml which I can post if you
> > think that would help. It's vastly smaller and more elegant than the
> > current code in Freetype.
>
> ROTFL :-) I'd like to see that (hint: I know OCaml), though I doubt
> it would compile within the FreeType code base.

Here's my current ocaml code-in-progress. The "build" function converts the 
Freetype data structure into a Smoke data structure. The "make_explicit" 
function takes a list of font points and explicitly adds in the implicit 
control and end points. For a list (a,b,c,d,e) the first call is to (d,e,a) 
so it can use the context of the first point on the contour to determine 
whether or not it should add an explicit end point or control point before 
the contour even begins.

      let make_explicit l =
        let rec helper l =
          match l with
            (v3, v2, v1::t) ->
              begin
                let centre r1 r2 = scale 0.5 (add r1 r2) in
                match (v3, v2, v1) with
                  (_, _, (_, Freetype.On_point)) ->
                    v1::(helper (v2, v1, t))
                | (_, (r2, Freetype.Off_point_conic), (r1, _)) ->
                    print_string "Adding explicit end point.\n";
                    (centre r1 r2, Freetype.On_point)::v1::(helper (v2, v1, 
t))
                | ((_, Freetype.Off_point_cubic), (r2, 
Freetype.Off_point_cubic), (r1, _)) ->
                    print_string "Adding explicit end point.\n";
                    (centre r1 r2, Freetype.On_point)::v1::(helper (v2, v1, 
t))
                | _ ->
                    v1::(helper (v2, v1, t))
              end
          | (_, _, []) -> []
        in
        let call_helper l = match List.rev l with
          v2::v3::t -> helper (v3, v2, l)
        | _ -> [] in
        call_helper l
      in
      let rec build i = match i with
        0 -> []
      | _ -> (make_explicit (to_vertex_tag_list (i-1)))::(build (i-1)) in
...

Maybe it is worth "growing" what is currently an ocaml veneer to Freetype into 
the library itself. I think that many of the data structures and algorithms 
could be much more cleanly implemented in ocaml. I'm certainly finding that 
Smoke develops vastly quicker in ocaml than it did in C++.

> > PPS: All that effort on hinting has paid off, IMHO.
>
> The effort isn't finished, unfortunately, there are still
> room for improvement :-(

Well, you've got one happy user here. :)

BTW, now that I'm being kicked out of academia, I'm considering trying to sell 
licences to my code. Have you guys made any money that way?

Cheers,
Jon.