summaryrefslogtreecommitdiff
path: root/config.guess
diff options
context:
space:
mode:
authorRegina Henschel <rb.henschel@t-online.de>2021-08-25 19:32:36 +0200
committerRegina Henschel <rb.henschel@t-online.de>2021-08-27 13:42:03 +0200
commitc56178f0daf69abb362e6216f51b6e1f5aff1777 (patch)
tree7be81145d0a2176266a0282780fc91c9ac152cac /config.guess
parent6146409978e1a2834c85acff33485f69164ae735 (diff)
tdf#112450 correct points and size for polyline in VML import
The points in file source might have units. Decode was missing. maWidth and maHeight are used in ShapeBase::convertAndInsert(), and moCoordSize is used in PolyLineShape::implConvertAndInsert(). So ShapeContext needs to provide both in case of importing a polyline. That was missing. Word writes the size into the coordsize attribute of the v:polyline element. But from VML specification it need not exist, but bounding rectangle of points has to be used. That is added too. Unclosed polyline cannot be filled in LO and ODF, a fill is only possible for a closed polygon. LO defines a sequence of points as being closed, if first point == last point. The import is adapted to that behavior. Word allows an unclosed polyline to have filling. That cannot be represented with a simple PolyPolygonShape but would need a CustomShape. Because the user cannot yet edit points in a CustomShape but can do that in a PolyPolygonShape, the v:polyline element is not converted to a CustomShape on import and not to DML on export. LO would first need an UI for editing points of a CustomShape. Change-Id: I23d08fda2005f8b36488e1d9ba32e565d8a0f803 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121042 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Diffstat (limited to 'config.guess')
0 files changed, 0 insertions, 0 deletions