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)
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
