diff options
| -rw-r--r-- | pdf/pdfium/pdfium_engine.cc | 19 |
1 files changed, 3 insertions, 16 deletions
diff --git a/pdf/pdfium/pdfium_engine.cc b/pdf/pdfium/pdfium_engine.cc index 6506d8c..b049a14 100644 --- a/pdf/pdfium/pdfium_engine.cc +++ b/pdf/pdfium/pdfium_engine.cc @@ -3885,27 +3885,14 @@ bool PDFiumEngineExports::RenderPDFPageToDC(const void* pdf_buffer, settings.bounds.x() + settings.bounds.width(), settings.bounds.y() + settings.bounds.height()); - // A temporary hack. PDFs generated by Cairo (used by Chrome OS to generate - // a PDF output from a webpage) result in very large metafiles and the - // rendering using FPDF_RenderPage is incorrect. In this case, render as a - // bitmap. Note that this code does not kick in for PDFs printed from Chrome - // because in that case we create a temp PDF first before printing and this - // temp PDF does not have a creator string that starts with "cairo". - bool use_bitmap = false; - if (base::StartsWith(GetDocumentMetadata(doc, "Creator"), "cairo", - base::CompareCase::INSENSITIVE_ASCII)) { - use_bitmap = true; - } - - // Another temporary hack. Some PDFs seems to render very slowly if - // FPDF_RenderPage is directly used on a printer DC. I suspect it is + // A "temporary" hack. Some PDFs seems to render very slowly if + // FPDF_RenderPage() is directly used on a printer DC. I suspect it is // because of the code to talk Postscript directly to the printer if // the printer supports this. Need to discuss this with PDFium. For now, // render to a bitmap and then blit the bitmap to the DC if we have been // supplied a printer DC. int device_type = GetDeviceCaps(dc, TECHNOLOGY); - if (use_bitmap || - (device_type == DT_RASPRINTER) || (device_type == DT_PLOTTER)) { + if (device_type == DT_RASPRINTER || device_type == DT_PLOTTER) { FPDF_BITMAP bitmap = FPDFBitmap_Create(dest.width(), dest.height(), FPDFBitmap_BGRx); // Clear the bitmap |