Re: ChangeLog Demon and 'Standard - Outline' (was Re: Dia ChangeLog reportfor 2007-11-06 13:01:39 UTC (Tue 06 Nov))
- From: Lars Clausen <lars raeder dk>
- To: discussions about usage and development of dia <dia-list gnome org>
- Subject: Re: ChangeLog Demon and 'Standard - Outline' (was Re: Dia ChangeLog reportfor 2007-11-06 13:01:39 UTC (Tue 06 Nov))
- Date: Sat, 10 Nov 2007 16:50:53 +0100
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]