On Wed, 02 Jun 2010 04:44:06 -0300, Rogério Brito wrote: > Hi once again, Michael.
hi again, > On 05/27/2010 04:41 PM, Rogério Brito wrote: > > The code has many warnings, after all and they indicate some > > problems with the build proccess. > > I've been making a lot of progress with xpdf-poppler. I would welcome > any help that you might offer. i'll probably upload my changes to mentors tonight. then its a matter of finding a sponsor ;) > > 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 problem is not present anymore (I think). > > > 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. > > I removed some code that was for legacy systems (e.g., Windows or very > old versions of Motif). This should keep the code smaller and easier to > understand. > > > 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). > > I moved from his GBool type to the C++ standard bool type and this makes > it easier to read the code. > > > Removing things like his custom libraries Goo-whatever would be > > a step in that direction (perhaps not right now, but latter). > > One of the next steps would be to remove the Goostring etc. and replace > with standard C++ string types. i think it would make more sense to apply these changes to poppler first since it has an active upstream (and since xpdf will be using poppler going forward). the poppler maintainers sent out an RFH a while back, so you may want to offer your assistance there. also, since these changes don't address debian-specific bug reports/problems, i think it makes more sense to push them upstream first. one of debian's tenants is to avoid upstream divergence unless absolutely necessary (bug/security fixes). hence, you probably want to try to become an upstream poppler contributor. > Also, the zoom code could be improved a lot: right now, there is a lot > of workarounds to make sure that the user only moves from one of the > defined zoom levels to another. > > This, in particular, involves converting between zoom (sometimes, > expressed as doubles, sometimes, as strings) levels and the indexes of > the array of the pulldown menu. i also think it would make more sense to push this kind of change into upstream xpdf first, but i would be willing to consider applying a patch if it is modest. > >> 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. > > Just for your information, I've been keeping the code at > > git://github.com/rbrito/xpdf-poppler.git i'll take a look when i have a chance, but i only plan on modifying the debian dir itself. > > 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). :-) > > With the code being offloaded to the library, the executable, stripped, > is under 130KB. i haven't taken a look at the size my version, but i would imagine it is similarly small due to the absence of poppler. thanks again for your work. best wishes, mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
