Just making it easier for developers to integrate pdftohtml features into there code; as well as general improvements to the pdftohtml codebase.
It could also serve as "killer-app" type reference for making the xpdf and poppler libraries more modular. On Sat, Oct 29, 2011 at 6:00 PM, Josh Richardson <[email protected]> wrote: > I think you may be mixing metaphors. Poppler is the library to > query/write PDFs. pdftohtml is a utility using that library using > specialized writers. > > I personally think that the Poppler code could use a lot of cleanup and > documentation, however I think we're somewhat limited because we still > track the sizeable development efforts of the xpdf community. I'm not > sure about the "modularization" you're looking for. What are the use > cases that you would like to improve? > > --josh > > On 10/28/11 11:37 PM, "Alec Taylor" <[email protected]> wrote: > >>The current pdftohtml.cc is extremely in need of modularity. I'm >>considering making the utility more modular, to the point of making it >>object-orientated. >> >>int main(int argc, char *argv[]) >> PDFtoHTML *foo = new PDFtoHTML; >> if(!foo->setArgs(argDesc, &argc, argv) { >> delete foo; >> return false; >> else { >> delete foo; >> return true; >> } >>} >> >>Public member functions could include: >>GBool PDFtoHTML::toXML(char passes); >>GBool PDFtoHTML::toHTML(GBool images, GBool complex); >>GBool PDFtoHTML::PDFinfo(); >>GBool PDFtoHTML::removeRestrictions(); >> >>&etc >> >>What do you think? - Worth doing? - Useful? - Too far?! >> > > _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
