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

[Hans Breuer <hans breuer org>]

On 10.11.2007 16:50, Lars Clausen wrote:
> 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'.
That's implemented now.

> > > The EPS w/ Pango fonts does the right thing, so we can get the correct
> > > data if we need to.
Not a matter of the data - we should get the same data when using FreeType
through cairo (and on windoze it is directly from the font backend).
It is a matter of drawing capabilities.

> > I don't think 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?
Yes. Another reason is it only working with the PS drawing model - but we
need Dia's limited drawing model here.
But as recent changes show it is not required to take anything from
diapsft2*.c :-)

> > > 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.
I think makinng the first hole should not be that hard - at least not if it
is specialized for filled beziergons. Making the second hole may collide
with the connection of the first though.

> > > 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:)
The main problem I see is to get it in all the renderers. A lot of effort
for a small feature at least I did not miss that much. And now with the
above even less.

And if we are planning to break some renderers anyway we may want to go the
full nine yards and add rotation on the object level. At least with cairo
rendering (ps, pdf, gdk pixmap, print, bitmap, svg) the drawing part should
not be very difficult, see:
http://cairographics.org/manual/cairo-Transformations.html

And while at it we can add a lot of fill variations as well (:
http://cairographics.org/manual/cairo-Patterns.html

        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert