[poppler] Getting a raster image like pdf2ppm

[Albert Astals Cid]

A Dijous, 21 de maig de 2009, Angus March va escriure:
> 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.
>
>     It doesn't seem to be. I'll try running valgrind on the debug
> version of pdftoppm that I have here, and see what that does...
>     Well she hasn't reported any problems so far. I'll see tomorrow
> morning, then I guess I'll know for sure.
>     Also, I keep forgetting to point out that another problem my app has
> is with Splash getting stuck in an infinite loop every so often,
> requiring a kill -9.
>     How about this: I send you a sample of something that causes the
> problems. Compile this and run it through valgrind. It came across a few
> problems in a short time. BTW, for the sake of simplicity, it doesn't
> actually output any files. It just gets the raw image data from Splash.

I see the problem, but i also see that 

pages=`/home/tsdgeos/cvs/poppler/build-new/utils/pdfinfo "$filename" | grep 
Pages: | cut -c 1,2,3,4,5,6 --complement`
for index in $(seq 1 $pages); do
  echo -n "$index "
  /home/tsdgeos/cvs/poppler/build/utils/pdftoppm -f $index -l $index 
"$filename" old/foo$index &
done
wait

Does not have this problem, so there must be something that does not get 
detached on fork?

Also thinking on the answer i gave you about thread safety, let me clarify 
this, i'm sure poppler runs fine on a thread, i'm not sure two threads can run 
poppler at the same time (maybe it's the same problem you are having but don't 
see how since fork() you fork at the very beginning)

Albert