[poppler] Fontconfig dependency for pdftops?

[Peter Åstrand]

On Tue, 19 Feb 2008, Albert Astals Cid wrote:

> > 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?

Yes, either this, or some other solution: GlobalParams.h needs the 
conditional define from config.h. One easy solution would be to just 
include config.h from GlobalParams.h, but as far as I can see, the 
approach in Poppler seems to be to include config.h in the .cc files 
rather than the header files. But for me, any solution which gives access 
to config.h defines from GlobalParams.{h,cc} is fine. 


> 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.

The main question is of course in what kind of "situations" 
getDisplayFont() is necessary. I've tried running the resulting binary on 
many PDFs without ever detecting any problem. From what I can tell from 
the code, all previous 14 if statements must be wrong for this to happen. 

As I understand it, getDisplayFont() should at least not be necessary if 
running pdftops with the -noembcidtt option? 

Our goal is to take a PDF, convert it to PS, and send it to the printer 
via "lpr". Thus, the resulting PS should be as "safe" as possible for 
printing. Perhaps I'm somewhat naïve, but in this case, wouldn't it 
suffice with embedding all fonts from the PDF in the PS, nothing more, 
nothing less? And cannot this be done without getDisplayFont()?


> 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"
> 
> So i want input from others here, Jeff? Carlos? Brad? Pino?

The statement "PDF without embedded fonts will not work" isn't generally 
true:

$ pdffonts hello2.pdf
name                                 type         emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------
Times-Roman                          Type 1       no  no  no       7  0

$ pdftops hello2.pdf

$ lpr hello2.ps

The printing is fine. 

Nevertheless, I do understand that you think a warning or similiar would 
be good. Initially, my idea was not to touch configure.ac at all, to avoid 
the problem of people being "tempted" by build without fontconfig. 
Instead, we could build without fontconfig by manually specifying 
DISABLE_FONTCONFIG on the make command line. But, since the configure 
script aborts if fontconfig is not found, this doesn't work, at least not 
without manually tweaking configure.ac. As I said, this is a problem for 
the Windows build as well. 

In any case, the changes to GlobalParams are the important ones. If you 
want to leave out the --disable-fontconfig option at this point, I can 
live with that. 

Best regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00