Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


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)


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.