[poppler] Getting a raster image like pdf2ppm

[Angus March]

Albert Astals Cid wrote:
> A Dijous, 21 de maig de 2009, Angus March va escriure:
>   
>> Albert Astals Cid wrote:
>>     
>>> A Dimecres, 20 de maig de 2009, Angus March va escriure:
>>>       
>>>> Albert Astals Cid wrote:
>>>>         
>>>>> A Dimarts, 19 de maig de 2009, Angus March va escriure:
>>>>>           
>>>>>> Adrian Johnson wrote:
>>>>>>             
>>>>>>> Angus March wrote:
>>>>>>>               
>>>>>>>> I tried using Poppler to get a Cairo surface and then saving the
>>>>>>>> surface to a PNG. Unfortunately, the resulting image was of
>>>>>>>> disastrously low quality.
>>>>>>>>                 
>>>>>>> Without seeing your code or the output you are getting I can only
>>>>>>> guess at what the problem might be. Did you alter the cairo scale to
>>>>>>> get the desired image dpi?
>>>>>>>               
>>>>>>     It was definitely an improvement, but I think the only thing that
>>>>>> did improve was the resolution. The old problems that caused me to
>>>>>> abandon Cairo persisted, which are: gradients have ugly stripes on
>>>>>> them, a background that should be white and opaque is black and
>>>>>> transparent, and some text that has a shadow in the PDF doesn't in the
>>>>>> image. I don't suppose you know of a way to deal w/those problems.
>>>>>>             
>>>>> ?
>>>>>
>>>>> I don't see anything obviously wrong.
>>>>>
>>>>> Basically it is:
>>>>>  * Create PDFDoc
>>>>>  * Create SplashOutputDev
>>>>>  * Call SplashOutputDev::startDoc
>>>>>  * Call PDFDoc::displayPageSlice
>>>>>           
>>>>     Well there definitely is something wrong, because it works with
>>>> pdftoppm. I thought of things like the __attribute__((constructor))
>>>> attribute, or static objects, but I don't see any evidence of the
>>>> attribute and I wouldn't know how to find a static object in all that
>>>> code. Maybe multiple processes causes problems for Splash.
>>>>
>>>>
>>>>
>>>> It's hard to know where to go.
>>>>         
>>> The crashes you pasted are from poppler compiled with -O2? If so remove
>>> the - O2 and substitute -g by -g3. Optimized poppler backtraces are
>>> really misleading.
>>>       
>>     I figured out a way to get my app to build from the poppler lib I
>> rolled myself (although I'd still like to know what the proper procedure
>> is to get it to build in debug, and install the Splash stuff) and I got
>> some valgrind reports that might be more helpful, but are fewer than
>> those I got when I was using the SUSE distro's lib:
>>
>> ==8577== Conditional jump or move depends on uninitialised value(s)
>> ==8577==    at 0x53DACE4: FoFiType1C::parse() (FoFiType1C.cc:1848)
>> ==8577==    by 0x53E10AB: FoFiType1C::make(char*, int) (FoFiType1C.cc:35)
>> ==8577==    by 0x5369A58: Gfx8BitFont::Gfx8BitFont(XRef*, char*, Ref,
>> GooString*, GfxFontType, Dict*) (GfxFont.cc:699)
>> ==8577==    by 0x536D72C: GfxFont::makeFont(XRef*, char*, Ref, Dict*)
>> (GfxFont.cc:143)
>> ==8577==    by 0x536D933: GfxFontDict::GfxFontDict(XRef*, Ref*, Dict*)
>> (GfxFont.cc:2051)
>> ==8577==    by 0x535AD21: GfxResources::GfxResources(XRef*, Dict*,
>> GfxResources*) (Gfx.cc:313)
>> ==8577==    by 0x535DD6B: Gfx::Gfx(XRef*, OutputDev*, int, Dict*,
>> Catalog*, double, double, PDFRectangle*, PDFRectangle*, int, int
>> (*)(void*), void*) (Gfx.cc:502)
>> ==8577==    by 0x539AF12: Page::createGfx(OutputDev*, double, double,
>> int, int, int, int, int, int, int, int, Catalog*, int (*)(void*), void*,
>> int (*)(Annot*, void*), void*) (Page.cc:404)
>> ==8577==    by 0x539B173: Page::displaySlice(OutputDev*, double, double,
>> int, int, int, int, int, int, int, int, Catalog*, int (*)(void*), void*,
>> int (*)(Annot*, void*), void*) (Page.cc:433)
>> ==8577==    by 0x40A756: pdf2jpg::GetSplash(int) (pdf2jpg.cpp:176)
>> ==8577==    by 0x40A9B5: pdf2jpg::TopupJpegThreads(int, astring const&)
>> (pdf2jpg.cpp:156)
>> ==8577==    by 0x40B3B1: pdf2jpg::Execute(int, char const*, char const*,
>> int) (pdf2jpg.cpp:99)
>> ==8577==
>>     
>
> Are you positively sure this doesn't happen with pdftoppm? Doesn't make any 
> sense.
>   

    BTW, this is the call to valgrind that you should us:
 valgrind --trace-children=yes --tool=memcheck
--log-file=valerror_%p.txt ./delete_this /path/to/a/pdf
If the pdf you choose enough samples you should be getting errors pretty
quickly.