B2DLineJoin::Middle, drawPolyLine etc

[Armin Le Grand]

Hi Caolan,

no, not an error, another simple LineJoin method which just takes the 
'middle' of the points to be joined. LineJoins are for fat lines, so you 
have an inner and outer edge of the current and next segment. To join 
the points of the inner edges, these are added and divided by two, same 
for outer.
I do not remember where that came from, but it was used in some graphic 
system and seemed a nice method for doing line joins. It should in 
practise not be used much and did not make it into current/modern 
systems, but is handled correctly e.g. in the primitive decomposition of 
fat lines.
There are always exceptions in different systems, e.g. for DirectDraw on 
Win there is no B2DLineJoin::NONE, so this has to be painted by painting 
the single line segments.
For a primitive renderer this means if there is no support for that 
style for the renderer you currently feed, use the decomposition :-)
In practise I know of no current usages - even on the UI that flag is 
missing. If it can be removed (UNO API, ODF, ...), remove it.

HTH!

Am 02.02.2016 um 12:27 schrieb Caolán McNamara:
> What is B2DLineJoin::Middle supposed to be ?
>
> I see that the vcl pdf, windows and quartz backends treat ::Middle the
> same as ::Mitre (so I made the cairo one do the same)
>
> On the the other hand I see cppcanvas...setupStrokeAttributes and
> filter...ImplWriteLineInfo would default ::Middle to the same as ::NONE
>
> while
>
> cui...SvxLineTabPage::Reset and
> svx...LinePropertyPanelBase::updateLineJoint treat LineJoin_MIDDLE the
> same as ROUND but
> filter...EscherPropertyContainer::CreateLineProperties and
> oox...DrawingML::WriteOutline the same as BEVEL
>
> Is ::Middle a "mistake" and we should just treat it as ::Mitre
> everywhere ? Especially as that's what it turns into for the windows
> vcl drawPolyLine. Or is there some subtlety here ?
>
> C.

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