Created attachment 123900 [details] [review] proposed patch The patch poppler-subpixel.patch provides a new function called poppler_page_support_subpixel_rendering for glib/cairo backend for poppler. This function checks whether a PDF page could be subpixel-rendered. The reason that subpixel rendering is not implemented in a PDF viewer is that glyphs subpixel rendering cannot easily support transparent background, i.e., the background color much be known when the glyphs are rendered. By default, PDF has a transparent background. In most case, one can fill white to the background before the rendering of glyphs to workaround this problem. However, PDF file format has a feature called blend modes. Example can be downloaded from [https://github.com/mozilla/pdf.js/blob/master/test/pdfs/blendmode.pdf]. Some blend modes will generate different results when drawing on transparent or white background. Therefore, filling color into background is incorrect in this case. The new added function poppler_page_support_subpixel_rendering checks whether it is safe to fill some color into background by traversing current page and check whether transparent background and colored background are distinguishable by checking all the blend modes used before rendering. If it returns true, the application can call cairo_paint to fill the background and cairo_font_options_set_antialias to enable the subpixel rendering for cairo. See glib/demo/render.c for an example how to use the subpixel rendering feature.
Comment on attachment 123900 [details] [review] proposed patch Review of attachment 123900 [details] [review]: ----------------------------------------------------------------- ::: glib/poppler-page.cc @@ +2426,5 @@ > } > + > +gboolean > +poppler_page_support_subpixel_rendering (PopplerPage *page) > +{ This is not a good function name. PDF pages do not "support" subpixel rendering. The limitation is in cairo not supporting component alpha. It would be better to call it something like poppler_page_requires_blend_modes. Maybe this could be generalized to a method of checking what PDF functionality the page requires. I'm not sure what the glib way of doing this is. ::: poppler/CairoOutputDev.cc @@ +1422,5 @@ > > + fontType = state->getFont()->getType(); > + // Do not enable subpixel rendering for type3 font > + // For some reason it does not work > + if (fontType == fontType3) { This should be in a separate patch. Also needs an explanation why it is needed and a test case.
Thanks for the review. For the second point, poppler calls cairo_user_font_face_set_render_glyph_func to define the render function for type3 font, as the type3 font is actually a PS file and it is not supported by freetype. It seems that cairo uses other blend mode other than CAIRO_OPERATOR_OVER to create a cairo_t as the canvas for input of user defined render function. So if we enable subpixel rendering, the result will be incorrect. I am not 100% sure on this as it requires to understand how the internal of cairo's custom render function works. I tried to workaround this problem but I did not succeed. I am not sure how to create a test in this case. Any advice?
(In reply to Yichao Zhou from comment #2) >It seems that cairo uses other blend mode other than > CAIRO_OPERATOR_OVER to create a cairo_t as the canvas for input of user > defined render function. So if we enable subpixel rendering, the result > will be incorrect. Where does this happen? Looking at cairo-user-font.c: In _cairo_user_scaled_glyph_init, a recording surface is created. A context is created for the recording surface. The default operator is not changed. The user render function is called to record the glyph drawing operations. In _cairo_user_scaled_glyph_init, when the glyph bitmap is requested, an image surface is created. If the font antialias option is subpixel the image will be ARGB32. The recording is replayed to the image surface. If you are seeing a problem with type 3 fonts you should be able to provide a sample pdf file and screen shots of the incorrect rendering. pdftocairo has -antialias option that can also be used to for testing. This sound like a separate issue to your proposed feature and should be filed in a separate bug. If may actually be a cairo bug and it would be helpful if you could create a test that used cairo to demonstrate the bug. We don't want to add code to poppler to workaround a cairo bug. Instead the bug should be fixed in cairo.
Hi, what's the current status of this patch? I've always been wanted sub-pixel rendering for PDF on the Linux world.. As far as I read the patch description, this seems to solve most of time. Then that's fine for me. If there is any chance this is got merged, I'm happy to finish off this patch for polishing! :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/23.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.