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

[Ineiev <ineiev@xxxxxxxxx>]

On 3/12/09, Peter Clifton <pcjc2@xxxxxxxxx> wrote:
> On Thu, 2009-03-12 at 12:32 +0300, Ineiev wrote:
> 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.

Agreed; I'd say more: PCB should not maintain any non-ASCII characters
until a distinct user base needing this feature appears; it would be
useless, on the one hand,  and harmful, on the other.

>> 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).

I see; personally, I do care: the `most maintainable' (or maintained?)
HID has no dependency on pango (I'm not fond of that HID, but it is a
way to use PCB in a poorer environment); I think there is nothing
wrong neither with your don't caring, nor with my caring.

>> 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.

I didn't know; probably I'll try to do it next time.

> we can only move forwards with features
> like this when people start experimenting with these things.

Very true.

> 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.

I'm not sure I've got the thought correctly.. do you mean using single
font per layout and setting it externally e.g. with an rc file?

> 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).

I believe this would slow it down, almost certainly. FreeType fonts
are more complicated, they include (more or less) time-consuming
features like Unicode indexing.

Current PCB fonts are fast, and I really don't want them to loose this
property (this is why I forked out another type for FreeType fonts
rather than modified the existing).

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

Thank you; I shall if I have any questions.

> 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.

Yes; probably, this should be done before draw time, when loading the font.

> 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.

This depends on the font (if I didn't forget, I posted a figure with a
self-intersecting outline).

> 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.

Never mind; I think this will not be too hard when it is really needed.

Thank you for review,
    Ineiev


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