[poppler] Fontconfig dependency for pdftops?

Albert Astals Cid aacid at kde.org
Thu Feb 21 11:24:52 PST 2008


A Dimecres 20 Febrer 2008, Jonathan Kew va escriure:
> On 19 Feb 2008, at 9:32 pm, Albert Astals Cid wrote:
> > A Dimarts 19 Febrer 2008, Peter Åstrand va escriure:
> >> On Sun, 10 Feb 2008, Peter Åstrand wrote:
> >>> We are updating our "pdftops" from the one shipped with
> >>> xpdf-2.02pl1 to
> >>> the latest poppler version. Is fontconfig a hard dependency
> >>> nowadays,
> >>> even for tools like pdftops?
> >>
> >> I think I can answer this myself. Yes, it's a hard dependency, but
> >> it's
> >> easy to get rid of. pdftops seems to work perfectly fine without
> >> fontconfig, and the size of the resulting binary is greatly reduced.
> >> Another great advantage is that the binary will be self contained
> >> and does
> >> not require a fontconfig configuration.
> >>
> >> In GlobalParams.cc, there's a comment:
> >>
> >>  /* if you can't or don't want to use Fontconfig, you need to
> >> implement
> >>     this function for your platform. For Windows, it's in
> >> GlobalParamsWin.cc */
> >>
> >> However, the code in question is surrounded by "#ifndef _MSC_VER",
> >> which
> >> is not very generic. The attached patch generalizes this and
> >> depends on
> >> the define "DISABLE_FONTCONFIG" instead. Additionally, it provides
> >> a stub
> >> implementation of getDisplayFont on UNIX, when fontconfig is not
> >> used.
> >>
> >> Any chance this patch can be accepted? In addition to making it
> >> possible
> >> to build Poppler without fontconfig on UNIX, it also makes it
> >> possible to
> >> build Poppler for Windows with MinGW, without Fontconfig.
> >
> > First a easy question:
> >  * Do you really need that config.h includes in HtmlFonts.cc and
> > PreScanOutputDev.cc?
> >
> > And now onto the core part of the mail. You are "wrong", pdftops uses
> > PSOutputDev which does getDisplayFont calls in some situations, so
> > right,
> > it's not a HARD dependency, but you most probably want it or those
> > situations
> > won't work.
> >
> > So i'm actually not much keen of adding that patch, but if others
> > OK it, i
> > think i could tolerate it if we add a big warning saying that
> > "FontConfig
> > will not be used and PDF without embedded fonts will not work"
>
> I've been using a similar -disable-fontconfig patch to (cross-)
> compile with MinGW for Windows. I also use it to build on Mac OS X
> without requiring fontconfig (which is not universally available --
> it depends whether the user has installed the optional X11 package),
> in a context where I don't need support for non-embedded fonts.
>
> What I think should eventually be offered would be several choices
> for the font-finding system:
>
> * fontconfig (available on all platforms, but not "native" on Win32
> or Mac OS X)
> * GDI (only on Win32, but should be available for both MSVC and MinGW
> builds)
> * Apple Type Services (only on Mac OS X, code still to be written)
> * omit support for local fonts (issuing a warning at build time would
> be fine)

I agree this would be a good solution, and Peter patch goes into this 
direction. Patches to finish it are more than welcome :-)

Albert

>
> Which of these is used (on Windows and Mac) should be independent of
> which compiler is being used. So it is correct to distinguish the
> fontconfig vs GDI question from the _MSC_VER conditional, and expose
> this through configure, but I'd like to see further work in this
> area. If I can find the time, I'm hoping to write a Mac OS X version
> of the getDisplayFont one of these days.
>
> JK
>
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler




More information about the poppler mailing list