Re: [Caml-list] [ANNOUNCE] llpp
Török Edwin
> Hello,
>
> Long story cut short: the PDF viewers that are available for my machine
> leave a lot to be desired for my usage pattern, so i had to write yet
> another, the code is at:
>
> http://repo.or.cz/w/llpp.git
>
> http://repo.or.cz/w/llpp.git/blob_plain/master:/BUILDING explains how to
> build it.
>
Appears to be working fine so far, and much faster than okular.
Two minor issues:
1. The mupdf from sumatrapdf installs fitz.h and mupdf.h directly into
/usr/local/include, and not under fitz/, or mupdf/, so llpp failed to
compile. I fixed by copying the headers to where llpp expected them to be.
2. It segfaults if the file is not found, fix below:
diff --git a/link.c b/link.c
index 7ca7684..7dab233 100644
--- a/link.c
+++ b/link.c
@@ -177,7 +177,8 @@ static void __attribute__ ((format (printf, 2, 3)))
static void die (fz_error error)
{
fz_catch (error, "aborting");
- pdf_closexref (state.xref);
+ if (state.xref)
+ pdf_closexref (state.xref);
exit (1);
}
Best regards,
--Edwin
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
malc
> On 06/12/2010 09:36 PM, malc wrote:
> > Hello,
> >
> > Long story cut short: the PDF viewers that are available for my machine
> > leave a lot to be desired for my usage pattern, so i had to write yet
> > another, the code is at:
> >
> > http://repo.or.cz/w/llpp.git
> >
> > http://repo.or.cz/w/llpp.git/blob_plain/master:/BUILDING explains how to
> > build it.
> >
>
> Appears to be working fine so far, and much faster than okular.
>
> Two minor issues:
> 1. The mupdf from sumatrapdf installs fitz.h and mupdf.h directly into
> /usr/local/include, and not under fitz/, or mupdf/, so llpp failed to
> compile. I fixed by copying the headers to where llpp expected them to be.
I was a nanometer away from typing: please edit build.sh to match your
mupdf installation(or lack there of) into BUILDING, but then didn't,
sigh...
> 2. It segfaults if the file is not found, fix below:
> diff --git a/link.c b/link.c
> index 7ca7684..7dab233 100644
> --- a/link.c
> +++ b/link.c
> @@ -177,7 +177,8 @@ static void __attribute__ ((format (printf, 2, 3)))
> static void die (fz_error error)
> {
> fz_catch (error, "aborting");
> - pdf_closexref (state.xref);
> + if (state.xref)
> + pdf_closexref (state.xref);
> exit (1);
> }
>
Thank you.
--
mailto:av1...@comtv.ru
bluestorm
> > Two minor issues:
> > 1. The mupdf from sumatrapdf installs fitz.h and mupdf.h directly into
> > /usr/local/include, and not under fitz/, or mupdf/, so llpp failed to
> > compile. I fixed by copying the headers to where llpp expected them to
> be.
>
> I was a nanometer away from typing: please edit build.sh to match your
> mupdf installation(or lack there of) into BUILDING, but then didn't,
> sigh...
I had the same problem and had to change link.c, not build.sh. It would be
nicer if the harcoded header path were not "fitz/fitz.h" and "mupdf/mupdf.h"
but "fitz.h" and "mupdf.h". You would have to add the corresponding
"$mupdflibpath/fitz/" and "$mupdflibpath/mupdf" in your build.sh, but
standard mupdf installation would work out of the box.
malc
Thanks for suggestion, it's just that i tend to not install things instead
just letting the linger in their build environments, i'll try to integrate
this idea though, thanks once again.