summaryrefslogtreecommitdiff
path: root/emfio/inc/emfreader.hxx
AgeCommit message (Collapse)Author
2023-03-16tdf#143148: Use pragma once instead of include guardsUday Sharma
Change-Id: I6898acbf7c6c9de45bbfa6a32202acf302f92caa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146822 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-05-22tdf#55007 EMF Allow negatives values for Start Point and End PointBartosz Kosiorek
With previous inplementation, the ARC, ARCTO, CHORD and PIE records were get Start Point and End Point only with positive values. It was causing display issues. This patch fix that according to [MS-EMF] specification Change-Id: Ie1d90a904e840674380b81af0dfe21260374587d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115994 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2020-12-09vcl: improve EMF+ -> WMF conversionMiklos Vajna
We throw away EMF fallback info when parsing EMF+ data. This means that the resulting GDIMetaFile (containing EMF+ data but no EMF fallback) is tricky to export to WMF, where EMF+ comments are not allowed. Improve the conversion result by re-parsing such EMF+ data with EMF+ disabled, and then converting the GDIMetaFile (containing EMF fallback data) to WMF. Change-Id: Ib2c0388f1344aef7f601ce9be59e4a8924e8085b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107453 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-18[API CHANGE] tdf#136836 emfio: set size hint on inner PDF if used as shape fillMiklos Vajna
The bugdoc has a shape, its bitmap fill is an EMF, which is actually a PDF. The PDF is has a height of 5cm, but the shape has a height of 14 cm. Inform vcl::RenderPDFBitmaps() about the size of the shape, so the result won't be blurry. This approach makes sure that we don't unconditionally render at higher resolution, i.e. the "load a PDF of 100 pages into Online" use-case won't use more memory than before. API CHANGE, because the EMF reader is only available via UNO, though it's likely that no actual external code would ever invoke it directly. Change-Id: If1d8def0136d408a31a0cc54777a7f26430a0ff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102996 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-17Fix typoAndrea Gelmini
Change-Id: I7840929712a8e9bd3f46b2c718cf430b97e9b683 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102970 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-09-17tdf#136836 emfio: speed up import of EMF import when the orig PDF is availableMiklos Vajna
The PPTX bugdoc has a 17MB EMF file, which has enough instructions to keep Impress busy for minutes during import. Take advantage of the detail that this EMF has a EMR_COMMENT_MULTIFORMATS record that contains the original PDF, which can be rendered much faster: - old cost: 122.153 seconds - new cost: 1.952 seconds (1.6% of baseline) Change-Id: I38efc1c24e21a7622377b9e1c1938ebee826bae9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102918 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-23emfio: extra loggingChris Sherlock
For emfio I believe we need more logging, so I am gradually adding this. I decided to log the EMR_COMMENT_PUBLIC record subtypes EMR_COMMENT_BEGINGROUP and EMR_COMMENT_ENDGROUP. I honestly don't know what these actually do, but they are specified in [MS-EMF] 2.3.3.4.1 and 2.3.3.4.2. Later on, we will need to look into handling EMR_COMMENT_MULTIFORMATS so we can display things with EPS data. We should also probably look into handling EMR_COMMENT_WINDOWS_METAFILE later on also. Change-Id: I7c3ba3cfd7f51a6cff2c7a47a48dde12240d0382 Reviewed-on: https://gerrit.libreoffice.org/83407 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2017-11-14ofz: stop at min of end of record and end of streamCaolán McNamara
Change-Id: I61c7cf74ea75ec56b6ccb3661f6fdd54a1ff12e1 Reviewed-on: https://gerrit.libreoffice.org/44705 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-26tdf#31814 EMF/EMF+ implement dual modePatrick Jaap
There can be a dual mode flag set in the EMF+ data. If set, we should process either EMF or EMF+ data, because the contained information should be equal (says the documentation). The more advanced EMF+ renderer is chosen here. The flag is read in the EMFPlusReader and blocks the reading of other EMF records than HEADER, EOF and COMMENT. Thanks to Chris, for pointing out the dual mode! Change-Id: I8522930cebbb9e9ecc732397cbb3deea9e8c9127 Reviewed-on: https://gerrit.libreoffice.org/43122 Reviewed-by: Patrick Jaap <patrick.jaap@tu-dresden.de> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> Tested-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2017-10-23loplugin:includeform: emfioStephan Bergmann
Change-Id: Icc71e73fad45d397e17ae4b6ba4967ec7a50ae27
2017-07-15emfplus: reorganized some old filter aspectsArmin Le Grand
Change-Id: I1949e851c560a81a461ec42a992f3b2cb0d019f8
2017-07-15emfplus: add rough version of local readerArmin Le Grand
Complete redevelopent is too expensive, start with adding a copy of the existing vcl importer which will in the next steps be adapted to import primitives instead of MetaFile(Actions). Adapted namespace, made compile and added sample code to roughly use it Change-Id: I79e7ea0d78099fbbe18e2a595457b2ab353f58ea
generated by cgit (git 2.34.1) at 2025-02-08 17:59:01 +0000