Description: Exporting Image or Drawing to PNG doesn't insert DPI resolution with Skia (previously OpenGL). Working with GDI Steps to Reproduce: 1. Open attachment 168385 [details] 2. Select the shape 3. File -> Export 4. Pick PNG and enter a file name 5. Set DPI to 222 cm/or inch (does not matter) 6. Export 7. Open the file with Gimp or another image viewer.. notice dpi missing Actual Results: No dpi inside the file (also not totally sure about the resolution) Expected Results: Should be the case Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: 315c7570c4a72f4c834086082825533b1e50d1bf CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 168409 [details] Bibisect log Bisected to: author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2019-02-15 13:14:32 +0100 committer Tomaž Vajngerl <quikee@gmail.com> 2019-04-03 11:57:08 +0200 commit 86ea64f216819696cd86d1926aff0a138ace2baf (patch) tree db513803abc9dc255d27c0f08cba6d6d0c9ef1d9 parent 994b41a6c69d20637dcb95894c385f5c0102d600 (diff) Support for native 32bit Bitmap in VCL and SVP (cairo) backend This adds basic support for 32bit bitmaps for the SVP backend. For other backends the support is disabled for now as we need to add it for each backend separately and enable support. When this patch is applied it is possible to a Bitmap with bit count 32, but currently no input filter uses this with the exception of the new PngImageReader(libpng based), which is used only for the icons. For a general support more things need to be implemented and tested: - conversion back and fourth between 32-bit and 24-bit + 8bit alpha (or other supported pairs) - 'raw' export of the bitmap needs to be handeled properly (like in SVM import/export) so it creates the correct image. - input filters need to be checked and converted if this is necessary - look for possible bugs when drawing transparent bitmaps - check of UNO API https://cgit.freedesktop.org/libreoffice/core/commit/?id=86ea64f216819696cd86d1926aff0a138ace2baf -> This is only about lacking dpi. The resolution is a mess too. Should be somewhere in the close area of the identified commit here
Conformation of this can be found in bug 132959. Setting to NEW
Adding CC: to Tomaž Vajngerl
@MWT I think lots of issue are coming from here.. Compare Export results from Master with 6.2 (running OpenGL). I think it's also relevant for transparency topic [but not sure of course]
Not Skia specific, using KF5 and Gtk3 backends has the same problem. *** This bug has been marked as a duplicate of bug 132959 ***
Setting this 6.3 regression back to New to keep it separate from the older issue in bug 132959. For the record, I followed a similar process as Teleto, on Linux and with Draw: Steps: 1. Open attachment 168385 [details] 2. File > Export > as PNG, make sure it uses 96 DPI 3. Open file in GIMP, look at metadata in Image > Image Properties Alternatively, with command line: 1. convert the file: instdir/program/soffice --headless --convert-to png star.odg 2. Use ImageMagick's command line tool "identify" to see missing metadata: identify -verbose star.png | head -10 Results: Resolution is at 72 ppi. Resolution, print size and units are missing from identify output. Expected: 96 ppi and useful metadata. Present in recent master buid at 24.2 alpha as well as 6.3.6.2. Not in 6.2.0.3, so it's a regression. Bibisected with linux-64-6.3 bibisect repo to first bad commit e36ad95ea54fcef5b6b97de27a7e8843b78b9e1b which points to core commit: commit 86ea64f216819696cd86d1926aff0a138ace2baf author Tomaž Vajngerl Fri Feb 15 13:14:32 2019 +0100 committer Tomaž Vajngerl Wed Apr 03 11:57:08 2019 +0200 Support for native 32bit Bitmap in VCL and SVP (cairo) backend Reviewed-on: https://gerrit.libreoffice.org/69289 Tomaž, can you please have a look?