[poppler] Poppler metadata expansion

[Martin Kretzschmar]

Hi Emil,

Am Montag, den 09.05.2005, 11:49 -0400 schrieb Leonard Rosenthol:
> At 11:36 AM 5/9/2005, Emil Soleyman-Zomalan wrote:
> >The reason for treating dates as strings was to do the actual
> >reformatting in the application itself (Evince) so that we could provide
> >that function to other areas that could possibly require it.
> 
>          That makes sense...
> 
>          Though it might be nice to have a similar API call inside of 
> Poppler for converting PDF dates into some other date format (time_t, 
> etc.).  pdfinfo has such a routine (printInfoDate()) from which the 
> relevent code can be lifted.
> 
>          Or if it helps, here are two snippets from my library that might 
> help.  They use std::string, so you may wish to change... (and in looking 
> at them now, for the first time in a LONG time - they could certainly be 
> cleaned up and more generalized).
> 
> 
> Leonard
> ------------------------------------
> int AcroDateTime::AcrobatDateToLocalDate ( const char * inAcrobatDate, char 
> * outLocalDate, ASInt32 inBufferLength )
>          {
>                  tm theTimeRecord ;

That would be "struct tm" (from time.h) in plain C. And it's what
pdfinfo uses internally as well. IMHO a newly allocated struct tm is the
best thing to return from poppler-glib. My attempt from gpdf (adapted
from pdfinfo, IIRC) is here:

http://cvs.gnome.org/viewcvs/gpdf/xpdf/pdf-info-dict-util.cc?rev=HEAD&view=markup

Bonus points if you add the time zone parsing ;-)

Regards,

Martin