summaryrefslogtreecommitdiff
path: root/vcl/qa
AgeCommit message (Collapse)Author
2022-03-09PDF export of PDF images: don't preserve annotations in generalMiklos Vajna
Regression from 33c9bc0225a92f26770f9ef20b252af47853e7b9 (PDF export of PDF images: preserve hyperlinks, 2022-01-07), the problem was that we want to preserve hyperlinks, but annotations are added by the PDF export explicitly, so it isn't a good idea to "preserve" them as well. Fix the problem by going back to the old behavior, except when the annotation sub-type is /Link. This keeps hyperlinks working but doesn't lead to duplicated comments when re-exporting an image + adding comments explicitly. Conflicts: vcl/qa/cppunit/pdfexport/pdfexport.cxx Change-Id: I910990da59bdc1150cc346f1a5471cb6da55dd2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131262 Tested-by: Aron Budea <aron.budea@collabora.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2022-02-07PDF export: improve precision of pdf image sizescp-6.4-55co-6.4-55Miklos Vajna
This helps exporting full-page PDF images from Draw more accurately. In case the page size was A4, then the page height is 841.8897637795276 i.e. 842 points. Full-page PDF images are scaled to this size, so the referred PDF form XObject has the reciprocal of that scaling. We used to just write 0.00118, doubling the precision leads to 0.0011878840. In practice the old precision resulted in e.g. hyperlink rectangles to get out of sync with link text after 2 roundtrips, while the new precision doesn't result in any noticeable modification to the link text position after a roundtrip. (cherry picked from commit 50682cea4196819980c8e2d4018f80384097ce6f) Conflicts: vcl/qa/cppunit/pdfexport/pdfexport.cxx Change-Id: I72cc68696b9b9bcc1cbfde8df331c2b9c5f9eb29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129498 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129592 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-01-11PDF export of PDF images: preserve hyperlinksMiklos Vajna
The input file has a single page, with a full-page PDF image, which contains a hyperlink. Similar to pdfcrop, we used to wrap this into a form XObject, so page-level annotations like hyperlinks were lost. Explicitly merge page-level annotations from the source page to the page that contains the PDF image to preserve those annotations. (cherry picked from commit 1984a5c140cc3c7c291047dacf3bddd7061d2047) Conflicts: vcl/qa/cppunit/pdfexport/pdfexport.cxx Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128127 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 58e6fce28f7d3e1c1504f048be5766dc732af4e7) Change-Id: I96e8bc9d33440b91f3514486d6a8bd75047546b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128253 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-01-05tdf#73523 do not seek backwards, the color mask info is not thereAndras Timar
Change-Id: I97f0fd4f184ea77beeab8b22fc98fdb78472d9bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127928 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2021-05-19vcl PDF export: fix re-exporting PDF images with arbitrary page-level rotationMiklos Vajna
Building on top of commit bd520b177637d4b7d9d93733103cff17a3c91b0a (vcl PDF export: fix re-exporting PDF images with page-level rotation, 2019-11-06), this was already working for 90 degrees, now generalize this to work with 180 degrees as well. (cherry picked from commit d7d43cf460d66354a40ffa3b34c0f9efcd42d0be) Conflicts: vcl/qa/cppunit/pdfexport/pdfexport.cxx vcl/source/gdi/pdfwriter_impl.cxx Change-Id: I5a5d51662399814d5554d7c2cb86a6c9a2974012 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115712 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Ashod Nakashian <ash@collabora.com>
2021-05-14vcl PDF tokenizer: fix EOF position when \r is not followed by \nMiklos Vajna
Otherwise this would break partial tokenize when we only read a trailer in the middle of the file: m_aEOFs.back() is one byte larger than rStream.Tell(), so we reader past the end of the trailer, resulting in a tokenize failure. What's special about the bugdoc: - it has 2 xrefs, the first is incomplete, and refers to a second which is later in the file - the object length is as indirect object, triggering an xref lookup - the first EOF is followed by a \r, but then not with a \n This results in reading past the end of the first trailer and then triggering a lookup failure. FWIW, pdfium does the same in <https://pdfium.googlesource.com/pdfium/+/59d107323f6727bbd5f8a4d0843081790638a1dd/core/fpdfapi/parser/cpdf_syntax_parser.cpp#446>, we're on in sync with it. (cherry picked from commit 6b1d5bafdc722d07d3dc4980764275a6caa707ba) Conflicts: vcl/qa/cppunit/filter/ipdf/ipdf.cxx Change-Id: Ia556a25e333b5e4f1418d92a98d74358862120e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115537 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-05-07vcl pdfium render: handle widget annotations for form fieldsMiklos Vajna
Note that we render the bitmaps without FPDF_ANNOT, so comments are not rendered into the bitmaps, rather we create them on top of the bitmaps in Draw, explicitly. FPDF_FFLDraw() draws content which is already an annotation, but not yet interactive content; so this just fixes "missing text", as far as the user is concerned. Verified that e.g. vcl/qa/cppunit/data/PangramAcrobatAnnotations.pdf indeed still doesn't render comments into bitmaps after this. (cherry picked from commit 92cba30d5ce45e4f4a9516a80c9fe9915add6905) Conflicts: include/vcl/filter/PDFiumLibrary.hxx vcl/qa/cppunit/PDFiumLibraryTest.cxx vcl/source/filter/ipdf/pdfread.cxx vcl/source/pdf/PDFiumLibrary.cxx Change-Id: I2b74d585729305cc1d3a9fefa258d4d76d1bd038 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115167 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-03-13tdf#140606 make PDF parsing more lenient and prevent a crashTomaž Vajngerl
If the external document can't be opened, it tried to continue with the export anyway, which eventually lead to a crash. This is fixed by handling this situation and prevent a crash, however the part of the document in this case isn't exported. The document couldn't be opened because of a parsing error - there was a unexpected null character instead of a whitespace, which made the parser panic. Fix this by making the parser more lenient in such a situation when there is an unexpected null and try to continue parsing. Bug document seems to be created with a buggy PDF writer, but other PDF readers don't complain when parsing the document so it looks to be a valid. qpdf --check doesn't complain either. Added a test that checks a document with a null parses. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111820 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 2c1ed5a5dad827cde032f27a4348e81be15889bc) Change-Id: I61eb281e821ccd195ef006d778556e25d1c7f5e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112418 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-11-26pdf: workaround to disable swapping of PDF graphic filesTomaž Vajngerl
This is needed so that swapping doesn't create excesive amount of swap files, where each includes the original PDF file, which would take a lot of temp disk space. This happens because each graphic object swaps out the original PDF and we create one graphic object per page. In a problematic PDF this means it took 20MB (PDF file) * 700 (pages) ~ 14 GB ob disk space. Change-Id: Id5f720946ce6b3f5aca92bc6d1af388fe8dbcc64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106651 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-11-13pdf: test PDFDocument parsingTomaž Vajngerl
basic.pdf is custom created so it covers all different parsing use-cases. Change-Id: I6eefa55b1cec5bf7eb91518d6a2df2cb48746dcc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105781 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-11-12vcl pdf tokenizer: fix handling of dict -> array -> dict tokensMiklos Vajna
Needed to be able to parse the /Reference key of signatures. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104443 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 056c1284d6a68525002c54bef10834cc135385db) Change-Id: I6b81089a3f58a2de461ad92ca5a891c284f8686a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105635 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-28pdf: deduplicate resources when copying from external PDF streamTomaž Vajngerl
When using external PDF stream/data (from PDF graphic objects), make sure to copy the content of external PDF resources (fonts, bitmaps, forms) only one time (by sharing the map between calls) and every other use, just use the reference to the objects. Change-Id: Ibaa632c8f74806eb195e69404551db6fd077a986 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104935 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-11external: update pdfium from 3963 to 4137Miklos Vajna
This is a combination of 6 commits, which brings pdfium to the same version as libreoffice-7-0. This is the 1st commit message: external: update pdfium to 4021 (cherry picked from commit 1cb70721ba00dd6c6958f0a10e39aa5c1866ec96) This is the commit message #2: external/pdfium: C++20 comparison operator fix Missing const leads to overload resolution ambiguity when a synthesized candidate of operator == for a reversed-argument rewrite conflicts with the actual operator ==, due to the asymmetric const-ness of the implicit object parameter and the RHS parameter: > In file included from workdir/UnpackedTarball/pdfium/core/fxge/cfx_font.cpp:7: > In file included from workdir/UnpackedTarball/pdfium/core/fxge/cfx_font.h:11: > llvm/inst/include/c++/v1/vector:1369:27: error: use of overloaded operator '!=' is ambiguous (with operand types 'std::__1::__vector_base<unsigned char, FxAllocAllocator<unsigned char> >::allocator_type' (aka 'FxAllocAllocator<unsigned char>') and 'std::__1::__vector_base<unsigned char, FxAllocAllocator<unsigned char> >::allocator_type') > if (__base::__alloc() != __c.__alloc()) > ~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~ > llvm/inst/include/c++/v1/vector:1359:5: note: in instantiation of member function 'std::__1::vector<unsigned char, FxAllocAllocator<unsigned char> >::__move_assign' requested here > __move_assign(__x, integral_constant<bool, > ^ > workdir/UnpackedTarball/pdfium/core/fxge/cfx_font.cpp:384:24: note: in instantiation of member function 'std::__1::vector<unsigned char, FxAllocAllocator<unsigned char> >::operator=' requested here > m_FontDataAllocation = std::vector<uint8_t, FxAllocAllocator<uint8_t>>( > ^ > workdir/UnpackedTarball/pdfium/core/fxcrt/fx_memory_wrappers.h:74:8: note: candidate function > bool operator!=(const FxAllocAllocator& that) { return false; } > ^ > workdir/UnpackedTarball/pdfium/core/fxcrt/fx_memory_wrappers.h:73:8: note: candidate function > bool operator==(const FxAllocAllocator& that) { return true; } > ^ > workdir/UnpackedTarball/pdfium/core/fxcrt/fx_memory_wrappers.h:73:8: note: candidate function (with reversed parameter order) (cherry picked from commit 6e0461d576d9f386e458f98f3c57f0ba385aacb4) This is the commit message #3: pdfium: don't patch out the COMPONENT_BUILD check, define it So next time we update, no need to adapt a failing patch. (cherry picked from commit 9b4ab9bda41a818832c721933986c9c6e07a6e6c) This is the commit message #4: make update_pch also consider files in <module>/src/**/inc With --enable-pch=full there's not much difference between a "public" header in <module>/inc and a private one in <module>/src/somewhere/inc . And since the script searches recursively, this apparently helps to find even more headers for lower pch levels. [ Just the pdfium part. ] (cherry picked from commit 69e0d871ec1de2260f9213d3113464155eac173c) This is the commit message #5: external: update pdfium to 4083 (cherry picked from commit 9054c36d4ea3bee25fb9a47a96a0ea2cd07148c3) This is the commit message #6: external: update pdfium to 4137 Conflicts: svx/source/svdraw/svdpdf.cxx (cherry picked from commit 1ffe59ef31186e36ad0aa7bbcdd32e407ee8d26c) Change-Id: Ib7c12461e04fa97bf55ee967e8d6c9bcf92fdf4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102439 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-19Add test for preserving page number when suappingTomaž Vajngerl
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100838 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit bda18edf18f30cabb1c6589c59afc77f38541220) Change-Id: I1a7028d1768d0098aabbbc519d1b7936ddfc4a48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100885 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-08-19vcl: save and load the page number when swapping the graphicTomaž Vajngerl
PDF vector graphic includes a page number, of the page that the graphic is rendering. This however isn't remembered when swapping out and back in the graphic, because the serialization format doesn't include it. This adds a version 2 of the serialization format, with an additional page number (page index) attribute. Also changes the GraphicTest to account for an additional 4 bytes written and the change of the checksum. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100836 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 28beaffba6a0ecaf351c84bed41443a6721d85b6) Change-Id: Ic0fbfc4ad983f7880e06956da3b4664bd4b610d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100883 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-08-19do not hardcode a BitmapChecksum in a testLuboš Luňák
The checksum depends on this like RGB vs BGR and changing the VCL backend to e.g. Skia breaks this. Change-Id: I5bb3f4c009327c92683bfa575bd1510e3a1ea826 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94224 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 88aeadd97e3aa8146e88912fa06d65743a36ead3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100882 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-19Test swapping of GraphicTomaž Vajngerl
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92920 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 287e39d363012788bf1f5bdb94fdebd370e8763d) Change-Id: I895002aa31380d2b5bc2593e66080f3fc94034e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100881 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-29pdf: add text page object attribs, refactor ImpSdrPdfImport, testsTomaž Vajngerl
This refactors ImpSdrPdfImport to push more functions into the PDFium wrapper. The focus is on text page object attributes. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97366 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 4e9b03d04f740a0cbafa22a4f3cedfae7f37a994) Change-Id: Ie1faf5e3743eec7c77050835651533f9e227c2a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97451 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-29pdf: add PDFiumTextPage and PDFiumPageObject + testTomaž Vajngerl
Also use it in ImpSdrPdfImport. Change-Id: I6d353ef60d036c3516448e64a50b25a9befd5db8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97364 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 440cb3fb80d9fd356871eac410b9797f23433722) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97449 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-06-29support date and time for PDFium and use it for annotationsTomaž Vajngerl
PDF annotations have the modification date and time accessible in the PDF specific format. With PDFium we read the annotation date and time and convert that to css::utils::DateTime (by converting to ISO8601 compatible string first). Add support for modification date and tme for annotations into ImportPDFUnloaded and when the annotations are inserted into the document as comments (in Draw document). Change-Id: I24aacde84b7530365d67ed335b1eefbaee706eca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96759 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 4e3196ceedc2b79d58bb57dba86f2f0158d32998) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97440 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-06-29vcl: Add annotation reading to PDFiumLibrary c++ wrapperTomaž Vajngerl
Also add tests readin annotations from Evince and Acrobat modified PDF files. Change-Id: I4565c6b621774fc8485a6c33bc18708664917b73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96756 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 7e4dc3b1eabcb1993d4143c046a2f32fedc852ed) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97438 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-06-29vcl: wrap PDFium types in c++ classes to ease lifecycle managementTomaž Vajngerl
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96753 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 526b09604399a71c17b15ee80bab48967563bfb6) Change-Id: Idd33dfe752a22b6628750c06f02e9467a69802bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97435 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-29sd signature line: place shape on the correct pageMiklos Vajna
PDFDocument::Sign() had this hardcoded to always place the signature widget on the first page, add a way so that xmlsecurity/ can tell the pdf signing code to put it on an other page. This way in case the user created the signature line shape on the Nth page, it'll end up on the Nth page of the PDF result as well, as expected. (cherry picked from commit 022f6bb1f7ed06edb126a2b85719d8622104bb57) Conflicts: vcl/Module_vcl.mk Change-Id: I63decba98774151e9634ea924c2fed0f7814cb28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97256 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-10sd: support match case, match whole word for PDF searchTomaž Vajngerl
THis adds support for match case and match whole word to the VectorGraphicSearch + tests. It uses the new options in PDF seearch in Draw/Impress. Change-Id: I20a6382c22bf01a5a021c8bae1ff78861419c0ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95530 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 112d8113388513d9c6b317e828f5d373b4a54330) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95950 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-06-10vcl: disable VectorGraphicSearchTest if we don't have PDFiumTomaž Vajngerl
enclose with HAVE_FEATURE_PDFIUM Change-Id: I46f8d6b19c46dbdf313b6192dddf85741ceb301f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95462 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit e848e95faa5cea1f258c9f97d99ffc91614e5a3b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95948 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-06-09vcl: VectorGraphicSearch - support changing search stringTomaž Vajngerl
Initial implementation only allowed to set the search string once. This change allows to change the search string and still retain the last position of a found string, so the search continues from this positon forward or backwards. This mimicks how we search through the GUI (which is the main use for this functionallity anyway). Change-Id: I8a7aee4b6b6525f483f105feaa1f83c4a0ad9594 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95460 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 1f8a46ae50c6977add4c4116f114df3a58796be3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95946 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-06-09pdfium: only init pdfium library one and destroy on LO exitTomaž Vajngerl
With more and more usage of PDFium, it is hard to keep track of the life-time of the PDFium library, so it can happen that a FPDF_DestroyLibrary happens when we still have another instance where PDFium is still use. The result of this is a crash. To prevent this, just initialize the library once and delete, when on LO exit. This can be improved in the future to only keep the library active when in actual use. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95391 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 067a8a954c8e1d8d6465a4ab5fb61e93f16c26c2) Change-Id: I5c7e5de7f8b97d10efb394c67c7a61b976c8d57c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95933 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-09vcl: add search start position support for VectorGraphicSearchTomaž Vajngerl
By default we start at the begin of the page, but with this change make it possible to start at the end. This makes it possible to search in the backwards direction (set the start position at to the end and search with "previous"). Change-Id: I78fb1461b86bf9eab2f91c3b9a81cbb5c6557332 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95382 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 83d27791fed75941c75d3cc571c3d5cf27d14e8c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95930 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-09vcl: add "previous" search to VectorGraphicSearchTomaž Vajngerl
Previous moves backwards in the search matches. Change-Id: I88d402e0b8cb9dc4fd93e7f1ce5b08fb42aadd06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95381 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit e20440effc7a47c8a5e8ef0943e6872cd9b3646a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95929 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-09vcl: VectorGraphicSearch return text rectangles in 100th mmTomaž Vajngerl
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95261 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 936a670f61fed891f8aaec77b2422f366240f193) Change-Id: I12e7ad10dc3ed68d20d94713acece1361da27e81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95834 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-09vcl: VectorGraphicSearch - add search result selection rectanglesTomaž Vajngerl
Change-Id: Ia0c5610f600719bcfb5de503f3876fc896cb630a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95256 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 4062b3f87689e48fd250d9cf0297a24b5427bf59) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95833
2020-06-08vcl: VectorGraphicSearch - for searching text inside PDFTomaž Vajngerl
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95254 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit efba780d6155317b592b6f5f73945a7851ec4d3b) Change-Id: Iee940a3927330c8739774ff3c1af15998f89193b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95801 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-07test import and export of multi-page PDF with PDFium filterTomaž Vajngerl
The test checks that the exported PDFs contain embedded PDF for different pages. Change-Id: I4e5cd108d8597851d86aa774efbde0d4f2b9d2ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93322 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95701 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2020-05-17widget theme: add additional settings to the theme definitionTomaž Vajngerl
Change-Id: Ib50ebadf73979068d3595f09de113aa8745eccb9 Reviewed-on: https://gerrit.libreoffice.org/83591 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-05-17widget theme: add centeredTabs setting to theme definition fileTomaž Vajngerl
Change-Id: I714a44d40a99e0bb5ff48e3d36ded73db60af5a0 Reviewed-on: https://gerrit.libreoffice.org/83133 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-05-17pdfexport: improved detection of failure to print with --disable-guiAshod Nakashian
PDF printing tests cannot run when we don't have the proper support enabled, so we need to detect those cases and avoid failing the test unnecessarily. Change-Id: Ia602dbb5c3d16c082a8ff6e707db90501bb5453c Reviewed-on: https://gerrit.libreoffice.org/78610 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/82168 Tested-by: Jenkins
2020-05-05Change default PDF version to 1.6 (released in 2004)Miklos Vajna
We already write markup which is newer than 1.5, but the PDF version was not changed. Fix the one violation I'm aware of. Printing is left unchanged, similar to how commit 99ac4ee05b039166eedfe361fb985682fd92dd13 (Change default PDF version to 1.5, 2018-04-24) updated the default last time. (cherry picked from commit 141e0449fdab89384564659191492b698e4b13d8) Conflicts: filter/source/pdf/pdfexport.cxx include/vcl/pdfwriter.hxx Change-Id: I9598dc46fe7db428bd2eff98bebff8b3c873b4ff
2020-05-05PDF export: fix handling of page sizes larger than 508 cmMiklos Vajna
The value of these coordinates are not allowed to be larger than 14 400, and Adobe Reader complains about them. Use UserUnit to declare in case we won't work with points anymore, but with a larger unit. This will mean UserUnit=2 in practice, since e.g. Draw has is page size limited to 600x600cm, so larger values won't happen, at least not for now. (cherry picked from commit 4830592b780833cf5eee2aef30bc9c5d444dfb24) Conflicts: vcl/source/gdi/pdfwriter_impl.cxx vcl/source/gdi/pdfwriter_impl.hxx Change-Id: I8ee159f2571f4070aded85388792a215de86f7ff
2020-03-21tdf#61274 sd PDF export: fix links ending up on wrong pages with hidden slidesMiklos Vajna
SdPage::IsExcluded() decides if a slide is hidden, SdXImpressDocument::render() checks for this and returns early if needed. In that case PDFExport::ExportSelection() detects that the produced metafile has no actions and avoids creating a PDF page. Then Impress links are created using the vcl::PDFExtOutDevData::CreateLink() call in drawinglayer::processor2d::VclMetafileProcessor2D::processTextHierarchyFieldPrimitive2D(), not specifying the PDF page number explicitly. This means the link is created on the "current" page number, set in vcl::PDFExtOutDevData::SetCurrentPageNumber(), called by PDFExport::ExportSelection(), but that filter/ code can't know about hidden slides in sd/. Fix the problem by setting the page number again in SdXImpressDocument::render(), that way the link created by drawinglayer will end on the correct page. (cherry picked from commit 01dbb38680aa39a4d3bc7afd05d44a4b2c9bc6ab) Conflicts: vcl/qa/cppunit/pdfexport/pdfexport.cxx Change-Id: Ic29e345d45bc7c944d65e6e450f1d742dd0e9f8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90551 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-03-17tdf#130150 Improve clipping in PDF exportArmin.Le.Grand (CIB)
For more info and discusson please have a look at the task. It reverts the change from tdf#99680 which did a wrong paradigm change in how clip in Region(s) is defined and tries to fix the underlying error in a more correct way. This includes problems noted in tdf#44388 and tdf#113449. This is a decent improvement, but - due to dealing with numerical problems - not yet the whole healing. Still thinking about how to solve this for good. Adapted PdfExportTest::testTdf99680() and PdfExportTest::testTdf99680_2() as needed, empty clip regions are allowed again. Added comments, too. Had to change solvePolygonOperationAnd to work on ranges if both inputs *are* ranges. The AND-case is then completely solvable. Also increased geometry for transformations of clip geometries - may help later. Change-Id: I2370447597faa6efb81d58ee31c63654e304262e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89874 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 6dff631f8f4b964b48aadde52a1e1b8b04b9ba53) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89923 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-06tdf#129976 PDF export of PDF images: adapt transparency to renderingMiklos Vajna
The bugdoc has a transparent PDF image, and we currently put a white background behind that in Impress, given that vcl::RenderPDFBitmaps() works with Bitmap instances, not BitmapEx ones. This means that in case we preserve transparency during PDF export, the content that was rendered OK now becomes unreadable. Adapt the PDF export to do the same as rendering by putting a white background behind the PDF image. (cherry picked from commit 7088140dbf1d5e0391c2662f0213018a45620ff9) Change-Id: I4edcb12fab71bb305d97a50d20fbfbf86d9aab85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87956 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-31Adapt CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)Stephan Bergmann
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t backward compatibility remediation", as implemented now by <https://gcc.gnu.org/ git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++: P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads that would print an integer rather than a (presumably expected) character. But for simplicity (and to avoid issues with non-printing characters), keep printing an integer here. Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7 Reviewed-on: https://gerrit.libreoffice.org/84348 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 5d8f0fad50f90195a11873c70ddab4644f5839ea) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87760 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-01-06tdf#129662 vcl: rtl: fix scrollbar in dropdownsMiklos Vajna
Regression from commit d4714b0fdb81e6e561ae526cc517ecc9a40a603e (tdf#101978 vcl combobox/listbox floating window: avoid flicker, 2019-06-17). High-level vcl double-buffering never set up RTL status of the virtual device correctly, but now that double-buffering is used at more places, this got noticed. (cherry picked from commit b0fa356eed82a0452e6bcb915f179f5e2d02943a) Conflicts: vcl/source/window/cursor.cxx Change-Id: Iba378cef3a693b0712389fab519f38ee222577d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86158 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-12-21tdf#127022 vcl: fix Windows RTL menu barMiklos Vajna
Regression from commit e8d5b8beb5958147235ff955ed38c47b51d860ff (tdf#113714 vcl menu bar window: avoid flicker, 2019-05-20), the problem was that while the original render context has RTL set up correctly, the intermediate virtual device had it disabled all the time. Change-Id: Ic063c4a6c0537891c0bfceb8927edb97cf1c6e86 Reviewed-on: https://gerrit.libreoffice.org/85624 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins Reviewed-on: https://gerrit.libreoffice.org/85636 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-26tdf#128629 vcl DrawTransformedBitmapEx: do scaling for flipped bitmapsMiklos Vajna
Regression from commit dd4a67084853a030bf4b9f1f85d728620e0604a5 (vcl: avoid downscale && upscale in DrawTransformedBitmapEx(), 2019-10-08), the original problem to be solved was that in case you downscale a bitmap and upscale it later, then you get blurry result, so we try to avoid touching the pixels and just scale during rendering of the bitmap. However, here the problem is that scaling is also (mis)used for flip purposes, so go back to the original behavior for negative scaling. This keeps the original problem fixed and solves the loss of flip as well. (cherry picked from commit 8dde8f9768f0dab97cdd30e3116f7e4d737c482f) Change-Id: Ic9a6eb49d55f2fb8ccf18d982e574398f010cabd Reviewed-on: https://gerrit.libreoffice.org/83732 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-19tdf#128632 vcl image lazy-load: take unit into account when setting sizeMiklos Vajna
It makes no sense to set the size of an image based on the swap info when the swap info unit and the actually loaded image's unit doesn't match. Converting the size would be also an option, but let's wait for the first case when a custom size is actually needed for mismatching units. (cherry picked from commit 0098563895f6a4024b400582d1bf93cb4435ceed) Change-Id: I96b5c237f0be5587bb2f938faf3c69fa0e1d4a5c Reviewed-on: https://gerrit.libreoffice.org/83160 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-18tdf#128847 - vcl: fix colorspace names for MacOSChris Sherlock
kCGColorSpaceGenericGray is deprecated and should be kCGColorSpaceGenericGrayGamma2_2, and kCGColorSpaceGenericRGB is similary deprecated and now should be kCGColorSpaceSRGB. This fixes the "color skew" issue found in a variety of tests. Change-Id: I8088b2377e03cde3f8e03e9d3778a40fc3081c4a Reviewed-on: https://gerrit.libreoffice.org/82809 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 3a8d16ba8ca7ef7349e893f2bf1c7e12d9a8d7ae) Reviewed-on: https://gerrit.libreoffice.org/83081 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-11-12tdf#128630 vcl PDF export: fix aspect ratio when scaling rotated imageMiklos Vajna
Regression from commit 68549e00d5e23aa22bc974a8151d93cd948444b3 (vcl, BitmapEx transformed draw: special-case simple rotations, 2019-10-10), the intention there was to fix an error on the last col/row of a bitmap, but that was only tested with input where the aspect ratio doesn't change on scaling. Fix the problem by going back to the original way in the "aspect ratio changes" case. Change-Id: I52bed503ddaadbbbdf64ac6fec2fe268153866f1 Reviewed-on: https://gerrit.libreoffice.org/82467 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-06vcl PDF export: fix re-exporting PDF images with page-level rotationMiklos Vajna
PDF images are effectively 1 page PDF documents. The page object may have a /Rotate key, which was simply ignored before. We turn page objects into form XObjects on PDF export, such rotation can be expressed with a /Matrix key. Add support for the 90 degrees rotation case, this can be generalized later if wanted. Change-Id: I55a4f63e0b986637ccdeba0b783f1db9a85c4d93 Reviewed-on: https://gerrit.libreoffice.org/82154 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-05vcl PDF export: fix re-exporting PDF images for dict obj resource sub-keysMiklos Vajna
Re-exporting PDF images works by tokenizing the PDF image, identifying which PDF object is the page object and then copying that over to the PDF output, together with the dependencies of that object. This involves copying the resources of the page object. Previously we assumed that the sub-keys of the resources are always inline dictionaries, but the bugdoc shows that they can be references as well, which point to dictionary objects, so add support for this scenario. Change-Id: I78ee1c726e6ecd958232e9fab64773595e5b9c86 Reviewed-on: https://gerrit.libreoffice.org/82076 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins