Google Summer of Code 2012 - The Linux Foundation accepted!

Google Summer of Code 2012 - The Linux Foundation accepted!

[Till Kamppeter]

[ Subject corrected. ]

Hi,

Google has accepted The Linux Foundation again as mentoring organization!

Please spread the news and keep adding project ideas.

    Till

[Printing-architecture] Google Summer of Code 2012 - The Linux Foundation accepted!

[Till Kamppeter]

[ Subject corrected. ]

Hi,

Google has accepted The Linux Foundation again as mentoring organization!

Please spread the news and keep adding project ideas.

    Till

Re: [Printing-architecture] Google Summer of Code 2012 - The Linux Foundation accepted!

[Tobias Hoffmann]

Till Kamppeter wrote:
> Google has accepted The Linux Foundation again as mentoring organization!
I've been interested in working on the pdf manipulation tools already 
back in 2008, when I implemented the pdftoijs and texttopdf filters as 
GSoC-Project. So I'm quite thrilled to hear, that now, nearly having 
completed university, I might have the ability to work on them, and 
participate in GSoC again.

Through work on my low-level pdf library unpdf ( 
http://code.google.com/p/unpdf/ ) I have gained much knowledge on PDF 
internals (Adobe's PDF Reference, different PDF versions, etc) and 
implementation caveats. Although the current unpdf code-base implements 
enough of the low-level handling (also e.g. including support for 
encrypted pdfs) to build the desired tools upon, there are a significant 
number of areas in need of work; another possibility would be to either 
reimplement only the bare minimum of functionality (i.e. use unpdf, and 
maybe other pdf libs like iText only as guideline) or use another pdf 
i/o library as basis (podofo comes to mind, 
http://podofo.sourceforge.net/ ; a pure C choice with good-looking 
codebase could be MuPDF, http://mupdf.com/ <http://mupdf.com/>). But 
theses details can be worked out in time.
FWIW, I personally would strongly prefer C++0x/C++11 (esp. auto, 
std::unique_ptr, rvalue references / std::move) for this project, 
instead of trying to work around language limitations that will not gain 
us anything in the long term -- if this is possible.

  Tobias