[ANNOUNCE] llpp

[ANNOUNCE] llpp

[malc]

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.

-- 
mailto:av1474@comtv.ru

Re: [Caml-list] [ANNOUNCE] llpp

[Török Edwin]

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.
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

Re: [Caml-list] [ANNOUNCE] llpp

[malc]

On Sat, 12 Jun 2010, T?r?k Edwin wrote:

> 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:av1474@comtv.ru

Re: [Caml-list] [ANNOUNCE] llpp

[bluestorm]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

2010/6/12 malc <av1474@comtv.ru>

> > 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.

[-- Attachment #2: Type: text/html, Size: 1152 bytes --]

Re: [Caml-list] [ANNOUNCE] llpp

[malc]

On Sat, 12 Jun 2010, bluestorm wrote:

> 2010/6/12 malc <av1474@comtv.ru>
> 
> > > 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.

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. 

-- 
mailto:av1474@comtv.ru