Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overly intense fringes #7

Open
0xBRM opened this issue Mar 23, 2016 · 10 comments
Open

Overly intense fringes #7

0xBRM opened this issue Mar 23, 2016 · 10 comments

Comments

@0xBRM
Copy link

0xBRM commented Mar 23, 2016

Screenshot comparison
Look at the t's, the i's and the p's. I know it is required but it seems a bit excessive.

Zoomed in is nowhere near as bad.

Edit: for some reason it seems to alter Okular's thumbnail generation as well, and not simply the text based ones.
Edit2: I am using poppler 0.42.0.

@giddie
Copy link
Owner

giddie commented Mar 23, 2016

Yeah, I'm not happy with the fringes either. I imagine there's some filtering that could be applied to this, but I'm afraid I know pretty much nothing about how Cairo does subpixel rendering. Patches or research would be greatly appreciated. A good starting point might be to look for any patches people have made to apply subpixel rendering in Evince, as we should be able to apply the same code in this patchset.

It doesn't surprise me too much that you're seeing differences in thumbnail generation in Okular: this patchset changes the whole rendering engine that Okular uses to match that of Evince and any other apps that use the Cairo backend.

@0xBRM
Copy link
Author

0xBRM commented Mar 23, 2016

Okay, so the problem is that Cairo, as used by poppler, will default to FT_LCD_FILTER_LEGACY and this is what's causing all the issues. When you force it to use FT_LCD_FILTER_DEFAULT (where the default is "08 24 36 24 08", as per infinality/fontconfig-ultimate's patchset, though you can try using vanilla freetype) the results look much better.

FT_LCD_FILTER_LEGACY

FT_LCD_FILTER_DEFAULT

The overly bold text can be remedied by using a more up-to-date pixman, or by including a slightly lighter default LCD filter (LCD_FILTER_LIGHT).

@giddie
Copy link
Owner

giddie commented Mar 23, 2016

So do you know what cairo method call is required to apply the filter? I'm hoping it can be easily added in the Cairo font options in CairoOutputDev::setCairo().

@0xBRM
Copy link
Author

0xBRM commented Mar 23, 2016

It used to be cairo_font_options_set_lcd_filter() but they have since removed it, so I'm using a patched Cairo.

Screenshot comparison

As you can see it looks noticeably better, without the fringes. Smaller fonts look amazing as well.

@zhou13
Copy link

zhou13 commented Mar 26, 2016

You may also interest in my patchset https://github.com/zhou13/poppler-subpixel, which only enables subpixel rendering when the correctness is guaranteed by calling poppler_page_support_subpixel_rendering.

@0xBRM
Copy link
Author

0xBRM commented Mar 26, 2016

@zhou13 Ah, I actually used your patchset.
I'm going to try your patch and report back with results.

Redacted due to misunderstanding.

@zhou13
Copy link

zhou13 commented Mar 26, 2016

What I notice is that zhou13's version in you screenshot does not has subpixel rendering at all... Directly applying my patchset won't change the result of okular because it is designed for evince now. In order to make it work for okular, you need to patch okular also (to explicit enable subpixel rendering). As for the result, I expect they should be exactly the same on most PDF files unless blending mode are used.

@0xBRM
Copy link
Author

0xBRM commented Mar 26, 2016

@zhou13 Oh, I see, so it doesn't add support for the cairo backend to the Qt4 bindings. My bad. Should have read the patchset.

@giddie
Copy link
Owner

giddie commented Mar 29, 2016

Thanks @zhou13; you've done the Cairo-backend-side work to support subpixel-rendering properly, which is what I was hoping for. It's unfortunate that it requires a patched Cairo. If that weren't the case, I'd certainly try to include your work in this patchset too, as the current patch I use to make the Cairo backend do subpixel-rendering is pretty basic.

Do you know whether Cairo is interested in merging the necessary code upstream?

@zhou13
Copy link

zhou13 commented Mar 29, 2016

https://bugs.freedesktop.org/show_bug.cgi?id=10301

It seems that comments in bugzilla are ignored as usual. Maybe we need to submit it to the developer mail list.

giddie pushed a commit that referenced this issue Sep 11, 2020
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24772

When numInputSyms + numNewSyms is large enough, a fatal out of memory
allocation can occur in JArithmeticDecoderStats() constructor per

```
    #0 0xf7f6bf19 in [vdso]
    #1 0xf7d40d08 in gsignal (/lib32/libc.so.6+0x2bd08)
    #2 0xf7d42206 in abort (/lib32/libc.so.6+0x2d206)
    #3 0xbdc0049 in gmalloc(unsigned int, bool) gdal/poppler/goo/gmem.h:52:5
    #4 0xbdf3c61 in gmallocn(int, int, bool) gdal/poppler/goo/gmem.h:119:12
    #5 0xc1391fd in JArithmeticDecoderStats::JArithmeticDecoderStats(int) gdal/poppler/poppler/JArithmeticDecoder.cc:36:30
    #6 0xc1130d5 in JBIG2Stream::resetIntStats(int) gdal/poppler/poppler/JBIG2Stream.cc:4052:25
    #7 0xc1083df in JBIG2Stream::readSymbolDictSeg(unsigned int, unsigned int, unsigned int*, unsigned int) gdal/poppler/poppler/JBIG2Stream.cc:1624:9
    #8 0xc105305 in JBIG2Stream::readSegments() gdal/poppler/poppler/JBIG2Stream.cc:1318:18
    #9 0xc103f5a in JBIG2Stream::reset() gdal/poppler/poppler/JBIG2Stream.cc:1142:5
```

Avoid it and return nicely.
giddie pushed a commit that referenced this issue Oct 19, 2020
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25411

    #0 0xf7ef8f19 in [vdso]
    #1 0xf7ccdd08 in gsignal (/lib32/libc.so.6+0x2bd08)
    #2 0xf7ccf206 in abort (/lib32/libc.so.6+0x2d206)
    #3 0xbdb9c2e in grealloc(void*, unsigned int, bool) gdal/poppler/goo/gmem.h:85:5
    #4 0xbdd9e11 in greallocn(void*, int, int, bool, bool) gdal/poppler/goo/gmem.h:171:12
    #5 0xc012373 in SplashPath::addStrokeAdjustHint(int, int, int, int) gdal/poppler/splash/SplashPath.cc:211:35
    #6 0xbfd156f in Splash::makeStrokePath(SplashPath*, double, bool) gdal/poppler/splash/Splash.cc:5987:34
    #7 0xbfcaec2 in Splash::strokeWide(SplashPath*, double) gdal/poppler/splash/Splash.cc:2028:13
    #8 0xbfc8a4d in Splash::stroke(SplashPath*) /src/gdal/poppler/splash/Splash.cc

Based on patch by Even Rouault
giddie pushed a commit that referenced this issue Mar 25, 2024
…odeMono8 case

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64471

```
$ utils/pdftoppm clusterfuzz-testcase-minimized-gdal_fuzzer-6127122829410304
[...]
=================================================================
==1758602==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000024cd5 at pc 0x7fd5850e977d bp 0x7ffe0e007430 sp 0x7ffe0e007428
READ of size 1 at 0x602000024cd5 thread T0
    #0 0x7fd5850e977c in Splash::blitTransparent(SplashBitmap*, int, int, int, int, int, int) /home/even/poppler/splash/Splash.cc:5778:24
    #1 0x7fd58505e19d in SplashOutputDev::beginTransparencyGroup(GfxState*, double const*, GfxColorSpace*, bool, bool, bool) /home/even/poppler/poppler/SplashOutputDev.cc:3998:17
    #2 0x7fd5850451c3 in SplashOutputDev::setSoftMaskFromImageMask(GfxState*, Object*, Stream*, int, int, bool, bool, double*) /home/even/poppler/poppler/SplashOutputDev.cc:2692:5
    #3 0x7fd584c3f6a7 in Gfx::doPatternImageMask(Object*, Stream*, int, int, bool, bool) /home/even/poppler/poppler/Gfx.cc:1964:10
    #4 0x7fd584c5cc26 in Gfx::doImage(Object*, Stream*, bool) /home/even/poppler/poppler/Gfx.cc:4304:17
    #5 0x7fd584c1827a in Gfx::opBeginImage(Object*, int) /home/even/poppler/poppler/Gfx.cc:4900:9
    #6 0x7fd584c32abe in Gfx::execOp(Object*, Object*, int) /home/even/poppler/poppler/Gfx.cc:811:5
    #7 0x7fd584c316ef in Gfx::go(bool) /home/even/poppler/poppler/Gfx.cc:686:13
    #8 0x7fd584c30f76 in Gfx::display(Object*, bool) /home/even/poppler/poppler/Gfx.cc:647:5
    #9 0x7fd58506713d in SplashOutputDev::tilingPatternFill(GfxState*, Gfx*, Catalog*, GfxTilingPattern*, double const*, int, int, int, int, double, double) /home/even/poppler/poppler/SplashOutputDev.cc:4424:10
    #10 0x7fd584c3b41b in Gfx::doTilingPatternFill(GfxTilingPattern*, bool, bool, bool) /home/even/poppler/poppler/Gfx.cc:2176:53
    #11 0x7fd584c36188 in Gfx::doPatternFill(bool) /home/even/poppler/poppler/Gfx.cc:1895:9
    #12 0x7fd584c16d93 in Gfx::opFillStroke(Object*, int) /home/even/poppler/poppler/Gfx.cc:1794:17
    #13 0x7fd584c32abe in Gfx::execOp(Object*, Object*, int) /home/even/poppler/poppler/Gfx.cc:811:5
    #14 0x7fd584c316ef in Gfx::go(bool) /home/even/poppler/poppler/Gfx.cc:686:13
    #15 0x7fd584c30f76 in Gfx::display(Object*, bool) /home/even/poppler/poppler/Gfx.cc:647:5
    #16 0x7fd584de61b9 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) /home/even/poppler/poppler/Page.cc:593:14
    #17 0x7fd584dfd5fc in PDFDoc::displayPageSlice(OutputDev*, int, double, double, int, bool, bool, bool, int, int, int, int, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) /home/even/poppler/poppler/PDFDoc.cc:633:24
    #18 0x4cc9c6 in savePageSlice(PDFDoc*, SplashOutputDev*, int, int, int, int, int, double, double, char*) /home/even/poppler/utils/pdftoppm.cc:293:10
    #19 0x4cb932 in main /home/even/poppler/utils/pdftoppm.cc:695:9
    #20 0x7fd5841ef082 in __libc_start_main /build/glibc-wuryBv/glibc-2.31/csu/../csu/libc-start.c:308:16
    #21 0x41d61d in _start (/home/even/poppler/build/utils/pdftoppm+0x41d61d)

0x602000024cd5 is located 1 bytes to the right of 4-byte region [0x602000024cd0,0x602000024cd4)
allocated by thread T0 here:
    #0 0x495d5d in malloc (/home/even/poppler/build/utils/pdftoppm+0x495d5d)
    #1 0x7fd5849f1d54 in gmalloc(unsigned long, bool) /home/even/poppler/goo/gmem.h:44:19
    #2 0x7fd5849f0ed0 in gmallocn(int, int, bool) /home/even/poppler/goo/gmem.h:121:12
    #3 0x7fd584c1384d in gmallocn_checkoverflow(int, int) /home/even/poppler/goo/gmem.h:126:12
    #4 0x7fd5850f7ec5 in SplashBitmap::SplashBitmap(int, int, int, SplashColorMode, bool, bool, std::vector<GfxSeparationColorSpace*, std::allocator<GfxSeparationColorSpace*> > const*) /home/even/poppler/splash/SplashBitmap.cc:111:28
    #5 0x7fd585066631 in SplashOutputDev::tilingPatternFill(GfxState*, Gfx*, Catalog*, GfxTilingPattern*, double const*, int, int, int, int, double, double) /home/even/poppler/poppler/SplashOutputDev.cc:4398:18
    #6 0x7fd584c3b41b in Gfx::doTilingPatternFill(GfxTilingPattern*, bool, bool, bool) /home/even/poppler/poppler/Gfx.cc:2176:53
    #7 0x7fd584c36188 in Gfx::doPatternFill(bool) /home/even/poppler/poppler/Gfx.cc:1895:9
    #8 0x7fd584c16d93 in Gfx::opFillStroke(Object*, int) /home/even/poppler/poppler/Gfx.cc:1794:17
    #9 0x7fd584c32abe in Gfx::execOp(Object*, Object*, int) /home/even/poppler/poppler/Gfx.cc:811:5
    #10 0x7fd584c316ef in Gfx::go(bool) /home/even/poppler/poppler/Gfx.cc:686:13
    #11 0x7fd584c30f76 in Gfx::display(Object*, bool) /home/even/poppler/poppler/Gfx.cc:647:5
    #12 0x7fd584de61b9 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) /home/even/poppler/poppler/Page.cc:593:14
    #13 0x7fd584dfd5fc in PDFDoc::displayPageSlice(OutputDev*, int, double, double, int, bool, bool, bool, int, int, int, int, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) /home/even/poppler/poppler/PDFDoc.cc:633:24
    #14 0x4cc9c6 in savePageSlice(PDFDoc*, SplashOutputDev*, int, int, int, int, int, double, double, char*) /home/even/poppler/utils/pdftoppm.cc:293:10
    #15 0x4cb932 in main /home/even/poppler/utils/pdftoppm.cc:695:9
    #16 0x7fd5841ef082 in __libc_start_main /build/glibc-wuryBv/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/even/poppler/splash/Splash.cc:5778:24 in Splash::blitTransparent(SplashBitmap*, int, int, int, int, int, int)
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants