Re: gEDA-user: PCB: simple FreeType fonts implementation

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Thu, 2009-03-12 at 12:32 +0300, Ineiev wrote:

>   Final remarks
> 
> Once I thought whether it would be better to use pango instead
> of freetype;

I was just thinking this as you were talking about scripts.

>  it would solve problems with combining character,

Don't even bother trying to re-invent all the I18N stuff pango
implements. It is _really_ complex, and I don't want to see PCB attempt
ot repeat it. We simply don't have the base of expertise to maintain it,
or get every corner case right.

> but it has the next disadvantages:
> first, it is a stronger dependence;

Personally, I don't care. It isn't so bad, and modern linux desktops
will have it. Anything using GTK anywhere will have it. (And we can make
it work with Lesstif too, so there is no problem there).

> second, it renders to bitmaps only, whereas having
> vectored outlines is important when the characters grow small.

Untrue. You have to supply a function for drawing glyphs, or drawing
trapezoids and rectangles IIRC. Pango does work with vector outlines,
you just need an appropriate back-end.

> As I mentioned, these patches can hardly be used in practice,
> because I had to change PCB file format, so mainstream PCB won't
> read the files saved by the patched program.

Still, an impressive start, and we can only move forwards with features
like this when people start experimenting with these things.

I expect we could start using Freetype2 / Pango without changing the
file-format, just you'd not be able to adjust any of the font / layout
settings from the defaults.

For backwards compat with fonts.. I know of people who've written custom
Freetype backends which allow them to feed legacy font data into
Freetype. (Alternatively we could convert the usual PCB font into a
format it understands).

If you want me to help with polygons, let me know.

Depending on how you're creating them, you could add new contours for
the holes directly in the linked list (might need to set a direction
flag, or ensure the contour is in the right order). You could create a
contour with the higher level routines for including points, then create
a contour and subtract it from the main outline. This should be more
robust. A lower level, direct to data-structure approach would probably
be faster (avoiding the boolean routines), but only works if the rules
of Freetype's polygon contours match any invariants we expect of them,
such as non-intersecting contours.

I agree the lined versions have a certain charm to them, and that we'd
need to be able to enforce DRC rules for min width on polygon versions.
I can't think how to do that immediately.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user