Hi, Michael.
On Thu, May 27, 2010 at 14:02, Michael Gilbert
<michael.s.gilb...@gmail.com> wrote:
> 2010/5/16 Michael Gilbert:
>> thanks for your work on that. i would rather not touch upstream itself.
>> as such, i've set up a git repo containing only the debian packaging at:
>>
>> git clone git+ssh://<alioth user
>> name>@git.debian.org/git/collab-maint/xpdf.git
>>
>> please push your changes there.
>
> i just saw your blog post.
Thank you very much. I I would like to ask one thing: why don't you
want to touch the upstream part of xpdf? I think that it is quite
feasible to reshape the code so that it works as we want.
I once asked Derek two things:
* if he had any coding standard that should be adhered to; he told me
that he had more or less of a standard, but nothing too fixed, if I
understood it correctly. Adopting something like the Linux kernel
Coding Standard document is something that I would like to do, as I
think that it is quite sane and makes the code very readable (even for
something as complex as a whole kernel);
* if he had a tree of development so that I could test a newer version
of what we have and he said that he had, but he would not open it to
the public, as he intended to use that as a way to give his customer
advantages. This is fair enough, but we should be able to fix bugs
more swiftly if we just offload things to poppler and run the user
interface under many helpful tools like cppchecker, valgrind, LLVM's
clang's static analyzer, gcc's -Wall -Wextra -Weff-c++, splint and so
on. The code has many warnings, after all and they indicate some
problems with the build proccess.
For instance, IIRC, with all the compilation efforts that I had, plain
xpdf eventually used tmpnam, which is an insecure way to create
temporary files.
This would prevent the problems that the distributions have. But
Derek's work is highly appreciated. He, of course, wants to have a
broad coverage of environments so that he can sell the software and
make some money and there is absolutely nothing wrong with that.
To guarantee that it works across a large amount of libraries,
compilers and platforms (e.g., under Windows and other environments
where X is not really native), he provides a log of code that can
simply be ripped, as we are using GCC with (E)GLIBC and a relatively
modern operating system.
With this removed, we could use the standard types of C++ and make the
readability of the code a little bit higher (it took me some time to
discover what some of the functions did, what some classes stood for
etc). Removing things like his custom libraries Goo-whatever would be
a step in that direction (perhaps not right now, but latter).
> interestingly, i just finished solving the same problem.
That is very, very nice. Do you have the code somewhere? I think that
I would change the name of this program to something short, but
different from xpdf. The names mpdf (for mini pdf viewer), spdf (for
small pdf viewer), uxpdf (for micro pdf viewer) were already
considered by me. But I can't make any guarantees that I will be able
to create a "micro" version of it (let alone a nano version). :-)
> although i approached it by converting the existing package to use poppler.
I am interested in knowing how you proceeded.
> i'm planning to upload it in the next couple days, but i've been have trouble
> finding sponsors...
I think that finding sponsors is the least of the problems. I am not a
debian developer (yet), but I personally have some friends that are
and that would trust a package of mine if it were of reasonable
quality.
Anyway, the package can mature without being in Debian proper (of
course, I would prefer, of course, if it were in the archives anyway).
My comments above are just about a worst case scenario.
> anyway, your assistance with the package is very much appreciated.
> please use the alioth repository.
I was going to use a private repository on github or on my account on
alioth, to keep things separate from the official xpdf. What do you
think about that?
Regarding xpdf proper, I had a lot of trouble applying some patches
due to conflicts. It would be a good thing if we could split each
CVE-related patch from the monolithic patches that they are aggregated
into, so that we can select what is already applied, what Derek has
already included in his pl1, pl2, pl3, and pl4 releases to xpdf 3.02.
> best wishes,
> mike
So, how to proceed? I do want badly a pdf viewer that is small and
that can zoom (almost) arbitrarily.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
