summaryrefslogtreecommitdiff
path: root/vcl/source/pdf
AgeCommit message (Collapse)Author
2024-08-15Update pdfium to 6656Miklos Vajna
Drop external/pdfium/annot.patch.1, it has been upstreamed as <https://pdfium-review.googlesource.com/c/pdfium/+/120750>. Update PDFiumPageObjectImpl::getFontName() to match <https://pdfium-review.googlesource.com/c/pdfium/+/121911> "Rename FPDFFont_GetFontName() to FPDFFont_GetFamilyName()". Extend external/pdfium/build.patch.1 to work around: > C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/workdir/UnpackedTarball/pdfium/fpdfsdk/fpdf_annot.cpp(1083): fatal error C1001: Internal compiler error. Change-Id: I94ed21265a79d484759f240f3baeb51c92365c78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171884 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-06-28Related: tdf#161708 sw content controls: fix custom default of dropdown to PDFMiklos Vajna
Export the bugdoc to PDF without noticing that there is a content control around some of the content and notice how the PDF export lacks some words from the body text. What happens is that content controls are exported to PDF as PDF forms by default, and the selected option of a dropdown has to be an index, so in case the text of the dropdown content control is not one of the options, then the PDF will miss those words. Fix the problem by inserting the text of the dropdown at the start if there would be no valid index for it. Also add a bit of padding around the rectangle of the content controls, it turns out there is a default 1pt border in PDF, and this would lead to a cut-off text at the end if we don't compensate for that border. Change-Id: I99447894b320b42ad9ffe0d54d0190000621616b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169694 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-06-21tdf#161708 sw content controls: handle font color when exporting to PDF formMiklos Vajna
Export the bugdoc to PDF, the orange "date" lost its font color. This went wrong in commit 82d90529dc2b3cb8359dec78852cbd910a66d275 (sw content controls, rich text: add initial PDF export, 2022-09-12), we export the content control as a PDF form widget by default since then. Various properties like checkbox status and dropdown items were handled already, but not text color. Fix the problem by mapping the SwFont color to the widget descriptor color, this fixes the color of the already filled in content of the widget. Note that given this is a property of the form widget, the color is correctly applied also to strings filled in via PDF readers, interacting with the form. Change-Id: Id3e8611e415c0d571afe1cd14561c97b8a910ce9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169317 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-06-14annot: make sure the annotation subtypes in PDFium match with oursTomaž Vajngerl
Change-Id: Ic18f394b532118f39988a650d046880b049c9ec3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168810 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-06-14annot: add support to import Stamp annotation from PDFTomaž Vajngerl
Stamp annotation shows an arbitrary bitmap in the document, where the most common bitmaps are stamps like "Approved", "Confidential", "Expired", "Sold",... Change-Id: I332e34cbb346a686ee16eac7ca437ec4048e65ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168760 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-05-10loplugin:ostr in vclNoel Grandin
Change-Id: I5b6ee5bda0c5ff69d297f7f8e87d4c3f3d21791c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167470 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-01-23tdf#138792: PDF export: export metadata dc:dateSarper Akdemir
Dublin Core attribute dc:date wasn't exported so far in the current implementation. Looking at the information pointed by http://purl.org/dc/elements/1.1/date, dc:date is a vaguely defined field. Now creation date is exported there, as I've came across the note of "Typically, Date will be associated with the creation or availability of the resource" in the resource linked below. https://www.dublincore.org/specifications/dublin-core/dcmi-terms/2005-06-13/#:~:text=Typically%2C%20Date%20will%20be%20associated%20with%20the%20creation%20or%20availability%20of%20the%20resource Change-Id: I0b5f37058f64e3d6d08cb46045a27ccde54ee434 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162404 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-12-13Work around strange error seen at least with VS 2022 Preview 17.9.0 Preview 2.0Stephan Bergmann
> vcl/source/pdf/XmpMetadata.cxx(39): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'rtl::OStringLiteral<55>' > vcl/source/pdf/XmpMetadata.cxx(39): note: Invalid aggregate initialization > vcl/source/pdf/XmpMetadata.cxx(39): note: too many initializers (Smells like a bug in that compiler's u8"..." handling, where it maybe gets tripped by the 3-byte UTF-8 encoding of \uFEFF?) Change-Id: I1c6a856a67c8328ed5fcc2f2fa6bb26f16319f55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160681 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-07simplify and modernise ScopedBitmapAccessNoel Grandin
(*) Make all of it use a "Scoped" paradigm (*) pass by value, no need to allocate on heap (*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods. (*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places. Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-19Extended loplugin:ostr: vclStephan Bergmann
Change-Id: I2a9d5383d1831d8bf61e5280d66556d71fccae52 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159666 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-18tdf#157517 vcl: PDF/UA export: add PDF/A extension schema to XMPMichael Stahl
... if PDF/A is also enabled. Thanks to Peter Wyatt for the example document. Change-Id: I2a5951e102ae28a4c998adafe8ab51caa2788e4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158118 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-09-04tdf#138792: PDF export: export metadata dc:formatSarper Akdemir
Export application/pdf MIMEType in dc:format Change-Id: I7cb658c869898df3a9436937329b4082843338bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156507 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-09-04tdf#138792: PDF export: add batch of dublin core attributesSarper Akdemir
Adds support for exporting, editing in the UI and storage in ODF for the dublin core attributes listed below. Contributor (http://purl.org/dc/elements/1.1/contributor) Coverage (http://purl.org/dc/elements/1.1/coverage) Identifier (http://purl.org/dc/elements/1.1/identifier) Publisher (http://purl.org/dc/elements/1.1/publisher) Relation (http://purl.org/dc/elements/1.1/relation) Rights (http://purl.org/dc/elements/1.1/rights) Source (http://purl.org/dc/elements/1.1/source) Type (http://purl.org/dc/elements/1.1/type) Introduces XDocumentProperties2 to extend XDocumentProperties interface. Change-Id: Ie2e0b1fbbbd00b66aef477ba1bf4e4f61c03a3b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156330 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-09-04tdf#138792: PDF export: export metadata pdf:PDFVersionSarper Akdemir
Adds export of pdf:PDFVersion metadata. Change-Id: Ic4c3eec3672839d0d125b64dfca6149912cd2458 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156329 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-09-04tdf#138792: PDF export: export metadata xmp:ModifyDate, xmp:MetadataDateSarper Akdemir
Export metadata xmp:ModifyDate & xmp:MetadataDate - populate both with the same information as CreateDate. Change-Id: I391a72cbe4e7d1ebba5c04c402a68534bbeb4743 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156328 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-07-23vcl: Drop now unneeded DevicePoint typedefKhaled Hosny
It has been always typedef'd to basegfx::B2DPoint since: commit 5e218b5c51f7d9cd10bd9db832879efca41b9c75 Date: Wed Jan 12 21:19:32 2022 +0000 always use B2DPoint for DevicePoint Change-Id: I9f5202d5a71c77dd79f1759923917c26bf68a9af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154632 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-07-07tdf#153472 vcl: PDF/A export: produce valid XMP metadataMichael Stahl
* historically the PDF export claimed to produce PDF/A-1a, which was removed from the UI in commit ed4a0eed82e2f29e8163a445db992d22c6d07134 "tdf#62728 add PDF/A-2 support, change UI default to use that", and then reintroduced, presumably intentionally changed, as PDF/A-1b in commit 49cfcf777d03abf59557cad021b4e5c4445de3c0 "tdf#62728 Provide both A/1 and A/2 in PDF export dialog" Adapt the XMP metadata to always write "B". * if PDF/UA is enabled, veraPDF complains about the added pdfuaid:part: Specification: ISO 19005-2:2011, Clause: 6.6.2.3, Test number: 7 All properties specified in XMP form shall use either the predefined schemas defined in the XMP Specification, ISO 19005-1 or this part of ISO 19005, or any extension schemas that comply with 6.6.2.3.2. Change-Id: I77b9fb728476e85830e3771135ac5a269e96b306 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154169 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-06-30tdf#156084: Fix PDF export of bitmap color fontsKhaled Hosny
A regression from the commit below caused the resources dictionary of the Type 3 font to be omitted making the images inaccessible: commit 845fbfcce9091e541bab657163b026aad8648261 Author: Khaled Hosny <khaled@libreoffice.org> Date: Thu Jun 15 06:27:38 2023 +0300 Don’t add empty Fonts dictionary to Type 3 font resources Change-Id: I479ca328bd1b1228ba722678d3d9686c8456b350 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153780 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-06-08pdfium: better suport for annotations and some fixesJaume Pujantell
Added suport to import FreeText annotations. Added some suport to export graphical annotations. Fixed some color issues to be more inline with the pdfium library. Change-Id: I7371595ebb95594ee765ae532ca7c7d4f0499592 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152606 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2023-01-20tdf#153047 sw: fix PDF export of content controls in placeholder modeMiklos Vajna
Importing an inline content control from DOCX used to be just plain text in Writer, so the PDF export of that was also just plain text. Now that content controls are actually supported, we used to not emit them as plain text in the PDF export, since 82d90529dc2b3cb8359dec78852cbd910a66d275 (sw content controls, rich text: add initial PDF export, 2022-09-12). Part of this was to write the string value of the content control as the /V (value) key of the form, when it's not in placeholder mode. This made sure that once the form is filled in, no overlap between the plain text and the filled in text happens. Try to support both use-cases at the same time by also mapping the value of the content control to /V, even if it's in placeholder mode. This keeps avoiding the unwanted overlap, but this way the placeholder text is no longer lost on PDF export. An alternative would have been to map the placeholder text to description when the alias/title is empty, but that would show up only as a mouse tooltip, so won't change the behavior when the PDF is printed. Change-Id: I9408b5abe36af28cd00845a74a3dfff13973b83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145828 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-25pdfium: reduce size if cannot create bitmapSzymon Kłos
In files with large pages it was rendering white, empty content. That was because bitmap creation in the PDFium failed. This reduces the size to possible value. Signed-off-by: Szymon Kłos <szymon.klos@collabora.com> Change-Id: I093a6aff94104cdc8223d7b8cbc00ff9217021b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143037 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143243 Tested-by: Jenkins
2022-11-16sw content controls, date: improve PDF export testMiklos Vajna
Assert not only that the widget is a text one, but also that it has the correct date format. Change-Id: If2bb8dcdfca0a8b76b5ed179ff558d351137bc06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142747 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-10-06pdfium: drop not needed annot.patch.1Miklos Vajna
If FORM_OnAfterLoadPage() is called, then FPDFAnnot_GetFontSize() can do what we need. Change-Id: I8aa3acbbda5c040f30b28db36f8b3332115b50e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140997 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-09-23sw content controls, combo box: add PDF exportMiklos Vajna
Map it to vcl::PDFWriter::ComboBoxWidget, which knows that this has list items + allows free-form user input as well. PDF 32000-1:2008 Table 230 documents those field flag bits. Change-Id: Ifb99625c2ab8792b756ad52a3f6d599507c5773f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140480 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-09-21use more string_view in vclNoel Grandin
Change-Id: I66f96a305bb095716023ae1e565950971826bce0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140242 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-20sw content controls: add a11y description for PDF exportMiklos Vajna
Acrobat Reader shows these descriptions on mouse hovering on a form widget. Change-Id: I8614222e46c992baca8a57b13a948f88973e8911 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140215 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-09-16sw content controls: add PDF export of font propertiesMiklos Vajna
Like font name or size. Change-Id: Ie7b0d38be0ef69faf364b7c801d0bd3fdd60777a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140038 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-09-13sw content controls, checkbox: add PDF exportMiklos Vajna
Map this to vcl::PDFWriter::CheckBoxWidget, which uses the /FT/Btn widget, i.e. a (toggle) button which is not a pushbutton or a radiobutton). Also avoid a border for content controls: it just cuts out some part of the rich text/plain text content control filled in text + causes a double border for checkboxes, so not useful. Change-Id: If8dd63fe71d7c2ba9bea4bf2ecc6621fefb74fd6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139864 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-25use DevicePoint and SubPixelToLogic to return to source coord systemCaolán McNamara
Change-Id: I1aeae6270feb6cb0a44b7850e1b3143e68ae780f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138770 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-07-20tdf#127236 vcl: fix missing encryption of PDF images during exportMiklos Vajna
Regression from commit 78e25558e86188314b9b72048b8ddca18697cb86 (tdf#106059 PDF export: create a reference XObject for JPG images with PDF data, 2017-02-23), once a PDF image was inserted to a document, an encrypted PDF export lost those images. The reason for this is that we started to preserve PDF images as vector data with the above commit, but this means we copied over PDF objects from PDF images to the export result as-is, so encryption was not performed for them. Fix this by separating the write of the PDF object headers, stream content and object footer and then calling checkAndEnableStreamEncryption() / disableStreamEncryption() for each object, even if it's not something our PDF export created but comes from a PDF image. Note that when existing PDF files are signed, PDF objects are also copied into a vcl::filter::PDFDocument, but such PDF images are never encrypted, so it's fine to have stub implementations in vcl::filter::PDFDocument. Change-Id: I2f74b9f51cd35b4319221532ca890e197bab9cf3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137242 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-05-01use more string_view in variousNoel Grandin
found by examining uses of OUString::copy() for likely places Change-Id: I6ff20e7b273ad6005410b82719183c1122f8c018 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133617 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-08move comphelper::string::toInt32 to o3tlNoel Grandin
so we can use it in places where we cannot include comphelper Change-Id: Iba0ba3e4c0dcf0f9d1f09092a77c3b2010ec4f6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132732 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-08use more subView when converting to Int32Noel Grandin
Change-Id: I54e3ddf79ba793fd4328bf8bda7f949b65349651 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132693 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-02-03Make inserted or pasted PDF sharper on macOSTor Lillqvist
When inserting a PDF file as an image or pasting PDF data from the clipboard on a Retina iMac the resulting rendered image did not look sharp. Using a surprisingly large extra scaling factor helps. The exact reasons for this are unknown. It isn't enough to use a scaling factor of just 2 (which is the HiDI ("Retina") scale factor on my iMac). Possibly the fuzziness is related to what Pdfium uses to render text. Also, look at CountDPIScaleFactor() in vcl/source/window/window.cxx. The GetDPIScaleFactor() function lies on macOS even more than it does on other platforms. It claims that the DPI scale percentage is always 100. But in fact most Macs nowadays have a Retina display so it would make more sense, in theory, to at least always return 200 instead. That wouldn't be any more wrong. But that causes regressions in the UI rendering, like needlessly large icons in the toolbars. Change-Id: Idc694f742c4ac32a5a134f8d206cf4eee467c39a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129369 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-11-12external: update pdfium to 4699Miklos Vajna
Change-Id: I545adce0491e48fad2bfc4003695bd96cc911f22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125068 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-09-23external: update pdfium to 4643Miklos Vajna
Change-Id: I4e86b163a9abef88f26c6c0ae91ae0a4008658f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122485 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-09-07Avoid repeating the return type from the declarationMiklos Vajna
Change-Id: I0dce02d10b8c74e80f5672e2dd580b6837ba3291 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121732 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-08-27Take the PDF graphic rendering DPI into account when exportingTomaž Vajngerl
Change-Id: I1d3465fc7357e6991161d5a96bcd70c53c55f244 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121087 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-08-04Remove harmful static_cast<int>Stephan Bergmann
...that were present ever since the code's introduction in 1ced26e19d769e2ac6ca83f57f82cddbd2cfd061 "INTEGRATION: CWS vcl15", but cause `instdir/program/soffice --headless --convert-to pdf` of doc/abi11923-2.doc from the crash-testing corpus to fail under UBSan with > vcl/source/pdf/Matrix3.cxx:30:35: runtime error: 2.14749e+09 is outside the range of representable values of type 'int' > #0 in vcl::pdf::Matrix3::transform(Point const&) const at vcl/source/pdf/Matrix3.cxx:30:35 (instdir/program/libvcllo.so +0x94098c5) [...] Change-Id: I3855027effa09c592345a9c85a9d5dee38d7c992 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119955 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-14external: update pdfium to 4568Miklos Vajna
Change-Id: I2bfd5f806281e747702d423b7e59b5f88a7bea9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118868 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-06-18Simplify a std::string_view constructionStephan Bergmann
...and combine three calls to SvStream::WriteOString into one. Despite its name, SvStream::WriteOString takes a std::string_view, but which cannot be constructed from a u8"..." char8_t string literal. Besides the OStringLiteral detour, other fixes could have been a reinterpret_cast<char const *> (but which would have defeated constexpr'ness of the std::string_view construction) or a plain "..." char string literal with the UTF-8 encoding of \uFEFF spelled out as \0xEF\xBB\xBF. Change-Id: I029f061134381a67516cbc4b0479942684c80c20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117461 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-05vcl 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. Change-Id: I2b74d585729305cc1d3a9fefa258d4d76d1bd038 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115122 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-04-01vcl pdfread: clean up not needed HAVE_FEATURE_PDFIUM ifdefsMiklos Vajna
Towards completely avoiding the HAVE_FEATURE_PDFIUM ifdef forest. Change-Id: Ide634f14087ec18e5ab8186be21def0698ddbd5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113428 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-03-13add PixelFormat enum that replaces bit count in Bitmap/BitmapExTomaž Vajngerl
Bit count for the image is a numeric value (sal_uInt16) but only a handful of values make sense - namely 1,4,8,24 and 32. This replaces the numeric value with an enum, which only accepts those values and checks the correct values are used at compile time. Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-02-26pdfium: don't build PDFiumLibrary when PDFium is disabledMiklos Vajna
Rather provide a stub implementation of PDFiumLibrary::get(), so other code can call it unconditionally. This is meant to allow removing the 10 stub functions in VectorGraphicSearch later. Also fix up CppunitTest_xmlsecurity_signing to pass in the disable-pdfium case by avoiding the known-problematic checks. Change-Id: I748fcc5c623c5ce937bd2980bfdfaadbdf6cedf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111564 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-25pdfium: turn the PDFium class into an interfaceMiklos Vajna
This will allow a dummy implementation that only provides PDFiumLibrary::get() and nothing else. Change-Id: Ia63b3f0b7751e5c05716825f0854282e4007207e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111502 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-24pdfium: move PDFiumLibrary::get() impl out of the headerMiklos Vajna
Otherwise vcl::pdf::PDFium can't be turned into an interface. Change-Id: I9e9030e7e7ed36ec1ed777f017c521fa64588e8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111434 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-19pdfium: eliminate FPDF_DOCUMENT from public headerMiklos Vajna
Which means the last pdfium include can go from PDFiumLibrary.hxx. Change-Id: I73e40767f594c9a6ce75582621af975419ccf996 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111163 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-18pdfium: eliminate FPDF_PAGE from public headerMiklos Vajna
Change-Id: I8cfe55b4b23441f7b5c3b748903137a145cc00bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111085 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-17pdfium: eliminate FPDF_SIGNATURE from public headerMiklos Vajna
Change-Id: I9c8297c69ca359d861c8506e41c069692331eb8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111005 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-28 01:50:17 +0000