New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 801430 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Save As PDF results in a huge asset

Project Member Reported by lushnikov@chromium.org, Jan 12 2018

Issue description

Re-filing issue from Puppeteer repository: https://github.com/GoogleChrome/puppeteer/issues/1177

I verified the issue on Mac OS X Chrome 63.0.3239.132.

Step-by-step:
1. Open https://jsfiddle.net/decoy9697/g6vq3kqf/3/embedded/result
2. Try to "Save as PDF"
3. Inspect file size

Expected: ~5Mb
Actual: 31Mb

Original author claims:

  This is unsurprising in some ways - the single image asset in the sample
  document is 4032 x 5040, I suspect that some upsampling is taking place in
  order to preserve the fidelity of the original? This is reasonable, but I'd
  suggest we a way to configure the PDF renderer with quality setting
  (as per the PNG renderer). If there is such a setting I apologise, I looked
  but did not find it.
 
Labels: Needs-Triage-M63
Cc: halcanary@chromium.org
Cc: sc00335...@techmahindra.com
Labels: -Pri-3 M-65 Triaged-ET OS-Linux OS-Windows Pri-2
Status: Untriaged (was: Unconfirmed)
lushnikov@ Thanks for the issue.

Able to reproduce this issue on Windows 10, Mac OS 10.13.1 an Ubuntu 14.04 using the latest Stable 63.0.3239.132 and Canary 65.0.3319.0 by following the below steps.

1. Launched Chrome and navigated to the above given link.
2. Hit Ctrl+P and saved the page as PDF.
3. Checked the size of the file and it is ~31MB.

This issue is seen from M50 chrome builds.Hence this is a Non-regression issue and marking this as Untriged for further updates from Dev.

Thanks..
Convert your assets from EXIF-JPEG to JFIF-JPEG, then try printing again.

  cd /tmp
  curl https://www.whitehouse.gov/sites/whitehouse.gov/files/images/45/PE%20Color.jpg > orig.jpg
  jpegtran orig.jpg > new.jpg
  printf '<img src="data:image/jpeg;base64,%s" width="300">\n' $(base64 new.jpg | tr -d '\n') > new.html
Labels: Needs-Feedback
Owner: thestig@chromium.org
Status: Assigned (was: Untriaged)
Mac triage: assigning directly to thestig@ - what (if anything) should we do here? Is this WontFix per #4?
For anyone else who runs into this bug report, it looks like JFIF-JPEGs get embedded without being converted to PNGs as long as you use an <img> tag- if you have a div with a background-image set to a JFIF-JPEG, the image will be converted to PNG.
Cc: thestig@chromium.org
Components: Internals>Skia>PDF
Owner: halcanary@chromium.org
Redirecting to Hal. Should websites have to convert the images to some specific sub-format to get smaller sizes? Can SkPDF offer some knobs as originally suggested? If so, we can hook them up in the printing code.
Can a someone give me a function that operates like this?

  sk_sp<SkData> jpegtran(const void* data, size_t len) {
    SkFILEWStream out("/tmp/x.jpg");
    out.write(data, len);
    if (0 != system("jpegtran /tmp/x.jpg > /tmp/y.jpg")) {
        return nullptr;
    }
    auto in = SkData::MakeFromFileName("/tmp/y.jpg");
    return SkData::MakeWithCopy(in->data(), in->size());
  }

but only depends on libjpeg-turbo?
Project Member

Comment 10 by bugdroid1@chromium.org, Apr 7 2018

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/83e0f1b1bb111c99d2f11d382b31caef0af5de10

commit 83e0f1b1bb111c99d2f11d382b31caef0af5de10
Author: Hal Canary <halcanary@google.com>
Date: Sat Apr 07 14:25:30 2018

SkPDF: smarter Jpeg when libjpeg-turbo is present

The fallback code does not parse the color type for EXIF-only jpegs.
Since these exist in the wild, we need to find out if they are really
standard YUV or greyscale Jpegs and embed them in PDFs if they are.

BUG= chromium:801430 
Change-Id: I93eaf8b8fc22b7169b2fce9520e022b72ad0bf81
Reviewed-on: https://skia-review.googlesource.com/118992
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>

[modify] https://crrev.com/83e0f1b1bb111c99d2f11d382b31caef0af5de10/tests/PDFJpegEmbedTest.cpp
[modify] https://crrev.com/83e0f1b1bb111c99d2f11d382b31caef0af5de10/src/pdf/SkPDFBitmap.cpp
[modify] https://crrev.com/83e0f1b1bb111c99d2f11d382b31caef0af5de10/BUILD.gn
[modify] https://crrev.com/83e0f1b1bb111c99d2f11d382b31caef0af5de10/src/pdf/SkJpegInfo.h
[modify] https://crrev.com/83e0f1b1bb111c99d2f11d382b31caef0af5de10/src/pdf/SkJpegInfo.cpp
[modify] https://crrev.com/83e0f1b1bb111c99d2f11d382b31caef0af5de10/src/codec/SkJpegCodec.cpp

Project Member

Comment 11 by bugdroid1@chromium.org, Apr 8 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4bcb74dab38727afbd1723876a41f320bacf44b0

commit 4bcb74dab38727afbd1723876a41f320bacf44b0
Author: skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Sun Apr 08 08:47:33 2018

Roll src/third_party/skia/ 0cfd547b4..4473907de (18 commits)

https://skia.googlesource.com/skia.git/+log/0cfd547b465a..4473907dee6b

$ git log 0cfd547b4..4473907de --date=short --no-merges --format='%ad %ae %s'
2018-04-08 herb Revert "Remove all notion of transport from the API."
2018-04-07 angle-skia-autoroll Roll third_party/externals/angle2/ e547aac75..5ae64c94d (1 commit)
2018-04-05 halcanary SkPDF: smarter Jpeg when libjpeg-turbo is present
2018-04-07 angle-skia-autoroll Roll third_party/externals/angle2/ d2488aba5..e547aac75 (2 commits)
2018-04-06 herb Better layer tracking fidelity
2018-04-06 angle-skia-autoroll Roll third_party/externals/angle2/ b8e396609..d2488aba5 (2 commits)
2018-04-06 skcms-skia-autoroll Roll third_party/externals/skcms/ 24c91d143..8a727815d (1 commit)
2018-04-06 brianosman Remove scanlineOrder switch statements that always do the same thing
2018-04-06 reed detect if makeOffset failed
2018-04-05 csmartdalton vulkan: Fix an optimus-related failure with vkEnumeratePhysicalDevices
2018-04-06 egdaniel Make generated effects from sksl fp files not need SK_SUPPORT_GPU
2018-04-05 herb Remove all notion of transport from the API.
2018-04-04 halcanary SkRegion: Use less memory for SkRegion::Oper
2018-04-06 brianosman Remove old debugger (it no longer builds)
2018-04-06 liyuqian Revert "Exercise the threaded backend in test bots"
2018-04-06 egdaniel Remove unneeded SK_SUPPORT_GPU checks in gpu only files.
2018-04-06 halcanary Region Op Fuzzer
2018-04-05 csmartdalton ccpr: Make curve corners more seamless

Created with:
  roll-dep src/third_party/skia
BUG= chromium:801430 ,chromium:797940


The AutoRoll server is located here: https://autoroll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
TBR=borenet@chromium.org

Change-Id: I45239c2c6224796dd180797160dcdef1249920f9
Reviewed-on: https://chromium-review.googlesource.com/1001732
Reviewed-by: skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#549085}
[modify] https://crrev.com/4bcb74dab38727afbd1723876a41f320bacf44b0/DEPS

Labels: -M-65 -Needs-Triage-M63 M-67
Status: Fixed (was: Assigned)

Sign in to add a comment