[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ChangeLog Demon and 'Standard - Outline' (was Re: Dia ChangeLog reportfor 2007-11-06 13:01:39 UTC (Tue 06 Nov))



On Fri, 2007-11-09 at 18:15 +0100, Hans Breuer wrote:
> On 10.11.2007 08:12, Lars Clausen wrote:
> > Hans Breuer said:
> [...]
> >> Unfortunately I dont know a way to make the filling respect holes within
> >> the glyphs. The path data delivered by cairo just consist out of different
> >> outlines, the first of a glyph usually the outer shape. When that is
> >> filled
> >> for a glyph like '#' the following hole filling does not matter anymore.
> >>
> >> It may be possible to substract overlapping outlines, but cairo does not
> >> give any hint on that either so some beziergon 'collision detection' would
> >> be required. But even with this information reconstructed the best Dia's
> >> beziergon currently can do is 'blanking'.
> > 
> > The EPS w/ Pango fonts does the right thing, so we can get the correct
> > data if we need to.  
> I don't hink that it's the code within Dia which makes the difference but
> the underlying glyph vectorization (or better the lack of content provided
> by cairo). But maybe there is more help available from the cairo people [1].

And you can't use the code from the diapsft2renderer because that requires FreeType, yes?

> > While the beziergon does allow holes, it only has one
> > curve, so I guess we're out of luck.  
> I started to experiment with the pathes. Just connecting the endpoints for
> the different pathes *when filling* may help. Unfortuanetly the code in
> cairo does not provide one path with move_to in between per glyph but
> completely separated pathes.

Hmmm... might work, if the precision is good enough.  Adding a way to
make holes in beziergons is tougher.

> > While having rotated text is nice,
> On purpose I did not call it Text, but Outline ;) At least if one is not
> filling the outlines it mostly works (there are glitches with the outline
> precision on windows). But it was never meant to replace proper (rotated)
> text rendering.

That's true.  Sheesh, now I'll have to look at what it'd take to allow
normal text to rotate:)

-Lars



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]