Re: Implementing SVG attribute "stroke-miterlimit" ( tdf#48066)

Hi Regina,

comments inline :-)

Am 08.04.2016 um 18:27 schrieb Regina Henschel:
> Hi Armin,
>
> since yesterday I have thought about it. I now think, that I will use 
> the GDI+ type 'LineJoinMiterClipped'. That makes rendering inside LO 
> consistent and that is more important as interoperability with foreign 
> applications. It is then still possible to implement the use of the 
> GDI+ type 'LineJoinMiter' in addition later on, and use it for pptx.

I checked and agree - when the limit is exceeded, fallback to bevel 
should happen. This is exactly what we do and what others do, e.g. cairo:

"If the current line join style is set to |CAIRO_LINE_JOIN_MITER| 
<http://www.cairographics.org/manual/cairo-cairo-t.html#CAIRO-LINE-JOIN-MITER:CAPS> 
(see |cairo_set_line_join()| 
<http://www.cairographics.org/manual/cairo-cairo-t.html#cairo-set-line-join>), 
the miter limit is used to determine whether the lines should be joined 
with a bevel instead of a miter. Cairo divides the length of the miter 
by the line width. If the result is greater than the miter limit, the 
style is converted to a bevel."

> It is not a problem of scaling, but the kind how the sharp corner is 
> clipped is fundamental different.

Yes, extending it somehow - instead of just doing a bevel it 'keeps' 
some lengths - stragne ;.)

> If you think I should do it different, please tell me.
>
> Next problem: When testing a curve I got bug
> https://bugs.documentfoundation.org/show_bug.cgi?id=99165 Rendering of 
> mitered curve changes with zoom level
> That is independent of SVG, but effects the rendering of SVG too. Do 
> you have a code pointer, where I should look for the reason?

I am surprised - and indeed, it is already in aoo. Sigh.
Entry is in VclPixelProcessor2D::tryDrawPolygonStrokePrimitive2DDirect, 
two hits, 1st is the fat line, 2nd the hairline. This goes down to the 
Gdiplus renderer WinSalGraphicsImpl::drawPolyLine which does

                const Gdiplus::REAL aMiterLimit(15.0);
                Gdiplus::DllExports::GdipSetPenMiterLimit(pTestPen, 
aMiterLimit);
                Gdiplus::DllExports::GdipSetPenLineJoin(pTestPen, 
Gdiplus::LineJoinMiter);

If this does not work (hopefully better with LineJoinMiterClipped) we 
have a problem with WIndows.
BTW: jumping in the debugger over tryDrawPolygonStrokePrimitive2DDirect 
in VclPixelProcessor2D::processBasePrimitive2D and using the 
decomposition works...

Regards,
Armin

> The state is now, that I have finished the transport of 
> fMiterMinimumAngle for Windows. The rendering is already good with 
> decomposition and with anti-aliasing on as well, here on Windows. I 
> have started to adapt the headers for the other OS. A MetaXYAction is 
> still missing.
>
> Kind regards
> Regina
>
> Armin Le Grand schrieb:
> > Hi Regina,
> >
> > yes, the MiterLimits are different in different systems, but all are
> > somehow specified using the angle between the two vectors involved. I
> > remember to have seen some definitions, most using the same and 15 as
> > default value. The ways to be compatible with MS are:
> > - find a definition somewhere, mqaybe in forums or newsgroups (I have
> > none, sorry)
> > - reverse engineer by trying out. Probability is high that there is a
> > (linear?) relationship between the values, so it might be a simple 
> > scaling
> > HTH!
> >
> > Regards,
> > Armin
> >
> > Am 07.04.2016 um 14:35 schrieb Regina Henschel:
> > > Hi all,
> > >
> > > I have made some progress. But a new problem comes up.
> > >
> > > I have changed WinSalGraphicsImpl::drawPolyLine [3] so that it gets an
> > > additional parameter fMiterMinimumAngle (same meaning as in
> > > createAreaGeometryForJoin) and uses it for gdi+. The rendering in
> > > edit-mode in Draw and Impress is correct then with gdi+ on Windows.
> > > Even Text in SVG works out of the box. [BTW: The current rendering
> > > using gdi+ is wrong, see my report bug#99102.]
> > >
> > > The behavior of gdi+ is described in [1]. To get the same kind of
> > > behavior as in LO, when the miter limit is exceeded, the LineJoin type
> > > 'LineJoinMiterClipped' has to be used.
> > >
> > > Being only in LibreOffice and SVG, that would be no problem. But MS
> > > seems to use different defaults. The rendering in PowerPoint looks
> > > like gdi+ type 'LineJoinMiter'. The specification for 'lim' in
> > > ECMA-376, Part 1, chapter 20.1.8.43, has no details, and I have not
> > > found details otherwhere.
> > >
> > > This gdi+ type 'LineJoinMiter' kind of clipping (see the image in the
> > > article [1]) will be used in SVG 2 [2] too under the identifier
> > > 'miter-clip'.
> > >
> > > So my question: Ignore interoperability with MS? If not, how to 
> > > solve it?
> > >
> > > Kind regards
> > > Regina
> > >
> > > [1]
> > > https://msdn.microsoft.com/en-us/library/windows/desktop/ms534148%28v=vs.85%29.aspx 
> > >
> > >
> > >
> > > [2] https://www.w3.org/TR/svg-strokes/#StrokeShape
> > >
> > > [3]
> > > diff --git a/vcl/win/gdi/gdiimpl.cxx b/vcl/win/gdi/gdiimpl.cxx
> > > index 7febbe8..36ecb31 100644
> > > --- a/vcl/win/gdi/gdiimpl.cxx
> > > +++ b/vcl/win/gdi/gdiimpl.cxx
> > > @@ -2031,7 +2031,8 @@ bool WinSalGraphicsImpl::drawPolyLine(
> > >      double fTransparency,
> > >      const basegfx::B2DVector& rLineWidths,
> > >      basegfx::B2DLineJoin eLineJoin,
> > > -    css::drawing::LineCap eLineCap)
> > > +    css::drawing::LineCap eLineCap,
> > > +    double fMiterMinimumAngle)
> > >  {
> > >      const sal_uInt32 nCount(rPolygon.count());
> > >
> > > @@ -2064,9 +2065,9 @@ bool WinSalGraphicsImpl::drawPolyLine(
> > >              }
> > >              case basegfx::B2DLineJoin::Miter :
> > >              {
> > > -                const Gdiplus::REAL aMiterLimit(15.0);
> > > +                const Gdiplus::REAL
> > > aMiterLimit(1/sin(fMiterMinimumAngle/2.0));
> > > Gdiplus::DllExports::GdipSetPenMiterLimit(pTestPen, aMiterLimit);
> > > - Gdiplus::DllExports::GdipSetPenLineJoin(pTestPen,
> > > Gdiplus::LineJoinMiter);
> > > + Gdiplus::DllExports::GdipSetPenLineJoin(pTestPen,
> > > Gdiplus::LineJoinMiterClipped);
> > >                  break;
> > >              }
> > >              case basegfx::B2DLineJoin::Round :
> > >
> > > _______________________________________________
> > > LibreOffice mailing list
> > > LibreOffice@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/libreoffice

--
--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)