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

[Turner David]

Hello Jon,

> 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...
> 
Ah ah, I have an explanation, and it's definitely not what you're
thinking about:

  - The "Hershey" font collection is very special because it doesn't use
    traditional Type 1 charstrings to encode. Instead, they only use *open*
    paths that must be stroked to be displayed correctly. Think about
    "plotter fonts".

  - what you're seeing is the result of interpreting a group of opened
    paths as a list of closed ones, and really doesn't look like the
    original vectors.

  - FT_Outline_Decompose doesn't deal with open paths. However, the
    FreeType stroker does, and is capable of converting these vectors
    into suitable outlines for monochrome and anti-aliased rendering
    (with arbitrary stroke widths)

  - There is no support for automatic stroking of these fonts for now
    because the stroker wasn't completed until recently. Moreover, it's
    a rather large source (about 13kb of compiled code), and I'd prefer
    to have it as an optional module (this isn't the case for now, it's
    an optional base-layer object), so that people wanting to support
    "traditional" Type 1 fonts don't need to add it to their build if
    they don't need its features.

In other words, it's possible to add automatic support for the Hershey
fonts in FreeType 2 with a little work, but I didn't consider doing it
for now. This involves moving the code currently in "ftstroker.c" into
its own module, implement a small service for it, and some code to call
it from either the Type 1 font driver or "src/base/ftstroker.c"

The previous "good-looking" rendering you experiences in the past was
probably due to using your X Server's font engine, which probably included
a copy of T1Lib, but only generated monochrome fonts. FreeType has never
rendered the Hershey fonts correctly.

And apparently, this has nothing to do with the Postscript hinter.

> 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++.
> 
The problem isn't implementation language, it's interfacing with the
rest of the programming world as a library. I don't think that many
applications would use a font engine that requires a garbage collector.
Moreover, there is the problem of embedding an Ocaml interpreter within
the library. And finally, there is the performance issue :-)

I'm pretty certain that development could also be vastly faster with
Python too; note that the first version of FreeType was written in
Pascal !

> 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?
> 
I did some money as a freelance software consultant. I was paid to develop
code. I haven't made any money selling only "licenses" of pre-existing code
for now though.

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)

> Cheers,
> Jon.
> 
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/freetype
> 

--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
NDS TECHNOLOGIES FRANCE will not therefore be liable for the message if 
modified.