[poppler] Poppler metadata expansion
m_kretzschmar at gmx.net
Mon May 9 12:52:24 PDT 2005
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).
> 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:
Bonus points if you add the time zone parsing ;-)
More information about the poppler