[poppler] Re: [Patch] Info about document fonts

[Kristian Høgsberg]

Allright, that's a good point.  The iterator API is easier to extend 
without breaking ABI.

Another thing: this is pretty slow on big documents, for the PDF 
specification, test-poppler-glib takes about 30 seconds to extract all 
the fonts.  Do we need some kind of callback API for scanning the 
document to avoid blocking the GUI?

Also, I got a crash on one of the documents I teste it on -- we'll need 
to do something like

   origName = font->getOrigName();
   if (origName == NULL)
       name = new GooString ("(no name)");
   else
       name = origName->copy();

in FontInfo::FontInfo(), since Type3 fonts don't have a BaseName entry 
(which makes sense, but the PDF spec doesn't explicitly mention this).

cheers,
Kristian

Marco Pesenti Gritti wrote:
> Hi,
> 
> we are probably going to need more than the name string later. For
> example the embedded boolean... See FontInfo.h for other info that is
> already exposed. Also we may need more later, kde for example use the
> font path.
> You could pass back a list of structures... something like:
> 
> typedef struct {
>   char *name;
>   char *path;
>   gboolean embedded;
>   ....
> }
> 
> ev_font_info_new
> ev_font_info_free
> 
> Though, at that point, I probably prefer the iterator api. Still if
> you like that better I can fixup the patch... let me know.
> 
> Marco
> 
> On 6/7/05, Kristian Høgsberg <krh at bitplanet.net> wrote:
> 
>>Marco Pesenti Gritti wrote:
>>
>>>Slightly updated patch, I implemented evince font properties page with this.
>>>
>>>Marco
>>>
>>>On 6/4/05, Marco Pesenti Gritti <mpgritti at gmail.com> wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>here is a patch that allows to retrieve fonts information from the
>>>>document. It's based on xpdf pdffonts code. It's not complete yet but
>>>>if it make sense I'd like to check it in so that we start playing with
>>>>the user interface in evince and see what we need more...
>>>>Suggestions welcome, my c++/xpdf knowledge is not that great.
>>
>>Do we actually need a iterator for this?  What about just returning a
>>GList of g_strdup()'ed strings?
>>
>>cheers,
>>Kristian
>>
> 
>