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

classic Classic list List threaded Threaded
20 messages Options
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

Hi all,

the following is, what I have found so far, but it might have errors. So
please correct me.

If two lines build a corner, the corner-style can be None, Rounded,
Beveled or Mitered. That is the property "draw:stroke-linejoin" in ODF
and "stroke-linejoin" in SVG. But SVG has the additional property
"stroke-miterlimit". Using it, the author can determine how sharp the
corner can be before it is turned into kind Beveled. I see no such
property in ODF. LibreOffice turns automatically to kind Bevel using the
default value of svg:stroke-miterlimit.

The API has the struct "StrokeAttributes" in css::rendering. It has the
element "MiterLimit". I do not know any UI for it and don't know, if and
how it is usable at all. The service "LineProperties" in css::drawing
does not provide such property.

In OOXML it is the attribute "lim" in element a:miter (20.1.8.43).


This svg-attribute is read on SVG import. And it could be evaluated by
the method basegfx::tools::createAreaGeometry(), if it got a value into
the already prepared parameter. But between these two ends there is
currently no way to transport the information. The line properties
Width, Color, LineCap and LineJoin are transported via class
"LineAttribute".

So my question is, how to transport the "Miterlimit"-information?
Add a member to class LineAttribute?
Add a member to PolygonStrokePrimitive2D and an additional new parameter
into the chain of calls and constructions?
Only fix svg-import or care for other things too? What would I have to
consider?

Kind regards
Regina




_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

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

Hi Regina,

AFAIK it is partially used, but not completely. I know of some cases in
renderers where today a fixed default of 15.0 is used. Various
GraphicSystems use various definitions for it, take care. It would be
necessary to define a definition for it for LO, import where available
and use where available. Some sub-systems can use it, e.g. Gdiplus or
cairo, export to SVG, but no tMetafile (at least not ours). There is
definitely no UI for it.

HTH!
Regards,
Armin

Am 24.03.2016 um 01:39 schrieb Regina Henschel:

> Hi all,
>
> the following is, what I have found so far, but it might have errors.
> So please correct me.
>
> If two lines build a corner, the corner-style can be None, Rounded,
> Beveled or Mitered. That is the property "draw:stroke-linejoin" in ODF
> and "stroke-linejoin" in SVG. But SVG has the additional property
> "stroke-miterlimit". Using it, the author can determine how sharp the
> corner can be before it is turned into kind Beveled. I see no such
> property in ODF. LibreOffice turns automatically to kind Bevel using
> the default value of svg:stroke-miterlimit.
>
> The API has the struct "StrokeAttributes" in css::rendering. It has
> the element "MiterLimit". I do not know any UI for it and don't know,
> if and how it is usable at all. The service "LineProperties" in
> css::drawing does not provide such property.
>
> In OOXML it is the attribute "lim" in element a:miter (20.1.8.43).
>
>
> This svg-attribute is read on SVG import. And it could be evaluated by
> the method basegfx::tools::createAreaGeometry(), if it got a value
> into the already prepared parameter. But between these two ends there
> is currently no way to transport the information. The line properties
> Width, Color, LineCap and LineJoin are transported via class
> "LineAttribute".
>
> So my question is, how to transport the "Miterlimit"-information?
> Add a member to class LineAttribute?
> Add a member to PolygonStrokePrimitive2D and an additional new
> parameter into the chain of calls and constructions?
> Only fix svg-import or care for other things too? What would I have to
> consider?
>
> Kind regards
> Regina
>
>
>
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

Hi Armin,

I need an advice/opinion _where_ to hold the information:

I cannot calculate whether to exchange 'miter' with 'bevel' directly in
svgreader, because there only properties for the whole path are handled,
but such exchange only happens for a single line pair of the path. So I
think, the exchange needs to be in createAreaGeometry part //check and
create linejoin. Is that right?

createAreaGeometry gets all needed information already in distinct
parameters. The division in single parameters is done inside
PolygonStrokePrimitive2D::create2DDecomposition part // create fat line
data. There I need access to 'miterlimit'. How should I hold this
information? Should I extend LineAttribute, or somethink else?

Kind regards
Regina

Armin Le Grand schrieb:

> Hi Regina,
>
> AFAIK it is partially used, but not completely. I know of some cases in
> renderers where today a fixed default of 15.0 is used. Various
> GraphicSystems use various definitions for it, take care. It would be
> necessary to define a definition for it for LO, import where available
> and use where available. Some sub-systems can use it, e.g. Gdiplus or
> cairo, export to SVG, but no tMetafile (at least not ours). There is
> definitely no UI for it.
>
> HTH!
> Regards,
> Armin
>
> Am 24.03.2016 um 01:39 schrieb Regina Henschel:
>> Hi all,
>>
>> the following is, what I have found so far, but it might have errors.
>> So please correct me.
>>
>> If two lines build a corner, the corner-style can be None, Rounded,
>> Beveled or Mitered. That is the property "draw:stroke-linejoin" in ODF
>> and "stroke-linejoin" in SVG. But SVG has the additional property
>> "stroke-miterlimit". Using it, the author can determine how sharp the
>> corner can be before it is turned into kind Beveled. I see no such
>> property in ODF. LibreOffice turns automatically to kind Bevel using
>> the default value of svg:stroke-miterlimit.
>>
>> The API has the struct "StrokeAttributes" in css::rendering. It has
>> the element "MiterLimit". I do not know any UI for it and don't know,
>> if and how it is usable at all. The service "LineProperties" in
>> css::drawing does not provide such property.
>>
>> In OOXML it is the attribute "lim" in element a:miter (20.1.8.43).
>>
>>
>> This svg-attribute is read on SVG import. And it could be evaluated by
>> the method basegfx::tools::createAreaGeometry(), if it got a value
>> into the already prepared parameter. But between these two ends there
>> is currently no way to transport the information. The line properties
>> Width, Color, LineCap and LineJoin are transported via class
>> "LineAttribute".
>>
>> So my question is, how to transport the "Miterlimit"-information?
>> Add a member to class LineAttribute?
>> Add a member to PolygonStrokePrimitive2D and an additional new
>> parameter into the chain of calls and constructions?
>> Only fix svg-import or care for other things too? What would I have to
>> consider?
>>
>> Kind regards
>> Regina
>>
>>
>>
>>
>> _______________________________________________
>> LibreOffice mailing list
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Regina Henschel
Regina Henschel wrote:
> The API has the struct "StrokeAttributes" in css::rendering. It has the
> element "MiterLimit". I do not know any UI for it and don't know, if and how
> it is usable at all. The service "LineProperties" in css::drawing does not
> provide such property.
>
Yeah, the css::rendering API in general is more modern than the stuff
in css::drawing. But for svg import, UNO API is for the while not
relevant, no?

> So my question is, how to transport the "Miterlimit"-information?
> Add a member to class LineAttribute?
>
Sounds like the way to go (if you mean the drawinglayer attribute).

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Regina Henschel
Hi Regina,

Am 24.03.2016 um 16:35 schrieb Regina Henschel:
> Hi Armin,
>
> I need an advice/opinion _where_ to hold the information:

Definitely in drawinglayer::attribute::LineAttribute, same place where
basegfx::B2DLineJoin is held. A double, defaulted to 15.0 and read
access will be fine. For setting it, add a 5th parameter to the
constructor, defaulted to 15.0. The LineAttribute is a read-only, not
later changeable class to keep things simple. It is better/safer to
create another one when a value needs to be changed than starting to
keep track of changes and add notification or other stuff.

HTH!

Regards,
Armin

>
> I cannot calculate whether to exchange 'miter' with 'bevel' directly
> in svgreader, because there only properties for the whole path are
> handled, but such exchange only happens for a single line pair of the
> path. So I think, the exchange needs to be in createAreaGeometry part
> //check and create linejoin. Is that right?
>
> createAreaGeometry gets all needed information already in distinct
> parameters. The division in single parameters is done inside
> PolygonStrokePrimitive2D::create2DDecomposition part // create fat
> line data. There I need access to 'miterlimit'. How should I hold this
> information? Should I extend LineAttribute, or somethink else?
>
> Kind regards
> Regina
>
> Armin Le Grand schrieb:
>> Hi Regina,
>>
>> AFAIK it is partially used, but not completely. I know of some cases in
>> renderers where today a fixed default of 15.0 is used. Various
>> GraphicSystems use various definitions for it, take care. It would be
>> necessary to define a definition for it for LO, import where available
>> and use where available. Some sub-systems can use it, e.g. Gdiplus or
>> cairo, export to SVG, but no tMetafile (at least not ours). There is
>> definitely no UI for it.
>>
>> HTH!
>> Regards,
>> Armin
>>
>> Am 24.03.2016 um 01:39 schrieb Regina Henschel:
>>> Hi all,
>>>
>>> the following is, what I have found so far, but it might have errors.
>>> So please correct me.
>>>
>>> If two lines build a corner, the corner-style can be None, Rounded,
>>> Beveled or Mitered. That is the property "draw:stroke-linejoin" in ODF
>>> and "stroke-linejoin" in SVG. But SVG has the additional property
>>> "stroke-miterlimit". Using it, the author can determine how sharp the
>>> corner can be before it is turned into kind Beveled. I see no such
>>> property in ODF. LibreOffice turns automatically to kind Bevel using
>>> the default value of svg:stroke-miterlimit.
>>>
>>> The API has the struct "StrokeAttributes" in css::rendering. It has
>>> the element "MiterLimit". I do not know any UI for it and don't know,
>>> if and how it is usable at all. The service "LineProperties" in
>>> css::drawing does not provide such property.
>>>
>>> In OOXML it is the attribute "lim" in element a:miter (20.1.8.43).
>>>
>>>
>>> This svg-attribute is read on SVG import. And it could be evaluated by
>>> the method basegfx::tools::createAreaGeometry(), if it got a value
>>> into the already prepared parameter. But between these two ends there
>>> is currently no way to transport the information. The line properties
>>> Width, Color, LineCap and LineJoin are transported via class
>>> "LineAttribute".
>>>
>>> So my question is, how to transport the "Miterlimit"-information?
>>> Add a member to class LineAttribute?
>>> Add a member to PolygonStrokePrimitive2D and an additional new
>>> parameter into the chain of calls and constructions?
>>> Only fix svg-import or care for other things too? What would I have to
>>> consider?
>>>
>>> Kind regards
>>> Regina
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LibreOffice mailing list
>>> [hidden email]
>>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>>
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

Hi Armin, hi Thorsten,

thank you. It is clear now, where to start (when I have enough spare time).

Kind regards
Regina

Armin Le Grand schrieb:

> Hi Regina,
>
> Am 24.03.2016 um 16:35 schrieb Regina Henschel:
>> Hi Armin,
>>
>> I need an advice/opinion _where_ to hold the information:
>
> Definitely in drawinglayer::attribute::LineAttribute, same place where
> basegfx::B2DLineJoin is held. A double, defaulted to 15.0 and read
> access will be fine. For setting it, add a 5th parameter to the
> constructor, defaulted to 15.0. The LineAttribute is a read-only, not
> later changeable class to keep things simple. It is better/safer to
> create another one when a value needs to be changed than starting to
> keep track of changes and add notification or other stuff.
>
> HTH!
>
> Regards,
> Armin

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Regina Henschel
Hi all,

I have started now and come immediately to the next design decision:

The svg attribute stroke-miterlimit is of type <number> in SVG, which is
in context of SVG attributes essentially a 'double'. The meaning of this
attribute is a ratio. Therefore in SVG is has no unit.
[https://www.w3.org/TR/SVG/painting.html#StrokeMiterlimitProperty]
[https://www.w3.org/TR/SVG/types.html#DataTypeNumber]

But LO imports it into the member 'SvgNumber maStrokeMiterLimit' of an
object of class SvgStyleAttributes. And class SvgNumber has a member
'SvgUnit meUnit'. In the ctor of SvgNumber the member meUnit defaults to
'Unit_px', if not given. But any unit is wrong for stroke-miterlimit.

Possible solutions
(1) Change the type of maStrokeMiterLimit' to 'double' and change its
name to 'mfStrokeMiterLimit'. That would loose the ability to track,
whether the value was found in the file or set by LO. In case not set in
the SVG file, it would be set to 4.0, as specified as initial value in
SVG spec.
(2) Extend the enum SvgUnit by an item 'Unit_none'. This likely requires
changes in places where SvgUnit is used. The member mfNumber of class
SvgNumber is already a 'double' and would fit.

My favorite is (2). What do you think?

Kind regards
Regina
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|

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

Regina Henschel wrote:
> (1) Change the type of maStrokeMiterLimit' to 'double' and change its name
> to 'mfStrokeMiterLimit'. That would loose the ability to track, whether the
> value was found in the file or set by LO. In case not set in the SVG file,
> it would be set to 4.0, as specified as initial value in SVG spec.
>
Why would knowing if it's the default or read from svg matter?

> (2) Extend the enum SvgUnit by an item 'Unit_none'. This likely requires
> changes in places where SvgUnit is used. The member mfNumber of class
> SvgNumber is already a 'double' and would fit.
>
> My favorite is (2). What do you think?
>
I think you know the code better than I do, so whatever you prefer. :)

Except if the question above has the 'does not matter' answer, then of
course (1) seems cleaner ...

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

Hi Thorsten,

Thorsten Behrens schrieb:
> Regina Henschel wrote:
>> (1) Change the type of maStrokeMiterLimit' to 'double' and change its name
>> to 'mfStrokeMiterLimit'. That would loose the ability to track, whether the
>> value was found in the file or set by LO. In case not set in the SVG file,
>> it would be set to 4.0, as specified as initial value in SVG spec.
>>
> Why would knowing if it's the default or read from svg matter?

That's why talking about it is good. Your question point me to the
solution. Searching around I have found, that the flag is indeed needed.
When first reading the attribute, this flag is used while resolving
inheritance. So I cannot drop it and will go with (2).

>
>> (2) Extend the enum SvgUnit by an item 'Unit_none'. This likely requires
>> changes in places where SvgUnit is used. The member mfNumber of class
>> SvgNumber is already a 'double' and would fit.
>>
>> My favorite is (2). What do you think?
>>
> I think you know the code better than I do, so whatever you prefer. :)

You flatter me, but it is not true.

Kind regards
Regina

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Armin Le Grand-2
Hi,

Armin Le Grand schrieb:

> Hi Regina,
>
> Am 24.03.2016 um 16:35 schrieb Regina Henschel:
>> Hi Armin,
>>
>> I need an advice/opinion _where_ to hold the information:
>
> Definitely in drawinglayer::attribute::LineAttribute, same place where
> basegfx::B2DLineJoin is held. A double, defaulted to 15.0 and read
> access will be fine. For setting it, add a 5th parameter to the
> constructor, defaulted to 15.0. The LineAttribute is a read-only, not
> later changeable class to keep things simple. It is better/safer to
> create another one when a value needs to be changed than starting to
> keep track of changes and add notification or other stuff.

I'm now at the stage, where createAreaGeometryForJoin() in
b2dlinegeometry is called with the correct angle in its parameter
fMiterMinimumAngle. But in the inserted svg image, the join is still not
changed to Bevel. What places do I need to change in addition? Is there
something to do in module canvas or vcl or something additional in svgio
or ...?

Kind regards
Regina

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

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

Hi Regina,

the MiterMinimumAngle influences only the miter mode, thus I do not
understand the 'still not changed to Bevel' comment. In SVG import, the
primitives and thus the LineAttribute as part of it containing the
MiterMinimumAngle is directly created, the exactly same instance will be
used in the renderer and be available in the decomposition.
I am not sure at which system you are, but the value needs to be used
either in

     VclPixelProcessor2D::tryDrawPolygonStrokePrimitive2DDirect

and then handed through

     OutputDevice::DrawPolyLineDirect

like the other values, down to the renderer sal implementation (Gdiplus
for windows).
Or - when getting decomposed in

     PolygonStrokePrimitive2D::create2DDecomposition

and then handed over to

     basegfx::tools::createAreaGeometry

also like the other values. Thus, still some hand-through
implementations needed to pass the value to the places where needed. At
that places, currently a default is used.

basegfx::tools::createAreaGeometry has an input value for
fMiterMinimumAngle already.

With OutputDevice::DrawPolyLineDirect it needs to be handed over to
diverse implementations of DrawPolyLine, there seems to be one for

OpenGLSalGraphicsImpl::DrawPolyLine
SalGraphics::DrawPolyLine

in principle all which use the same parameters (e.g. including
basegfx::B2DLineJoin). For me, OpenGLSalGraphicsImpl is new and I am not
sure how/where it is used.
SalGraphics::DrawPolyLine uses SalGraphics::drawPolyLine (small 1st
letter) which is

     virtual bool                drawPolyLine(
                                     const basegfx::B2DPolygon&,
                                     double fTransparency,
                                     const basegfx::B2DVector& rLineWidths,
                                     basegfx::B2DLineJoin,
                                     css::drawing::LineCap) = 0;

and has diverse system-specific implementations that need to be adapted.
In those implementations usually the default value for MiterMinimumAngle
is used (see WinSalGraphicsImpl::drawPolyLine).

Unfortunaltely it is not easy in vcl to do that, the compiler is your
friend. It was already a lot of work to add methods to the whole chain
that use more modern parameters. It is also necessary to adapt all
implementations for all target plattforms and to test compilation on all
plattforms, since this touches plattform-dependent code that is not
built on all plattforms.

Theoretically it would also need to be added to MetaPolyLineAction, but
the Metafile actions have the problem to be saved/loaded, so this is
hard to to backwards compatible. You would need to create a new version
of MetaPolyLineAction, see other examples with MetaActions.

Hard stuff....
I hope this helps!

Regards,
Armin

Am 01.04.2016 um 16:04 schrieb Regina Henschel:

> Hi,
>
> Armin Le Grand schrieb:
>> Hi Regina,
>>
>> Am 24.03.2016 um 16:35 schrieb Regina Henschel:
>>> Hi Armin,
>>>
>>> I need an advice/opinion _where_ to hold the information:
>>
>> Definitely in drawinglayer::attribute::LineAttribute, same place where
>> basegfx::B2DLineJoin is held. A double, defaulted to 15.0 and read
>> access will be fine. For setting it, add a 5th parameter to the
>> constructor, defaulted to 15.0. The LineAttribute is a read-only, not
>> later changeable class to keep things simple. It is better/safer to
>> create another one when a value needs to be changed than starting to
>> keep track of changes and add notification or other stuff.
>
> I'm now at the stage, where createAreaGeometryForJoin() in
> b2dlinegeometry is called with the correct angle in its parameter
> fMiterMinimumAngle. But in the inserted svg image, the join is still
> not changed to Bevel. What places do I need to change in addition? Is
> there something to do in module canvas or vcl or something additional
> in svgio or ...?
>
> Kind regards
> Regina
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

Hi Armin,

Armin Le Grand schrieb:
> Hi Regina,
>
> the MiterMinimumAngle influences only the miter mode, thus I do not
> understand the 'still not changed to Bevel' comment.

I mean, when I set a breakpoint in createAreaGeometryForJoin, which is
called from createAreaGeometry, then I see, that this function will
indeed be hit and the value in double fMiterMinimumAngle is that one,
that it should be according to the SVG source. And in
createAreaGeometryForJoin, there is a case distinction which switches to
B2DLineJoin::Bevel in case the current angle is smaller as
fMiterMinimumAngle. So I had expected, that nothing more was needed.

  In SVG import, the
> primitives and thus the LineAttribute as part of it containing the
> MiterMinimumAngle is directly created, the exactly same instance will be
> used in the renderer and be available in the decomposition.

So you saw, adapting the way through
PolygonStrokePrimitive2D::create2DDecomposition is not enough and I have
to change the renderers parallel?

> I am not sure at which system you are,

only Windows

  but the value needs to be used

> either in
>
>      VclPixelProcessor2D::tryDrawPolygonStrokePrimitive2DDirect
>
> and then handed through
>
>      OutputDevice::DrawPolyLineDirect
>
> like the other values, down to the renderer sal implementation (Gdiplus
> for windows).

It seems, that part is missing.

> Or - when getting decomposed in
>
>      PolygonStrokePrimitive2D::create2DDecomposition
>
> and then handed over to
>
>      basegfx::tools::createAreaGeometry
>
> also like the other values.

There the value arrived.

  Thus, still some hand-through
> implementations needed to pass the value to the places where needed. At
> that places, currently a default is used.
>
> basegfx::tools::createAreaGeometry has an input value for
> fMiterMinimumAngle already.

I have adapted the caller
PolygonStrokePrimitive2D::create2DDecomposition already to use this
argument.

>
> With OutputDevice::DrawPolyLineDirect it needs to be handed over to
> diverse implementations of DrawPolyLine, there seems to be one for
>
> OpenGLSalGraphicsImpl::DrawPolyLine
> SalGraphics::DrawPolyLine
>
> in principle all which use the same parameters (e.g. including
> basegfx::B2DLineJoin). For me, OpenGLSalGraphicsImpl is new and I am not
> sure how/where it is used.
> SalGraphics::DrawPolyLine uses SalGraphics::drawPolyLine (small 1st
> letter) which is
>
>      virtual bool                drawPolyLine(
>                                      const basegfx::B2DPolygon&,
>                                      double fTransparency,
>                                      const basegfx::B2DVector& rLineWidths,
>                                      basegfx::B2DLineJoin,
>                                      css::drawing::LineCap) = 0;
>
> and has diverse system-specific implementations that need to be adapted.
> In those implementations usually the default value for MiterMinimumAngle
> is used (see WinSalGraphicsImpl::drawPolyLine).
>
> Unfortunaltely it is not easy in vcl to do that, the compiler is your
> friend. It was already a lot of work to add methods to the whole chain
> that use more modern parameters. It is also necessary to adapt all
> implementations for all target plattforms and to test compilation on all
> plattforms, since this touches plattform-dependent code that is not
> built on all plattforms.

I first need to make it work on Windows.

>
> Theoretically it would also need to be added to MetaPolyLineAction, but
> the Metafile actions have the problem to be saved/loaded, so this is
> hard to to backwards compatible. You would need to create a new version
> of MetaPolyLineAction, see other examples with MetaActions.
>
> Hard stuff....
> I hope this helps!

Yes. I now see which parts to touch, but it will take some time. I am
glad you take the time to guide me. Luckily it is not a feature, which
is urgently needed.

Kind regards
Regina


>
> Regards,
> Armin
>
> Am 01.04.2016 um 16:04 schrieb Regina Henschel:
>> Hi,
>>
>> Armin Le Grand schrieb:
>>> Hi Regina,
>>>
>>> Am 24.03.2016 um 16:35 schrieb Regina Henschel:
>>>> Hi Armin,
>>>>
>>>> I need an advice/opinion _where_ to hold the information:
>>>
>>> Definitely in drawinglayer::attribute::LineAttribute, same place where
>>> basegfx::B2DLineJoin is held. A double, defaulted to 15.0 and read
>>> access will be fine. For setting it, add a 5th parameter to the
>>> constructor, defaulted to 15.0. The LineAttribute is a read-only, not
>>> later changeable class to keep things simple. It is better/safer to
>>> create another one when a value needs to be changed than starting to
>>> keep track of changes and add notification or other stuff.
>>
>> I'm now at the stage, where createAreaGeometryForJoin() in
>> b2dlinegeometry is called with the correct angle in its parameter
>> fMiterMinimumAngle. But in the inserted svg image, the join is still
>> not changed to Bevel. What places do I need to change in addition? Is
>> there something to do in module canvas or vcl or something additional
>> in svgio or ...?
>>
>> Kind regards
>> Regina
>>
>> _______________________________________________
>> LibreOffice mailing list
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Armin Le Grand-2
Hi Armin,

Addendum: I have now switched off AA. And then the SVG image is rendered
correctly. So it seems, I'm on the right track.

Kind regards
Regina

Armin Le Grand schrieb:

> Hi Regina,
>
> the MiterMinimumAngle influences only the miter mode, thus I do not
> understand the 'still not changed to Bevel' comment. In SVG import, the
> primitives and thus the LineAttribute as part of it containing the
> MiterMinimumAngle is directly created, the exactly same instance will be
> used in the renderer and be available in the decomposition.
> I am not sure at which system you are, but the value needs to be used
> either in
>
>      VclPixelProcessor2D::tryDrawPolygonStrokePrimitive2DDirect
>
> and then handed through
>
>      OutputDevice::DrawPolyLineDirect
>
> like the other values, down to the renderer sal implementation (Gdiplus
> for windows).
> Or - when getting decomposed in
>
>      PolygonStrokePrimitive2D::create2DDecomposition
>
> and then handed over to
>
>      basegfx::tools::createAreaGeometry
>
> also like the other values. Thus, still some hand-through
> implementations needed to pass the value to the places where needed. At
> that places, currently a default is used.
>
> basegfx::tools::createAreaGeometry has an input value for
> fMiterMinimumAngle already.
>
> With OutputDevice::DrawPolyLineDirect it needs to be handed over to
> diverse implementations of DrawPolyLine, there seems to be one for
>
> OpenGLSalGraphicsImpl::DrawPolyLine
> SalGraphics::DrawPolyLine
>
> in principle all which use the same parameters (e.g. including
> basegfx::B2DLineJoin). For me, OpenGLSalGraphicsImpl is new and I am not
> sure how/where it is used.
> SalGraphics::DrawPolyLine uses SalGraphics::drawPolyLine (small 1st
> letter) which is
>
>      virtual bool                drawPolyLine(
>                                      const basegfx::B2DPolygon&,
>                                      double fTransparency,
>                                      const basegfx::B2DVector& rLineWidths,
>                                      basegfx::B2DLineJoin,
>                                      css::drawing::LineCap) = 0;
>
> and has diverse system-specific implementations that need to be adapted.
> In those implementations usually the default value for MiterMinimumAngle
> is used (see WinSalGraphicsImpl::drawPolyLine).
>
> Unfortunaltely it is not easy in vcl to do that, the compiler is your
> friend. It was already a lot of work to add methods to the whole chain
> that use more modern parameters. It is also necessary to adapt all
> implementations for all target plattforms and to test compilation on all
> plattforms, since this touches plattform-dependent code that is not
> built on all plattforms.
>
> Theoretically it would also need to be added to MetaPolyLineAction, but
> the Metafile actions have the problem to be saved/loaded, so this is
> hard to to backwards compatible. You would need to create a new version
> of MetaPolyLineAction, see other examples with MetaActions.
>
> Hard stuff....
> I hope this helps!
>
> Regards,
> Armin
>
> Am 01.04.2016 um 16:04 schrieb Regina Henschel:
>> Hi,
>>
>> Armin Le Grand schrieb:
>>> Hi Regina,
>>>
>>> Am 24.03.2016 um 16:35 schrieb Regina Henschel:
>>>> Hi Armin,
>>>>
>>>> I need an advice/opinion _where_ to hold the information:
>>>
>>> Definitely in drawinglayer::attribute::LineAttribute, same place where
>>> basegfx::B2DLineJoin is held. A double, defaulted to 15.0 and read
>>> access will be fine. For setting it, add a 5th parameter to the
>>> constructor, defaulted to 15.0. The LineAttribute is a read-only, not
>>> later changeable class to keep things simple. It is better/safer to
>>> create another one when a value needs to be changed than starting to
>>> keep track of changes and add notification or other stuff.
>>
>> I'm now at the stage, where createAreaGeometryForJoin() in
>> b2dlinegeometry is called with the correct angle in its parameter
>> fMiterMinimumAngle. But in the inserted svg image, the join is still
>> not changed to Bevel. What places do I need to change in addition? Is
>> there something to do in module canvas or vcl or something additional
>> in svgio or ...?
>>
>> Kind regards
>> Regina
>>
>> _______________________________________________
>> LibreOffice mailing list
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

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

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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

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.

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

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?

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
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Regina Henschel
Hi all,

I have put a patch to Gerrit https://gerrit.libreoffice.org/#/c/23946/
It does only rendering, MetaActions are missing. But it is already so
large, that I think a review would be good before I continue. Because I
can only build and test on Windows, I would be glad, if you would test
and review it for Linux and MacOSX.



For the warning-break [1] on MacOSX from Jenkins I need some help. I
cannot compile or test on Mac.
The value fMiterMinimumAngle has to be used in case eLineJoin ==
basegfx::B2DLineJoin::Miter in OpenGLSalGraphicsImpl::DrawPolyLine
around line 886.
In content this has to happen in that place:
if ('current miter length' > 'miter limit')
then use the same statements as in case Bevel
else use the statement in line 892.

But I'm not sure about the meaning of variable 'length' in line#885.


The MetaPolyLineAction gets a LineInfo and a tools::Polygon, but
LineInfo does neither contain miter minimum angle nor miter limit.
Therefore my question is, how to resolve it. Making a total new
MetaAction? Or extend LineInfo (similar as ExtLineInfo in pdfwriter)? Or
extend MetaPolyLineAction to take a PolygonStrokePrimitive2D or a
B2DPolyPolygon plus the needed line and stroke information separate?

The module com::sun::star::rendering has a struct StrokeAttributes,
which would contain all needed information. How is that currently used?
Is it useful?

Kind regards
Regina


[1]
/Users/tdf/lode/jenkins/workspace/lo_gerrit_master/Gerrit/Gerrit/Platform/MacOSX/vcl/opengl/gdiimpl.cxx:770:167:
error: unused parameter 'fMiterMinimumAngle' [-Werror,-Wunused-parameter]
void OpenGLSalGraphicsImpl::DrawPolyLine(const basegfx::B2DPolygon&
rPolygon, float fLineWidth, basegfx::B2DLineJoin eLineJoin,
css::drawing::LineCap eLineCap, float fMiterMinimumAngle)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

Hi all,

Regina Henschel schrieb:
> In content this has to happen in that place:
> if ('current miter length' > 'miter limit')

I should not write a mail at midnight. The condition is
current ratio miter length to stroke width > miter limit
or
angle between line segments < miter minimum angle

Kind regards
Regina





_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Regina Henschel
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 (see 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice



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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Regina Henschel
Hi Regina,

comments inline :-)

Am 10.04.2016 um 00:46 schrieb Regina Henschel:
> Hi all,
>
> I have put a patch to Gerrit https://gerrit.libreoffice.org/#/c/23946/
> It does only rendering, MetaActions are missing. But it is already so
> large, that I think a review would be good before I continue. Because
> I can only build and test on Windows, I would be glad, if you would
> test and review it for Linux and MacOSX.

I cannot help with Mac - have no possibility to build currently myself.
I can do a linux build - you can do that too on a VirtualMachine, I use
that ;-)

>
>
>
> For the warning-break [1] on MacOSX from Jenkins I need some help. I
> cannot compile or test on Mac.
> The value fMiterMinimumAngle has to be used in case eLineJoin ==
> basegfx::B2DLineJoin::Miter in OpenGLSalGraphicsImpl::DrawPolyLine
> around line 886.
> In content this has to happen in that place:
> if ('current miter length' > 'miter limit')
> then use the same statements as in case Bevel
> else use the statement in line 892.
>
> But I'm not sure about the meaning of variable 'length' in line#885.
>
>
> The MetaPolyLineAction gets a LineInfo and a tools::Polygon, but
> LineInfo does neither contain miter minimum angle nor miter limit.
> Therefore my question is, how to resolve it. Making a total new
> MetaAction? Or extend LineInfo (similar as ExtLineInfo in pdfwriter)?
> Or extend MetaPolyLineAction to take a PolygonStrokePrimitive2D or a
> B2DPolyPolygon plus the needed line and stroke information separate?

Hard to say. It belongs logically to LineInfo, so I would opt to put it
there. MetaActions support new versions, so the old will ignore the new
values, the new can read them. It is necessary to set useful defaults
when old Metafile is loaded, not to forget!

>
> The module com::sun::star::rendering has a struct StrokeAttributes,
> which would contain all needed information. How is that currently
> used? Is it useful?

A fast grep shows that it is used in canvas and cppcanvas. It uses
sal_Int8 for Cap and Join types, this makes it less useful from my POV...


Regards,
Armin

>
> Kind regards
> Regina
>
>
> [1]
> /Users/tdf/lode/jenkins/workspace/lo_gerrit_master/Gerrit/Gerrit/Platform/MacOSX/vcl/opengl/gdiimpl.cxx:770:167:
> error: unused parameter 'fMiterMinimumAngle' [-Werror,-Wunused-parameter]
> void OpenGLSalGraphicsImpl::DrawPolyLine(const basegfx::B2DPolygon&
> rPolygon, float fLineWidth, basegfx::B2DLineJoin eLineJoin,
> css::drawing::LineCap eLineCap, float fMiterMinimumAngle)
>

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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice