summaryrefslogtreecommitdiff
path: root/xmlreader
ModeNameSize
-rw-r--r--Library_xmlreader.mk1411logplain
-rw-r--r--Makefile225logplain
-rw-r--r--Module_xmlreader.mk1010logplain
-rw-r--r--README253logplain
d---------source112logplain
generated by cgit (git 2.34.1) at 2024-07-24 06:51:27 +0000
192b'>simplify "a = a +" to "a +="Noel Grandin mostly so that my stringadd loplugin can point out places to improve Change-Id: I9920ee1c99cdb6b811ba67ff9d8e32aa261884b5 Reviewed-on: https://gerrit.libreoffice.org/80618 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-10-09tdf#127785 Apply 180deg compensation for flipV to text rangeRegina Henschel If a shape is vertically flipped, then the text is rotated by 180deg around the shape center. The rotation is done by SdrTextObj, where text rectangle and shape rectangle are the same, so the rotated text rectangle has the correct position despite flipping. But the text rectangle for SdrObjCustomShape is set by the shape author in the TextFrames attribute and might have an asymmetric position. The patch compensates the flip-rotation by pre-rotate the text rectangle. This replaces commit caaa8fe7c4bb88185b5b11591ee8a619cff0eced. The error in the old patch was, that it has uses a translation instead of a rotation, and has used a wrong place. The result was, that a text box, which has an own TextRotateAngle, had got a wrong position. Change-Id: Id38e8c1839afa5091cd251fc5237315ba7944263 Reviewed-on: https://gerrit.libreoffice.org/80310 Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Tested-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> 2019-10-02tdf#127785 compensate 180deg rotation for position of text boxRegina Henschel If a shape is vertically flipped, then the text is rotated by 180deg around the shape center. The rotation is done by SdrTextObj. There text rectangle and shape rectangle are the same, so the rotated text rectangle has the correct position in regard to flipping. But the text rectangle for SdrObjCustomShape is set by the shape author in the TextFrames attribute and might have an asymmetric position. The patch translates the text rectangle so, that is will be at the correct position after the 180deg rotation. Change-Id: I42e552394cc4b0103530eab48750dd621c52cc5e Reviewed-on: https://gerrit.libreoffice.org/79984 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-10-02loplugin:stringadd in svxNoel Grandin Change-Id: I47944e589c5261d26d5ef0c116a9173bf6ed1f03 Reviewed-on: https://gerrit.libreoffice.org/79983 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-09-29Fix typoAndrea Gelmini Change-Id: I3a322ce0d16daa179dd674b975327180f8b10561 Reviewed-on: https://gerrit.libreoffice.org/79809 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr> 2019-09-28tdf#127785 correct calculation of text rectangle in flipped shapeRegina Henschel The calculation had used a wrong corner. That resulted in negative width or height. Thus the entire shape frame was used as fallback instead of the smaller text rectangle. Change-Id: Ia18d9630dc83c0556115609575f26dcfa71bdb13 Reviewed-on: https://gerrit.libreoffice.org/79774 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-08-10tdf#126512 make handle of ooxml-shapes usable in odpRegina Henschel The error was that handles in OOXML shapes can be used in LibreOffice as long as you work in OOXML format, but not anymore when you convert the file to ODF. Handles in OOXML reference the adjustment values by name, e.g. 'RefX = adj5'. ODF has no way to save this, so this information is lost. The patch reconstructs this information from the shape definition of the preset shape. It gets the preset shape name 'foo' from the shape type 'ooxml-foo'. This means that it only works with our own naming convention. Still, I think it's an improvement for our users. Change-Id: Iebd9f36a5c36356a12c8687e961c7802111cbd85 Reviewed-on: https://gerrit.libreoffice.org/76887 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-06-10tdf#125782 use correct 'current point' for quadraticcurvetoRegina Henschel Use the same way to get the 'current point' as in command arcangleto. The error was visible in shape teardrop. Change-Id: Ie7af2b9111150bae7e3ea492eeb439a0cc2bfe7c Reviewed-on: https://gerrit.libreoffice.org/73723 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-05-25tdf#125181 Update comment in unit test for added shapesRegina Henschel I have recently added shapes star24 and star32 to the unit test, but forgotten to update the comment in the test accordingly. Change-Id: I712c652100cadedc06a0b16c8dd27dc078cdbbeb Reviewed-on: https://gerrit.libreoffice.org/72954 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-05-17tdf#115813 unit test for handle position of OOXML shapesRegina Henschel The patch contains some additions to tdf#115813 and a unit test. The test covers nearly all OOXML preset shapes with handles. Only some shapes do not fit to the test pattern: swooshArrow and polar handle shapes arc, blockArc, chord, circularArror, mathNotEqual, pie, leftCircularArrow, leftRightCicularArrow. The shapes star24 and star32 are excluded because of tdf#125181. The shapes gear6 and gear9 are excluded because a correct handle movement is not yet implemented. Connector shapes are inserted as ordinary shapes to prevent converting. The error string is designed to identify the affected shape. Change-Id: Icd3358f3701ac2db2cc61eb045ae10bc4b72b9ca Reviewed-on: https://gerrit.libreoffice.org/72229 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-04-16tdf#124740 Handle position is already scaled for ooxml-foo shapesRegina Henschel If a 'ooxml-foo' shape has a path internal coordinate system by using w and h attribute, the position of the handle was out of place. Because in 'ooxml-foo' shapes the handle position is not directly connected to the adjustment value but via formulas, the handle position is already scaled when calculating the position. Change-Id: I84ef8c5ea3bbe94a1bfd9d8ba17b97248086234f Reviewed-on: https://gerrit.libreoffice.org/70783 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-04-02Fix typoAndrea Gelmini Change-Id: Iccc8c8b82efb00df491d5283512b60d6d1746735 Reviewed-on: https://gerrit.libreoffice.org/70101 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de> 2019-04-01tdf#124029 Force correct import pos&size of mso_sptArc shapeRegina Henschel mso_sptArc uses the current pos&size of the sector as frame rectangle LO has used the underlaying ellipse. That has resulted in wrong shape position and text wrap problems in Writer. The patch sets the viewBox to the current pos&size of the sector and thus force the frame rectangle to the same values in LO as in MS Office. For details see bug report. Change-Id: I039c27f57966bad25e9f2123f50728e6a15f2f7e Reviewed-on: https://gerrit.libreoffice.org/69829 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-03-21tdf#124212 make adjustment handle work alwaysRegina Henschel In method SetHandleControllerPosition() all transformations are reversed to get the coordinates in shape inner coordinate system from the outer position. The error was, that the first transformation, the move in method GetPoint was forgotten. In case of default viewBox '0 0 21600 21600' it is not visible. But the error is noticeable, if left or top do not equal zero. Change-Id: Icc3f4f2c603826151c95b8b9eea5030fb5805d67 Reviewed-on: https://gerrit.libreoffice.org/69439 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-03-21CppunitTest_svx_unit: use CPPUNIT_TEST_FIXTURE()Miklos Vajna Change-Id: Ib2eac7368ebb06702f05101641e8830ea1fff6d5 Reviewed-on: https://gerrit.libreoffice.org/69483 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2019-03-04tdf#121845 rework custom shape path command U and TRegina Henschel The patch covers several errors, see comments in the bug report. Change-Id: I6cdaf3e8951dab21b314ef61e12ffa3b3ee481dc Reviewed-on: https://gerrit.libreoffice.org/68029 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2019-01-29Removed executable permission on source fileAndrea Gelmini Change-Id: I085a21afdf842a70dcdaaf9694fc6b09502985fe Reviewed-on: https://gerrit.libreoffice.org/67096 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2019-01-29Improve ODF enhanced-path command moveTo to follow specRegina Henschel ODF 1.2 section 19.145 says 'If a moveto is followed by multiple pairs of coordinates, they are treated as lineto.' The patch does this on import. Change-Id: Ib493ca49288cdb2d34b7ee801bd052281617d2e8 Reviewed-on: https://gerrit.libreoffice.org/66888 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2018-12-23tdf#121761, tdf#121952 Accurate ellipsequadrant in custom shapeRegina Henschel The current solution uses one, bad valued Bezier curve and does not toggle direction. The patch uses the more accurate solution from basegfx and simplifies the decision tree. In addition it extracts the calculation in double from GetPoint, so they can be used directly instead of double->long->double conversion. Change-Id: I298f49415d1b7624b36ca561647f2e58af5eb5c6 Reviewed-on: https://gerrit.libreoffice.org/65203 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> 2018-12-14Removed executable permission on .cxx fileAndrea Gelmini Change-Id: I09775c92f7c5b5e0f554a2822d243a230a06f626 Reviewed-on: https://gerrit.libreoffice.org/65136 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2018-12-13tdf#121890 ODF custom shapes use left and top from viewBoxRegina Henschel MS custom shapes use always zero for identifier left and top in the formulas of the shape geometry. But custom shapes in ODF use the left and top value from the svg:viewBox attribute, see table 11 in section 19.171 draw:formula; part 1 of the spec. Change-Id: Ief4b9d9b8797e165a494d049f32c5a46880044c2 Reviewed-on: https://gerrit.libreoffice.org/64704 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>