summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2014-08-07Avoid incomplete type in fn sig to keep ubsan's RTTI-based checks happyStephan Bergmann2-0/+2
Change-Id: I9d58782c3d3bd09dc0d1d7121c057541f1186b43
2014-08-07remove unnecessary references to test-install (just use instdir)Michael Stahl1-3/+3
Change-Id: I99f19a3e2ed166c2ea4397f8767975973dd5d983
2014-08-07If dev-install is obsolete, why have it at all?Tor Lillqvist1-3/+3
Replace mentions of it in a few (dcumentation) places with test-install. Change-Id: I6fc8e58fa5813b05de16feec35215c83e0e45834
2014-08-05Avoid exporting label placement property when the chart is 3D.Kohei Yoshida1-10/+19
MS Office has trouble loading the file if you do. There is an exception, however. A pie chart allows label placement option even when 3D. There may be other chart types that allow variable label placement when 3D. Change-Id: I6a9247041ca6ee3ae1b9c245f5919fcb35951f24
2014-08-05oox: tokenize all attributes from CT_CnfMiklos Vajna1-0/+8
Change-Id: Ifceb9c1319208c897a6f018fa0b5f8863b58c3e1
2014-08-05oox: sort tokens.txtMiklos Vajna1-25/+25
The benefit is that then it's possible to just add new tokens at the end of the file, have your editor put them to their sorted place and have no additional noise in the commit diff. Change-Id: I221b8b10ae588180dd61207a6c9279fe8af7531f
2014-08-04Consistency around SdrOnOffItem in svx/sdtagitm.hxxStephan Bergmann1-2/+2
...similar to what has been done for svx/sdtmfitm.hxx in 6a2ea81ca1622d2c2ad55bea8ddc28167fcc2794 "Remove unused ctors" and 68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem." Change-Id: I6d8b3709d6d55bd6958d38f262141c43779dfdcc
2014-08-04Let's not forget the keyword.Kohei Yoshida1-1/+1
Change-Id: I86c114e903eaee1404875a794ed4f1c76f61169e
2014-08-04bnc#886540: Default chart background for pptx docs should be transparent.Kohei Yoshida3-1/+18
Charts in docx and xlsx OTOH use solid white as the default fill style. Change-Id: Ic4351fe65cabc12d60214b67c7026a317841f2c7
2014-08-04oox: tokenize noHBand and noVBandMiklos Vajna1-0/+2
Change-Id: I43ea6cb2665e17239da61adffd0583b9201bef59
2014-08-04fdo#78301 : Size of word-arts change during import.Umesh Kadam1-0/+16
- Do not resize the fallback geometry for Word-Arts(VML), since the overlay geometry is constructed using the properties of the fallback geometry. - The resize autoshape to fit text attr of FontWork/Word-Art should always be false for the fallback geometry(the SdrObject). Change-Id: If8badb382c525875a07a0a9e6268cec036739001 Reviewed-on: https://gerrit.libreoffice.org/10486 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2014-08-01fdo#80895 : Shape in Header&Footer is getting lost after RTTushar Bende1-1/+9
If there is a shape in Header or footer in a docx created in MSO-2010 that shape was getting lost after RT(actually shape was there but it's properties were getting missed). Root cause was : When LO processes Header it has msRelationFragmentPath= header.xml in ShapeContextHandler::startFastElement() and searches for theme as there is No theme specific to header or footer, aThemeFragmentPath becomes empty in that case. This is because MS office shares same theme for both documentBody as well as Header or footer. To fix Get Target for Type = "officeDocument" from _rels/.rels file this target is "word/document.xml" for docx & to "ppt/presentation.xml" for pptx and use this Target for fetching correct theme.xml. Tested group shapes in header/footer,previously was not getting rendred and not preserved after RT.After this patch it's now working correctly. Tested chart in header/footer previously chart colour was not coming properly both during rendering as well as after RT.after this patch it's working correctly. Reviewed on: https://gerrit.libreoffice.org/10451 Change-Id: Id47008550da90c0d697b434b676765230e3258a7
2014-07-29Fix some number format issues, bnc#862510Matúš Kukan3-6/+6
Set "LinkNumberFormatToSource" to false, so that format code is not ignored. Also, do not inherit format code common for all labels, if there is specific format code for a data label. Change-Id: I505311d5df641d61e616e354734bd332609fa122
2014-07-29bnc#862510: PPTX import: Properly show data labels in percent format.Matúš Kukan1-2/+5
Usually, "General" is "0.00" number format, but in this case, when we want to show percent value, MSO writes that instead of "0%". Change-Id: I748719765f58e66f9f3fb43c2b527c6823ef6fa1
2014-07-29fdo#46037: remove unused comphelper/configurationhelper.hxxAlexandre Vicenzi1-1/+0
Change-Id: I66f9d2912202ba1393d0c65189f8a945bca4fcaa Reviewed-on: https://gerrit.libreoffice.org/10603 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2014-07-27indentation fixesMiklos Vajna1-2/+2
Change-Id: I0a0f04d0f0e008e8947a5a7e3ed6083c1589e61b
2014-07-26bnc#885825: OOXML import and export of data label borders.Kohei Yoshida3-135/+115
2014-07-25WaE: extern prototype in main file without definitionTor Lillqvist1-2/+0
Change-Id: I7121bf7bcc043065d4f10f7c67aaecd7059d6f89
2014-07-24Remove compiler warning.Kohei Yoshida1-3/+3
nTransparancy will be left uninitialized if unstuffing the value from the Any value fails. Change-Id: I06a5853066edeb39b811bf12fd09afbc11792add
2014-07-24bnc#887227: Do not set TextAutoGrowHeight for vertical text.Matúš Kukan1-1/+5
It's horribly broken and it would resize text box horizontally which is not supposed to happen. Change-Id: I201ec8dbcddca56d21bf46ea8ee838d01923c442
2014-07-24bnc#862510: PPTX import: bullets have color as following text by default.Matúš Kukan1-0/+2
aTextCharacterStyle contains font theme color set in Shape::createAndInsert. Change-Id: I55e66aeaa7176fbd3f64dcdf075d411f460947d4
2014-07-21Most certainly meant to be plural.Kohei Yoshida1-1/+1
Change-Id: I3772091c77307892b13d75cc6a5a191ec07c7bf5
2014-07-21WaE: passing class rtl::OUString by value, rather pass by referenceTor Lillqvist1-1/+1
Change-Id: Ib332d04fa27501ec35267b5e389c2979c9c55be2
2014-07-21fdo#78663 : The File gets corrupted when saved in LOBisal Nayal1-13/+2
Problem Description: The docx file contains a word art inside a drawing tool. After RT, nesting of <txbxContent> tag is happening which is causing the corruption. Solution: Created a service in util.cxx for checking few shapetypes for which textbox with content is not allowed. This check also helps to find that if we are already inside a DML then we should purely read VML Information.An existing UT testWordArtWithinDraingtool was failing. The UT is related to same issue (word art inside drawing tool) hence changed it accordingly. Following is the commit id of the UT-Change-Id: I00e94712e912ad1977fcb65a945fefb927795d77 Change-Id: I7e456c9f6a69af80da443e29eb02a64ba7d59468 Reviewed-on: https://gerrit.libreoffice.org/10229 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Luboš Luňák <l.lunak@collabora.com>
2014-07-21fdo#80897: Preservation of text warp properties.Rohit Deshmukh5-8/+48
- Generic fix for all warp properties Change-Id: I77c37759aa49706fc3cd1a80770a85face53f0a2
2014-07-20cppcheck: Prefer prefix ++/-- operatorsJulien Nabet1-5/+5
Change-Id: If9fa06958c4ebb45a5d4acf3b2994dd3b79f81bf
2014-07-18coverity#1038295 Unchecked dynamic_castCaolán McNamara1-2/+2
Change-Id: I0206983f7dd57626a7d33a95d5025af1b12ed9d3
2014-07-18coverity#1202900 Uncaught exceptionCaolán McNamara1-1/+1
Change-Id: I9e49abc490935710b471c79d19385bda37f038b0
2014-07-18coverity#1226484 Using invalid iteratorCaolán McNamara1-1/+1
Change-Id: I30e4d365fb2a851ea8d81e9f45a6f4d0bf6d7ec7
2014-07-18coverity#1226480 Unchecked dynamic_castCaolán McNamara1-1/+1
Change-Id: I07c0ee479a384d213a1b9b9252846bd9873b0bdc
2014-07-18Use comphelper::SequenceAsHashMapMiklos Vajna1-20/+10
Change-Id: I5e4dc99c86b696d2c00392fdb47c4d9ebb7f14ff
2014-07-18oox: write Company in docProps/app.xmlMiklos Vajna1-1/+16
Change-Id: I8474b8ec7415b4d8e067343295ea985319c34834
2014-07-18use rtl::math::round here to get the same number on 32/64bit platformsMatúš Kukan1-1/+2
This fixes sd_import_tests where 100*0.35 was 34 on 32bit platform. Change-Id: I45705326e91892beb814bd94e074b0a652709768
2014-07-18bnc#887230: always use theme color for hyperlinks in ImpressMatúš Kukan1-2/+1
Change-Id: I888f107c61037162439ad2d1ba99ad8185532f71
2014-07-17coverity#735310 Unchecked return valueCaolán McNamara1-2/+1
Change-Id: I1a35da4b23b9ff8efa8f500eaf18e4c259cc0177
2014-07-17fdo#80894 : Rotation value for textframe was missing after RT.sushil_shinde2-1/+7
- Rotation property is not available for TextFrame in LO. - Hence grabbaged this value. - Roundtripped rotation value by converting it properly for both dml and vml textbox. - Added UT for it. Change-Id: Ia040d55dc2ea79500df76877ba44a02971c872a8 Reviewed-on: https://gerrit.libreoffice.org/10190 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2014-07-16Try to fix compilation with pre-C++11 compilerTor Lillqvist1-2/+2
Change-Id: Ic014db043a08fc2b82c56e6a1f944c9403c441d0
2014-07-16bnc#862510: Improve handling of OOXML gradientsTor Lillqvist2-26/+192
OOXML gradients can have an arbitrary number of "stops". LibreOffice gradients have just a start and end colour, plus an optional uniformly coloured border (on the "start" side). In addition, LibreOffice has the "axial" gradient mode, which means the gradient is reflected in the middle. It is thus obviously impossible in general to losslessly map OOXML gradients to LibreOffice ones. But let's try a bit harder than earlier to get visually more similar result, in at least some simple sample cases. We look for the widest gradient segment and use that for the start and end colours of the LibreOffice gradient. Also, map an OOXML gradient to an axial LibreOffice gradient only if it is symmetrical. Also, use the border property when suitable. In general, look for the widest OOXML gradient segment (once a segment corresponding to the LibreOffice gradient border, if any, has been accounted for) and use that as the LibreOffice gradient. Possibly some perceptionally better heuristic should be used... Like, if we have a three-segment gradient, with a wide gradient segment between two visually very similar colours (for example, two shades of red), and a narrower segment ending with a visually very different colour (for example, yellow), it probably would be best to represent that in LibreOffice as a gradient from the first red shade to yellow, instead of as a gradient between the two shades of red. Or even, if a first or last gradient segment is between very similar colours, equalize those start and end colours, thus using a border colour in LibreOffice instead. The possibilities for bikeshedding are endless. I am sure there are instances where the old code (by accident?) produced visually more pleasing results... But hopefully this works more pleasingly and consistently in a larger number of cases. Change-Id: If153e986ad943454307e3ba718479d5ac4cdc7ab
2014-07-15fdo#80569:FILEOPEN:4.4 Regression .docx chart not rendered properlyHeena Gupta2-1/+5
Change-Id: Ic3304c1bd11fcd372a0859a70a531675effe7af0 Reviewed-on: https://gerrit.libreoffice.org/10322 Reviewed-by: Muthu Subramanian K <muthusuba@gmail.com> Tested-by: Muthu Subramanian K <muthusuba@gmail.com>
2014-07-15Do not prefer bandRow over firstCol/lastCol, nor the same with bandCol.Matúš Kukan1-2/+6
Change-Id: I0c573d721212c870e9ecc99ba5e8494073e09aaf
2014-07-15bnc#887225: OOXML import: Correctly apply table style for lastRow.Matúš Kukan1-1/+1
nMaxColumn and nMaxRow are indexes, so use size() - 1. Change-Id: I20055e55cf2464710fe553fb8067bad13a339084
2014-07-15DOCX FILEOPEN VML Shape (image) is lost on import fdo#81031Vinaya Mandke1-1/+13
ShapeContextHandler::getDrawingShapeContext mxDrawingShapeContext is set once and never reset. So in a file which has numPicBullets and vml shapes in document.xml there is a problem. First the fragment path is set as word/numbering.xml. But when msRelationFragmentPath changes to word/document.xml, mxDrawingShapeContext is not reset and hence the relationships are not resolved. Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport.cxx Reviewed on: https://gerrit.libreoffice.org/10180 Change-Id: I4a1401103797972731257145430f2048b94a04bc
2014-07-14oh for the love of...Caolán McNamara1-1/+1
Change-Id: I5cb90f10112afda77e68035d89cb7026d6e32eec
2014-07-14Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImageCaolán McNamara1-8/+26
I imagine it would be best that the Graphics were delivered pre-swapped in by higher levels in case there are second level caches or more complex caching systemed wrapped around it, so warn about it in debug mode but give it a last-ditch shot anyway. i.e. while the .docx problem should be fixed there is a report of a very similar .xlsx problem Change-Id: Ie40ee10fe5cba8ff9c321f47b83e33ee2c1425fd
2014-07-10coverity#1224995 Uncaught exceptionCaolán McNamara1-1/+1
and coverity#1224994 Uncaught exception Change-Id: I7f25e3829dbd1e5d68561ca9853ab8fc10c79484
2014-07-10coverity#1224997 Uncaught exceptionCaolán McNamara1-1/+1
and coverity#1224996 Uncaught exception Change-Id: I36ea602a93471d826859bef739c4165117cc4cd9
2014-07-09remove no longer needed http://sprm nonsenseMiklos Vajna2-2/+0
Change-Id: I2f8d473ab564c9849963d937690fc48bc04a17b9
2014-07-07bnc#881025: Mark axis a percent axis only when all data series are percent.Kohei Yoshida3-16/+38
Change-Id: I302cc1e5b164b2ce9999087293b034ec930951af
2014-07-07Adjust for the splitting of number format properties in chart.Kohei Yoshida3-12/+5
Since 1d38cb365543924f9c50014e6b2227e77de1d0c9, "number format" and "link number format to source" properties are 2 separate properties. Adjust OOXML import code for that split. Also, always set axis' number format via NumberFormat property even when it's a percent format. The axis object doesn't keep a non-percent and percent number formats separately. Change-Id: I8667b6f1a78d88cc37d059518919ad1b37f154e1
2014-07-07bnc#882383: Do not ignore themeOverride for charts in .pptxMatúš Kukan3-1/+68
Otherwise wrong colors are displayed. Change-Id: I5d7444100355fdbc5fcd2aaa1c01202ace54312d
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-23 12:36:40 +0000