[poppler] [KPDF-PATCH] Fontconfig support

[Kristian Høgsberg]

Albert Astals Cid wrote:
...

>>I finally got around to looking into this patch.  I do like the idea of
>>parsing the weight and slant settings from the PDF font name; that
>>should improve the font matching heuristic a great deal.
> 
> That algorithm should be improved a bit, PDF spec says only , can be used to 
> give Bold, Oblique etc to fonts (i can not find it in the spec right now but 
> i'm almost sure i saw it), but i have some pdf that use - instead of , so 
> having - to is good in some cases but bad in some others, for example there 
> are fonts called MS-Mincho that means our algorithm splits it in MS and 
> Mincho, right now i've modified it a big and have 
> 
> if (name.find("MS-") == 0) name = "MS " + name.remove(0,3);
> if (!name.contains('-') && !name.contains(',')) return;
> QString type = name.section(QRegExp("[-,]"),-1);
> name = name.section(QRegExp("[-,]"),0,-2);
> if (type.contains("Oblique")) slant=FC_SLANT_OBLIQUE;
> if (type.contains("Italic")) slant=FC_SLANT_ITALIC;
> if (type.contains("Bold")) weight=FC_WEIGHT_BOLD;
> if (type.contains("Light")) weight=FC_WEIGHT_LIGHT;
> if (type.contains("Condensed")) width=FC_WIDTH_CONDENSED;
> 
> That is, i've added weights Light and Condensed (i think we should add all of 
> them) and have created a hack to avoid MS-Mincho problem, but i think that a 
> better solution could be found.

I don't think we should special case things like substituting "MS-" 
prefixes for "MS ", but you're right, the heuristic can definitely be 
improved.  The ',' rule is described in section 5.5.2, and is for 
requesting a synthesized bold, italic or bolditalic version of a font. 
The dash seems to be a convention for separating family name and style 
in postscript font names, but apparently some PDF generators also 
substitute dashes for spaces.

I don't think we should spend too much time optimizing this case - 
documents that rely on non-standard external fonts are sort of broken 
anyway, in my opinion.  What about this approach: we look for the last 
',' or '-' in the font name and look for style properties after that. 
We should probably look for common abbreviations ('Ital', 'Medi', 
'Ligh', 'Obli' etc) and not the full names.  If we find style 
properties, we convert them to fontconfig properties and use the part 
preceeding the ',' or '-' as family name.  If we don't match any style 
properties, we use the whole fontname as family name.  It might make 
sense to substitute '-' for ' ' in the family name before matching, I'm 
not sure.

But there is no right to do this, it's all black magic... we just need 
to reasonable well.  If there's some common case we don't handle, we can 
always tune the heuristics down the road.

>>Martin Kretzschmar did point out to me, though, that the patch removes
>>the GlobalParams::setupBaseFontsFc() function from evince, which
>>initializes the 14 standard fonts using fontconfig.  But reading the
>>kpdf source, it looks like you don't initialize the standard fonts at
>>all (i.e. you don't call GlobalParams::setupBaseFonts() either), but
>>handle all font references through the general font matching
>>algorithm... correct?
> 
> No, we do globalParams->setupBaseFonts(NULL); on part.cpp but i have just 
> remove it and i get the same substitutions that xpdf has (displayFontTab), 
> you can test that on your system with the test program i sent
> ./fonttest Times-BoldItalic gets me n021024l.pfb file. (that is with 
> -DWEIRD_FUN) probably thanks of my fontconfig setup? (i did not edit it)

Well, that's good news.  So you would be happy with not initializing the 
standard fonts at all in kpdf?

cheers,
Kristian