Index: pdf/pdfium/pdfium_engine.cc |
diff --git a/pdf/pdfium/pdfium_engine.cc b/pdf/pdfium/pdfium_engine.cc |
index 6506d8c96b1038af85ffed479c6b7d05e9dcb8c1..b049a14c35cfc68266c7960f9570036f37626d10 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 |