summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2014-08-12bnc#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 (cherry picked from commit d068f13596f6d1023a70d98ec2059d38ad6fd777) Reviewed-on: https://gerrit.libreoffice.org/10541 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-08-11bnc#821916: Better algorithm to find placeholder shape.Matúš Kukan3-74/+71
Placeholder type seems to be more relevant than index. Change-Id: I9d6c6cad8e0a51b2385801f65d7d1c697ad7998e Reviewed-on: https://gerrit.libreoffice.org/10844 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-08-11Fix 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 (cherry picked from commit c8cc89ff802d86b1f3a69afe1b4835b7df7f70c7) Reviewed-on: https://gerrit.libreoffice.org/10780 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-08-11bnc#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 (cherry picked from commit 5f47e319428a703ea53ce49d166e7628aaa60789) Reviewed-on: https://gerrit.libreoffice.org/10779 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-08-06bnc#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. (cherry picked from commit 4a8f2431718f99de6fd9ee3461d703d007261c03) (cherry picked from commit 013744a5b475e151ca0918565fb369e22dfbc1db) Conflicts: oox/source/drawingml/chart/chartspaceconverter.cxx Change-Id: Ic4351fe65cabc12d60214b67c7026a317841f2c7 Reviewed-on: https://gerrit.libreoffice.org/10736 Reviewed-by: Matúš Kukan <matus.kukan@collabora.com> Tested-by: Matúš Kukan <matus.kukan@collabora.com>
2014-07-30bnc#885825: OOXML import and export of data label borders.Kohei Yoshida3-137/+113
(cherry picked from commit 48f31a924280a418046f0c816f8a7d20b672dac6) Conflicts: oox/source/export/chartexport.cxx Change-Id: I0fd808145aaeb0aa36d3ec30d7b977890642dcff Reviewed-on: https://gerrit.libreoffice.org/10562 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2014-07-25bnc#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 (cherry picked from commit d60cec0e60c5c0880f8098d39443c391abed80b2) Reviewed-on: https://gerrit.libreoffice.org/10516 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2014-07-23fdo#54361: Chart background in XLSX is transparent instead of whiteHeena Gupta1-1/+4
Cherry-picked from 53b9adc135f4abb086c740582e5f85cea710287d and 6d3269ad94bbad8abae5703edc86d8888356bf14 Change-Id: I96d86854484deb7b5c0b99739fed60a430f2f957 Reviewed-on: https://gerrit.libreoffice.org/10468 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2014-07-21bnc#887230: always use theme color for hyperlinks in ImpressMatúš Kukan1-2/+1
Change-Id: I888f107c61037162439ad2d1ba99ad8185532f71 (cherry picked from commit 92f74f6ccb5a55807724db85815f7ea0c49370e0) Reviewed-on: https://gerrit.libreoffice.org/10384 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
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 (cherry picked from commit ba6da9545764f2545313ba085ed4a096165180fd) Reviewed-on: https://gerrit.libreoffice.org/10385 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2014-07-17Do not prefer bandRow over firstCol/lastCol, nor the same with bandCol.Matúš Kukan1-2/+6
Change-Id: I0c573d721212c870e9ecc99ba5e8494073e09aaf (cherry picked from commit 5d2f12a44d2af3e42e0c3a17ff556f5ada27b1b8) Reviewed-on: https://gerrit.libreoffice.org/10332 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2014-07-17bnc#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 (cherry picked from commit 47645734c350f244b4a5642a709132ca1b7dc75d) Reviewed-on: https://gerrit.libreoffice.org/10331 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2014-07-17bnc#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 (cherry picked from commit f4a2f1e647354efb75be8c90384d6cd3e5f9b9bd) Signed-off-by: Andras Timar <andras.timar@collabora.com>
2014-07-15Related: 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 (cherry picked from commit 6e580f3f53ae2de086a08c8ba1958b67874eb9c5) Reviewed-on: https://gerrit.libreoffice.org/10299 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-07-10bnc#882383: Do not ignore themeOverride for charts in .pptxMatúš Kukan3-1/+68
Otherwise wrong colors are displayed. (cherry picked from commit 08818d8a45e034ad825c7fafbb76766f106f1d1d) Conflicts: oox/source/drawingml/shape.cxx Change-Id: I5d7444100355fdbc5fcd2aaa1c01202ace54312d Reviewed-on: https://gerrit.libreoffice.org/10134 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2014-07-09bnc#881025: Mark axis a percent axis only when all data series are percent.Kohei Yoshida2-10/+34
(cherry picked from commit b8c444a46b2f41dae673c6118d84276be0e6c87d) Conflicts: oox/inc/drawingml/chart/axisconverter.hxx Change-Id: I302cc1e5b164b2ce9999087293b034ec930951af Reviewed-on: https://gerrit.libreoffice.org/10124 Reviewed-by: Matúš Kukan <matus.kukan@collabora.com> Tested-by: Matúš Kukan <matus.kukan@collabora.com>
2014-07-09Adjust 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 (cherry picked from commit af5a6615dfdbe5c2cacdcacb00fc6f418b925c06) Reviewed-on: https://gerrit.libreoffice.org/10123 Reviewed-by: Matúš Kukan <matus.kukan@collabora.com> Tested-by: Matúš Kukan <matus.kukan@collabora.com>
2014-07-07fix crash loading ooo100546-1.xlsCaolán McNamara1-2/+3
regressions around inserted extra enum values into ShapePropertyId (cherry picked from commit aacfd5038d05a02f8b1eade3a5896d3d7e959f3d) Conflicts: oox/source/drawingml/chart/objectformatter.cxx Change-Id: I06696c8cfe4acc3836723c31d5e714bd7d8439b3 Reviewed-on: https://gerrit.libreoffice.org/10108 Reviewed-by: Matúš Kukan <matus.kukan@collabora.com> Tested-by: Matúš Kukan <matus.kukan@collabora.com>
2014-07-03bnc#812796: Correctly handle static value array for OOXML charts.Kohei Yoshida3-5/+7
We need to pass the role of the data sequence in order to avoid unreliable guess work when importing static value array. Also, not all Excel's scatter plots have real numeric X values; some have textural X values in which case Excel switch to generating 1, 2, 3, ... as X values. When importing to our chart implementation, using "categories" role in such cases instead of "values-x" results in a more faithful chart rendering. (cherry picked from commit 6c4e21a234f12e1310ba06f9859e08b424acf8bf) Conflicts: chart2/source/inc/InternalDataProvider.hxx chart2/source/tools/InternalDataProvider.cxx Change-Id: If4bc1f650bb024dcd1b1b36537f457fb38404a78 Reviewed-on: https://gerrit.libreoffice.org/10040 Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2014-07-03bnc#812796: Don't create data series when the series has no values.Kohei Yoshida1-0/+4
Change-Id: I92e2d7a3fab0948aea0557cf3cb65d57d48f3f59 (cherry picked from commit 5e2b7e37a29edf45f829ccee2302a942b54568a1) Reviewed-on: https://gerrit.libreoffice.org/10039 Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2014-07-01Use a new fast parser instance for each XML fragment.Kohei Yoshida1-1/+5
Otherwise a crash ensues when the threaded XML parsing kicks in. Change-Id: Ic41e5a29bbb860d7b63b70f2f0d8896264d9d53e (cherry picked from commit dc93074f71f91efd8a615ad8f1a5289deb210b75) Reviewed-on: https://gerrit.libreoffice.org/10002 Tested-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2014-06-23use the correct default value, fdo#78080Markus Mohrhard2-3/+2
Change-Id: I8b01bf22e8e3b98ef013b947f617905d558d3554 Reviewed-on: https://gerrit.libreoffice.org/9849 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2014-06-11Related bnc#862510: extend handling of txXfrmZolnai Tamás2-28/+34
We don't actually need to check mbAnchorCtr to change text spacing. This txXfrm workaround works only with rectangles, because other shapes' text area can be smaller then the shape size. So add some condition to avoid using it for other shapes. Plus fix typos cause regression introduced in: 53c376d35b7223d53e8c9403390afe53d1f69089 Change-Id: I87917b8e0b2bb97ae1bba773e7dda7f81682736f (cherry picked from commit 98dd0f2bb5801f974374ef341037e094e4275cbb)
2014-06-08DOCX import: recurse into w:ins in groupshape textMiklos Vajna1-0/+7
Groupshape text is provided by editeng, redlining is available in Writer text only. But still, instead of ignoring both deletions and insertions in group shape text, we could at least show the latest version correctly, i.e. ignore deletions but import insertions. Change-Id: I12df2ca1a8d27f9496a8036e521f8820d7075053 (cherry picked from commit e6300f83d08fd959596551dcd660eb0fbfb248a6)
2014-06-07make sure all objects exist, related fdo#75692Markus Mohrhard1-1/+2
fdo75692-2.xlsx and fdo#75692-3.xlsx crash. Change-Id: I56353e7da1850a49e18d3a570641843600d34b1c
2014-06-06bnc#880763: PPTX import: wrong z-order becuause of wrong import orderZolnai Tamás2-9/+12
importExtDrawings() must be called as soon as possible, before parser starts to parse the next shape. Call it when graphicFrame tag is closed. This tag include the reference to the SmartArt. Plus fix up import tests. Change-Id: I9e8d54c2b1afeb78a1122390dc4982d580c152ae (cherry picked from commit 46d682eec92bb241f4604a4b6ab42a3859cd0d48)
2014-06-062nd part of bnc#870233: import font color from color fragment for SmartArtsZolnai Tamás3-41/+60
SmartArt import ignores some fragments during import if drawing fragment exists, which seems to be not complete. In this case font style is blank (white) in data (and drawing) fragment and the real value is defined in the ignored color fragment. So first make color fragment parsing work, then apply font color of "node0" style on nodes of the SmartArt. Actually, it's a workaround, because "node0" style label is hardcoded, for a proper solution layout fragment should be parsed too to get the right style label, but it interferes with the drawing fragment by now. Change-Id: I7db89176a07eee928563d42d3896fbd02190dfa8 (cherry picked from commit 639571d52b1b7e4cf912803642ca245c5dd86839)
2014-06-061st part of bnc#870233: wrong list style in shapesZolnai Tamás1-0/+28
Text list styles were copied, without proper copy constructor and operator. It lad to mix up list styles and so text font. (cherry picked from commit 31650d5b4255c484faec11d570cb98a80f0120cc) Change-Id: Iee7a6c0c1f74322fd7b80e41a262849f948e463a
2014-06-05Be more sensible about checking buffers of VML points we write.Michael Meeks1-0/+8
Change-Id: Id3811dbe0cf2510ef6a851804b3886c14eca01b6 (cherry picked from commit a2d2c7f707838511ede017ed920205b9165a35a2)
2014-06-03oox, writerfilter: Support for artistic effects on picturesJacobo Aragunde Pérez7-0/+437
Bitmaps can define artistic effects like in the following example: <a:blip r:embed="rId5"> <a:extLst> <a:ext uri="{BEBA8EAE-BF5A-486C-A8C5-ECC9F3942E4B}"> <a14:imgProps xmlns:a14="http://schemas.microsoft.com/office/drawing/2010/main"> <a14:imgLayer r:embed="rId6"> <a14:imgEffect> <a14:artisticMarker trans="14000" size="80" /> </a14:imgEffect> </a14:imgLayer> </a14:imgProps> </a:ext> </a:extLst> </a:blip> They are defined in the MS-ODRAWXML extension. Ref: http://msdn.microsoft.com/en-us/library/dd905216(v=office.12).aspx LO core doesn't support them, but I'm preserving them using the shape grab bag. Bitmaps must not be transformed to a SwXTextGraphicObject so the grab bag of the XShape is not discarded. Added several Context and Properties objects on the import side to traverse and save the relevant tags, and added the corresponding code on the export side to extract the grab bag and output the effect back. When Word applies an artistic effect, it creates two embedded files; one contains the bitmap with the effect and the other one contains the original bitmap to be able to undo the effect. We also read the original bitmap, store it in the shape grab bag and save it back to the docx file. When two pictures apply different effects to the same picture, it is only saved once in the original document. Added a cache to DrawingML to know if the picture has already been exported. Finally, added unit tests for a selection of artistic effects. [Squashing commits from master: 21d4cfe19e2796ebf89c408e292c4473924b2bc4 642a252cf1a2f1d08c4bbfcae15527bb82c7664d 2e68a1468c035fc3bb4d02ad0b3187872fe1e67b b5f6a5cfc517ecd8aa6ba96471d854b07b92ebaa 38d7b82c277599f2e613256c4353aa7dfdc219ec] Change-Id: I39327a8118e23829c029122154a31ce3af5b48cd Reviewed-on: https://gerrit.libreoffice.org/9495 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2014-05-30bnc#870237: wrong text position in grouped listZolnai Tamás2-4/+23
In grouped list text area does not cover the whole shape but just a part of it at the top. To get the same visual effect modify text distance attribute. Change-Id: I32f30d0afbc1975f940c4562ec65f46596e97060 (cherry picked from commit 53c376d35b7223d53e8c9403390afe53d1f69089) Reviewed-on: https://gerrit.libreoffice.org/9571 Tested-by: Zolnai Tamás <zolnaitamas2000@gmail.com> Reviewed-by: Zolnai Tamás <zolnaitamas2000@gmail.com>
2014-05-25Resolves: fdo#79137 Crash in oox::vml::InputStream::updateBufferJulien Nabet1-0/+2
bt shows: Program received signal SIGSEGV, Segmentation fault. 0x00002aaadba213fb in oox::vml::InputStream::updateBuffer (this=0x8d7fd80) at /home/julien/compile-libreoffice/libreoffice/oox/source/vml/vmlinputstream.cxx:339 339 while( (mnBufferPos >= maBuffer.getLength()) && !mxTextStrm->isEOF() ) (gdb) bt 0x00002aaadba213fb in oox::vml::InputStream::updateBuffer (this=0x8d7fd80) at /home/julien/compile-libreoffice/libreoffice/oox/source/vml/vmlinputstream.cxx:339 0x00002aaadba21048 in oox::vml::InputStream::available (this=0x8d7fd80) at /home/julien/compile-libreoffice/libreoffice/oox/source/vml/vmlinputstream.cxx:326 0x00002aaacf5a0249 in sax_fastparser::FastSaxParserImpl::parseStream (this=0x89aea30, maStructSource=...) at /home/julien/compile-libreoffice/libreoffice/sax/source/fastparser/fastparser.cxx:810 Indeed, mxTextStrm is invalid, so let's test its validity in InputStream constructor Cherry-picked from 372d5d74ad8cfb9b69dc20557359c4a2c1597b57 Change-Id: Ifed79603e33b64d11eb07656df17824b7f98058f Reviewed-on: https://gerrit.libreoffice.org/9465 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2014-05-22oox: fix export of OOXML generator infoMiklos Vajna1-1/+2
This time we did preserve this info, and we should not. Change-Id: If2ddd7a266cd7da5642dc234411ce34e94bd3384 (cherry picked from commit 3bebb3c2d25601767e950de02f2d549acbdaa2d2)
2014-05-20fdo#78290 : The File gets corrupted when saved in LOBisal Singh Nayal1-2/+3
Problem Description: Docx file containing a chart (line chart / scatter chart)which has used a builtin marker'x' gets corrupted when we save it in LO.The reason was that while exporting LO was writing the marker information 'x' as 'X' which MS Word doesn't recognize.‒<c:marker><c:symbol val="X" />. Also the size of the marker was coming 1 less than the actual value. Ex: if size is 7 then it was being written as 6. Solution: During export I have made changes so that now LO writes 'x' in the tag information ‒<c:marker> <c:symbol val="x" />. Now the size of the marker is also being correctly exported. Change-Id: I26b747f9576625bf3acb941322ae418a0bbc6b64 Reviewed-on: https://gerrit.libreoffice.org/9273 Tested-by: Miklos Vajna <vmiklos@collabora.co.uk> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2014-05-20fdo#78658 Corruption: lockedCanvas tag is missing from RT fileDinesh Patil1-0/+6
While export, locked Canvas is missing and drawing is exported inside textbox. However a locked Canvas has to be exported inside a text-box and drawing should fall under locked Canvas for the RT file to work in MS Office 2010. Reviewed on: https://gerrit.libreoffice.org/9377 Change-Id: Iea2c411302b552db18527001cc4c6d0290085afe
2014-05-19oox: remove using namespace from headersThomas Arnhold1-5/+3
Change-Id: Iaf33c536c86a372aed2a719b6f87a8e03a5481ea
2014-05-19fdo78474:Corruption a:graphicData has no info for the image.Sourav1-1/+4
The original file contains two text boxes one contains image and the other contains chart. Image in text box is not getting imported in LO which leads to no contents inside the a:graphicData tag which is causing the corruption. Root cause is found in ShapeContextHandler::getShape. mxChartShapeContext.is() returns true even when mnStartToken is not set as NMSP_dmlChart which is causing the issue. I have added one more condition to handle this. Change-Id: I6c567d7618b34c1a24f6809801e4460af6894c67 Reviewed-on: https://gerrit.libreoffice.org/9363 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2014-05-17Correct common misspellings, and remove some ASCII art along the way.Chris Laplante2-3/+3
Change-Id: I42787db31769e8bde984c5f4f0aa90335e889b1c Reviewed-on: https://gerrit.libreoffice.org/9356 Reviewed-by: Thomas Arnhold <thomas@arnhold.org> Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
2014-05-16Use SVM (metafile) instead of PNG for diagrams (SmartArt)Tor Lillqvist1-16/+10
It seemed a bit pointless to waste CPU cycles on PNG-compressing a bitmap image only to later then uncompress it anyway. vcl's PNG writing code showed up as 13% on the time profile of TiledLibreOffice when displaying a document full of SmartArts. Miklos suggested I try using SVM (which I guess means "StarView Metafile") instead. When using SVM, no rendering of diagrams to bitmaps during loading is done, but the diagram stays stored in a resolution-independent (vector-ish) form. Which means it will be rendered nicely and crisply regardless of the zoom level. At least, that is my understanding, and experimentation (on OS X and Linux) seems to confirm. ce8c0ff07559ddcc729bffd7a68f4c6f281882e3 Change-Id: Ice8c0ff07559ddcc729bffd7a68f4c6f281882e3
2014-05-16ooxml: Preserve effects on picturesJacobo Aragunde Pérez1-0/+4
If a picture contains some 2D (glow, shadow...) or 3D effect (rotation, extrusion...), we prevent the importer from transforming it into a XTextContent so the XShape grab bag is not removed and the effects are preserved using the existing mechanisms. Added a unit test for this issue, and modified some existing unit tests to match the new behaviour. Change-Id: I3b87069ea208604383a592d34d0a4ceb6b0f9fc7
2014-05-16ooxml: Preserve shape effects when there's more than oneJacobo Aragunde Pérez4-143/+160
Transformed the preservation process of shape effects to be able to store more than one effect. For that we: * Created the Effect struct and added a vector member to the EffectProperties struct. * Changed the shadow effect to use the new Effect struct, EffectShadowProperties struct is preserved because the direction field still has some use but we should remove it. * Changed the structure of the grab bag to store more than one effect. * Modified an existing unit test to check shapes with several effects. Change-Id: I0dd908fa1d9578827c02ef6272fc9e2b914391be
2014-05-16oox: always save all kinds of 3d effects to the grab bag.Jacobo Aragunde Pérez1-1/+1
This was actually a bug. It didn't matter much because a document with an a:sp3d tag but without a:scene3d section would be invalid, but the code was logically wrong. Change-Id: Ifa838e425849642c2a1bf6fca6b6a8dc8ed3b465
2014-05-15Resolves fdo#70681: fixincludeguards.pl: all that's leftThomas Arnhold1-2/+2
Change-Id: I3e51a62710bb46c8255fd228d41d9300c90a1fb5 Reviewed-on: https://gerrit.libreoffice.org/9360 Reviewed-by: Thomas Arnhold <thomas@arnhold.org> Tested-by: Thomas Arnhold <thomas@arnhold.org>
2014-05-14WaE: warning C4701: potentially uninitialized local variableThomas Arnhold1-2/+4
Change-Id: I00a4ebdcfc278274a567403bc1ccb5332ada836f
2014-05-14Find places where uno::Sequence is passed by value.Noel Grandin3-5/+5
Implement a clang plugin to find them, and clean up existing code to pass them by reference. Change-Id: If642d87407c73346d9c0164b9fc77c5c3c4354b8 Reviewed-on: https://gerrit.libreoffice.org/9351 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2014-05-13Work around another seeminly random mis-optimization by Apple's Clang with -OzTor Lillqvist1-1/+15
If it wasn't for the desperate need to minimize code size for LO-based iOS apps, I definitely wouldn't use -Oz in gb_COMPILERDEFAULTOPTFLAGS (in solenv/gbuild/platform/IOS_ARM_GCC.mk). Change-Id: Icb231b5f30b32afe1c0f3b43e5744bf0e41e96df
2014-05-13oox: Use references to prevent unnecessary object copiesJacobo Aragunde Pérez1-2/+2
Change-Id: I5113bc581a8ac98b97c6598a5355e050c7ad7860
2014-05-13ooxml: Preserve shape 3d effects: extrusion and contour colorsJacobo Aragunde Pérez4-3/+104
Shapes 3D effects can specify colors for extrusion and contours like in the following example: <a:sp3d extrusionH="25400" prstMaterial="metal"> <a:extrusionClr> <a:schemeClr val="accent5"> <a:lumMod val="40000"/> <a:lumOff val="60000"/> </a:schemeClr> </a:extrusionClr> <a:contourClr> <a:srgbClr val="3333FF"/> </a:contourClr> </a:sp3d> Colors can be theme-defined or set in RGB and can contain transformations. This patch preserves all the color information using the shape grab bag and modifies an existing unit test to add this check. Change-Id: Ida168affd4ca2135d0bd8f97135dc1cd1e74165a
2014-05-13ooxml: Preserve shape 3d effects: materialJacobo Aragunde Pérez3-2/+41
Shapes 3D effects can specify a material like in the following example: <a:sp3d prstMaterial="metal" z="488950" /> This patch preserves the prstMaterial attribute in the sp3d tag using the shape grab bag and modifies an existing unit test to add this check. Change-Id: I7be2dbbcc7e599d5f0fb8fa53ec1d180c18d8ebd
2014-05-10coverity#1079343 Uninitialized pointer fieldCaolán McNamara1-2/+7
Change-Id: I05ec88144273c15181e9afa8f616b0ab11695f04
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-17 08:09:14 +0000