Your patches do not apply on master.

I made them against the latest stable release, 0.18.4. When I have time I'll look into rebaseing them to master...

Created attachment 60451 [details] [review]
Patch for handling of Standard-14 fonts on Windows

Patch made against master/ad8785b053aa115b593b2f20073e2989d59a77c9

I filed the difference between ZapfDingbats and wingding.ttf
in another item: https://bugs.freedesktop.org/show_bug.cgi?id=48040 ,
but I have not compared s050000l.pfb versus symbol.ttf.
Thank you for pointing out. 
But, the description "(e.g., the glyphs for 'f', 'j', 'v')" is
not reliable to specify the glyph. Using glyph name (fortunately,
both of s050000l.pfb and symbol.ttf have glyph names, and their
naming convention is almost same) would be more reliable.

--

And, I think this patch is mainly designed to import the fonts
bundled to Ghostscript automatically & easily. And, this patch
assumes many things; both of Ghostscript and some binary using
poppler are installed to the same directory tree, thus,
it is assumed that the directory of the fonts bundled to Ghostscript
can be obtained by replacing "/bin/blahblahblah" (the tail of
pathname of running executable) by "/share/fonts/type1/gsfonts".
Maybe it would be reasonable assumption for the people who are
using Cygwin environment and who does not build any binaries
by themselves (so all binary executables are installed to same
folder), but it would not be so portable for MinGW or non-Unix
oriented applications.

If people using poppler on Win32 environment want to co-use
Ghostscript, configure script should detect its directory.
The heuristic detection based on Unix file system structure
is not good idea. I my opinion, if Ghostscript fonts should be
used, the user can install PFB fonts into Microsoft Windows
directly. Recent Ghostscript on Microsoft Windows would be able
to scan the system font directory, so the installation of the
Ghostscript fonts to the operating system would not be so
problematic.

Anyway, hardwired font directory list is existing in Unix part
(and I think it is not good idea), too. I will try to set it
up by configure script.

First of all, thanks that one more tries to support the windows font substitution at all. Other than on unix platforms i.e. with fontconfig, on Windows every program itself is responsible to find and / or install every font which it needs. Because we have no Windows installer for poppler, we only have the choice to find a suitable font, if it is not embedded in the PDF.
But to Your patch:
1. It will not work at all: Because the library first calls GlobalParams::findFontFile and then GlobalParams::findSystemFontFile, setupBaseFonts is first called with parameter NULL, so Your attempt fo find ghostscript fonts will not succeed. At least You have to patch the call of setupBaseFonts in GlobalParams::findFontFile, too.
2. I personally don't like the call of GetModuleFileName in get_poppler_fontdir: it will returns the path of the executable file, and because we have no installer, and i.e. call it under the Visual studio, You need to install the fonts twice, one time under "Debug" and one time under "Release". But at least You should not search for "bin" only (that's Unix style), but You shoud remove "Debug" and "Release", too. And why Do You don't use the define "POPPLER_DATADIR" and use a font directory under it?
3. Of course we could search the registry for a ghostscript installation, it's quite easy, too, and look for the GS_LIB-key, it already has a pointer to the ghostscript installed fonts. But unfortunately ghostscript removes its font installer, so also here You have to download the ghostscript fonts manually and have to put them in the correct directory.
4. On my system I have a true type font ZapfDingbats, installed by ScanSoft, and I would like to use this one. Why does PFB fonts overrules TTF fonts?
Therefore I would like to agree to mpsuzuki: Why don't install all needed fonts in the Windows font directory. The most program (at least MicroSoft, and even if most people don't like it, it's a Windows system) install it there.

Thanks for your insights. I'm not a font expert myself, but have seen some reports for TeXworks (which uses poppler) that the Symbol font is rendered incorrectly on Windows. As a test-case, you could use http://texworks.googlecode.com/svn/trunk/testcases/base14-fonts.pdf (which references all 14 standard fonts). What I did there was to simply render text (hence my mentioning the characters that produce problems).

Regarding the patch:
I modeled the function looking for the font directory after get_poppler_datadir() in poppler/GlobalParams.cc which does very much the same thing for locating the poppler-data directory. It does not depend specifically on ghostscript - I only chose the folder name to correspond to the *nix name (as get_poppler_datadir() does), but it is rather arbitrary. Fonts could be taken from ghostscript or other sources (e.g., http://www.ctan.org/tex-archive/fonts/urw/base35). All this patch does is provide an additional directory to search for fonts.

bin/ is only stripped if it exists, as is done in get_poppler_datadir().

Regarding co-using ghostscript: if ghostscript fonts are installed in the Windows system directory, they should be picked up by poppler automatically, I assume. Being able to re-use the fonts in an existing ghostscript installation (that does not touch the system directory) would be nice, but is not what this patch is intended for. It is intended for an application using poppler to be standard-compliant even if ghostscript is not installed (which is kind of the point of a pdf viewer, IMO, to not depend on essentially another viewer).
BTW: using an existing ghostscript installation would only work reliably if (a) the application using poppler bundles ghostscript or (b) the user build the application himself. Otherwise, there is no guarantee if and where ghostscript may be installed.

Exposing the path to the configure script is probably a good idea.

PS: I'm using MinGW myself.

(In reply to comment #6)
> Thanks for your insights. I'm not a font expert myself, 

Welcome to the club :-)

> but have seen some
> reports for TeXworks (which uses poppler) that the Symbol font is rendered
> incorrectly on Windows. As a test-case, you could use
> http://texworks.googlecode.com/svn/trunk/testcases/base14-fonts.pdf (which
> references all 14 standard fonts). What I did there was to simply render text
> (hence my mentioning the characters that produce problems).
> 
> Regarding the patch:
> I modeled the function looking for the font directory after
> get_poppler_datadir() in poppler/GlobalParams.cc which does very much the same
> thing for locating the poppler-data directory. It does not depend specifically
> on ghostscript - I only chose the folder name to correspond to the *nix name
> (as get_poppler_datadir() does), but it is rather arbitrary. Fonts could be
> taken from ghostscript or other sources (e.g.,
> http://www.ctan.org/tex-archive/fonts/urw/base35). All this patch does is
> provide an additional directory to search for fonts.

Oh, I missed that: I never used cmake, it was to confusing for me to get it running togethet with VisualC, therefore I oversee to define ENABLE_RELOCATABLE. But then You should do it in the same way, i.e. introduce a POPPLER_FONTDIR and then something like
#undef POPPLER_FONTDIR
#define POPPLER_FONTDIR get_poppler_fontdir ()
And of course get_poppler_fontdir should be bracketed by "#if ENABLE_RELOCATABLE", too.

> 
> bin/ is only stripped if it exists, as is done in get_poppler_datadir().

Yes, I see that, I only ask to remove then "Debug" and "Release", too. Of course should be also done then in get_poppler_datadir, too.
> 
> Regarding co-using ghostscript: if ghostscript fonts are installed in the
> Windows system directory, they should be picked up by poppler automatically, I
> assume. Being able to re-use the fonts in an existing ghostscript installation
> (that does not touch the system directory) would be nice, but is not what this
> patch is intended for. It is intended for an application using poppler to be
> standard-compliant even if ghostscript is not installed (which is kind of the
> point of a pdf viewer, IMO, to not depend on essentially another viewer).
> BTW: using an existing ghostscript installation would only work reliably if (a)
> the application using poppler bundles ghostscript or (b) the user build the
> application himself. Otherwise, there is no guarantee if and where ghostscript
> may be installed.

Sorry, but I don't think so: looking for registry key and if find look into that directory, too, will work in all cases :-). But nevertheless, it was probably only a kiddy idea...

> 
> Exposing the path to the configure script is probably a good idea.

Yes, for MinGW users. On a pure Windows system there is no way to use a "configure" script. When I started with poppler, I used MinGW, too, but in some way it breaks my Visual C compilations, as far as I remember, therefore I removed it and create my project files for Visual C manually..

> 
> PS: I'm using MinGW myself.

I guessed that already :-)

Created attachment 60522 [details]
Changes mentioned in comment 7

I think, I wasn't very understandable in my comment 7. But it's quite easy to make the few changes in You patch. So I made it here. Do You think, You can live with that until we got a better configure solution?

Created attachment 60523 [details] [review]
Once again

Sorry, I forgot to mark it as patch

(In reply to comment #5)
> 3. Of course we could search the registry for a ghostscript installation, it's
> quite easy, too, and look for the GS_LIB-key, it already has a pointer to the
> ghostscript installed fonts. But unfortunately ghostscript removes its font
> installer, so also here You have to download the ghostscript fonts manually and
> have to put them in the correct directory.

BTW, it is slightly off-topic discussion, I have a concern about
base PDF/PS font availabilities in future Ghostscript package.
Ghostscript has a hook to embed fonts into its binary executable
or shared library (I remember making CPIO archive of the fonts
and put it in the binary), thus, it would be possible for Ghostscript
to work without the installation of the font files.

# I guess this hook is designed for the proprietary customers who
# don't want to expose the bundled fonts to the outside of the
# Ghostscript.

I think, Unix distributors won't rely on this hook, because there
are many software who want to use PostScript Type1 fonts and embedding
the font files to Ghostscript executable would be just an inflation
of the file size. But I'm not sure about how Windows packages would
be designed.

(In reply to comment #7)
> > bin/ is only stripped if it exists, as is done in get_poppler_datadir().
> 
> Yes, I see that, I only ask to remove then "Debug" and "Release", too. Of
> course should be also done then in get_poppler_datadir, too.

Excuse me, "Debug" and "Release" are the directories that Microsoft
Visual Studio stores the built binaries in its project tree?
The stripping of "Debug" and "Release" is for the developers testing
poppler or some applications using poppler, with VS?

(In reply to comment #11)
> (In reply to comment #7)
> > > bin/ is only stripped if it exists, as is done in get_poppler_datadir().
> > 
> > Yes, I see that, I only ask to remove then "Debug" and "Release", too. Of
> > course should be also done then in get_poppler_datadir, too.
> 
> Excuse me, "Debug" and "Release" are the directories that Microsoft
> Visual Studio stores the built binaries in its project tree?
> The stripping of "Debug" and "Release" is for the developers testing
> poppler or some applications using poppler, with VS?

Yes, that are the default subdirectories in VS. The directory names are changable, but normally noone will change these names. So this problably only helps me :-)

When I was writing about the replacement of hardwired pathnames
by configured strings for Ghostscript directories in GlobalParams.cc,
I was thinking about Unix systems. But...

(In reply to comment #7)
> (In reply to comment #6)
> > Exposing the path to the configure script is probably a good idea.
> 
> Yes, for MinGW users. On a pure Windows system there is no way to use a
> "configure" script. When I started with poppler, I used MinGW, too, but in some
> way it breaks my Visual C compilations, as far as I remember, therefore I
> removed it and create my project files for Visual C manually..

This is very enlightening comment and I should reconsider.

(In reply to comment #5)
> 3. Of course we could search the registry for a ghostscript installation, it's
> quite easy, too, and look for the GS_LIB-key, it already has a pointer to the
> ghostscript installed fonts. But unfortunately ghostscript removes its font
> installer, so also here You have to download the ghostscript fonts manually and
> have to put them in the correct directory.

I think this idea (searching the font directory of Ghostscript by
the registry) is better than playing with the pathname of poppler
executables. Just I've scratched a small tool to search the registry
keys named "XXX Ghostscript\XXX\GS_LIB" and collect the directories
from their values into GooList object.

Created attachment 60572 [details] [review]
Patch to add "Win32DetectGS" demo

Patch to add "Win32DetectGS" demo, autogen.sh is needed.
The result would be saved as poppler-x.y.z/poppler/Win32DetectGS.exe.

Created attachment 60573 [details]
Win32DetectGS.exe binary (built by MinGW)

Binary of Win32DetectGS.exe built by MinGW.

(In reply to comment #15)
> Created attachment 60573 [details]
> Win32DetectGS.exe binary (built by MinGW)
> 
> Binary of Win32DetectGS.exe built by MinGW.

Nearly, but not complete. It gave me the following output:
Check the registry data for 'SOFTWARE\GPL Ghostscript\8.70'
Check the registry data for 'SOFTWARE\GPL Ghostscript\9.04'
Check the registry data for 'SOFTWARE\GPL Ghostscript\9.05'
gsFontDirs[0]   F:\Program Files\gs\gs8.70\lib
gsFontDirs[1]   E:\gs\gs9.04\bin
gsFontDirs[2]   E:\gs\gs9.04\lib
gsFontDirs[3]   E:\gs\gs9.05\bin
gsFontDirs[4]   E:\gs\gs9.05\lib
But my gs fonts are installed under E:\gs\gs9.05\fonts, and the registry key also points to it:
E:\gs\gs9.05\bin;E:\gs\gs9.05\lib;E:\gs\gs9.05\fonts

Created attachment 60584 [details]
Win32DetectGS.exe binary (built by MinGW), with a few debug message

Thank you for testing. Here I added a few debug messages.
Now my Windows machines have only Ghostscript 8.x,
I will test other configuration in tomorrow.

Check the registry data for 'SOFTWARE\GPL Ghostscript\8.70'
HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\8.70 GS_DLL='F:\Program Files\gs\gs8.70\bin\gsdll32.dll'...ignored, because not GS_LIB
HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\8.70 GS_LIB='F:\Program Files\gs\gs8.70\lib;F:\Program Files\gs\fonts'...split by ';'
  add F:\Program Files\gs\gs8.70\lib
Check the registry data for 'SOFTWARE\GPL Ghostscript\9.04'
HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.04 GS_DLL='E:\gs\gs9.04\bin\gsdll32.dll'...ignored, because not GS_LIB
HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.04 GS_LIB='E:\gs\gs9.04\bin;E:\gs\gs9.04\lib;E:\gs\gs9.04\fonts'...split by ';'
  add E:\gs\gs9.04\bin
  add E:\gs\gs9.04\lib
Check the registry data for 'SOFTWARE\GPL Ghostscript\9.05'
HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.05 GS_DLL='E:\gs\gs9.05\bin\gsdll32.dll'...ignored, because not GS_LIB
HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.05 GS_LIB='E:\gs\gs9.05\bin;E:\gs\gs9.05\lib;E:\gs\gs9.05\fonts'...split by ';'
  add E:\gs\gs9.05\bin
  add E:\gs\gs9.05\lib
gsFontDirs[0]   F:\Program Files\gs\gs8.70\lib
gsFontDirs[1]   E:\gs\gs9.04\bin
gsFontDirs[2]   E:\gs\gs9.04\lib
gsFontDirs[3]   E:\gs\gs9.05\bin
gsFontDirs[4]   E:\gs\gs9.05\lib

(In reply to comment #18)
> HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\8.70 GS_LIB='F:\Program
> Files\gs\gs8.70\lib;F:\Program Files\gs\fonts'...split by ';'
>   add F:\Program Files\gs\gs8.70\lib
> Check the registry data for 'SOFTWARE\GPL Ghostscript\9.04'

Oops! There is a mistake to pick the last item from
a semicolon-separated list.

Created attachment 60594 [details]
Win32DetectGS.exe binary (built by MinGW), off-by-one bug fixed

The off-by-one bug in previous demos is fixed.

Created attachment 60595 [details] [review]
Patch to add "Win32DetectGS" demo (off-by-one bug is fixed)

The patch to build 60594 binary.

(In reply to comment #5)
> 4. On my system I have a true type font ZapfDingbats, installed by ScanSoft,
> and I would like to use this one. Why does PFB fonts overrules TTF fonts?

In addition, the preference is by the hardwired filename, not by font file format!

# If the TrueType fonts were unreliable resource, as earlier Ghostscript,
# or the days of patented hinting problem, the prioritization to PS Type1
# fonts would be reasonable. But I think it is not applicable to the
# recent poppler...

Yet I'm not sure about the frequency of this situation ("I have genuine typeface
for some base 14/35 fonts, but poppler prioritizes non-genuine substitution
fonts!"), but I think this comment is reasonable. And, this is not Win32
specific issue. Mac OS X may have similar issue, I'm afraid (there would be
genuine Helvetica, but they would not be used?).

However, the "genuinity" of the fonts cannot be validated by poppler, except
of the cases that the fonts are detected to be manufactured by Adobe or some
companies producing the fonts for PS or PDF engines (detection would be possible
by checking the entries in 'name' table).

In my personal opinion, the external configuration file to control such ambiguity
at users own risk would be the easiest solution. But considering the external
configuration files are not welcomed solution for poppler maintainers,
the compromising point would be:

0) Having the list of the familyname/PostScript name and another
list of the filenames for base14/35 fonts. The list should be
ordered from the higher priority to lower priority. Also a blacklist
of the font to be avoided should be prepared.

1) Lookup the font by the familyname or PostScript name.
1') If the found font is blacklisted (how to identify?),
skip to next candidate.

2) If no font with compatible(?) familyname/PostScript name
is found, lookup the font by the list of the filenames.

Please comment.

(In reply to comment #22)
Okay, Win32DetectGS.exe now works as expected. Regarding Your
> Please comment.
I have an open mind about what solution will be implemented, but as Stefan told: According to the PDF specs, every PDF viewer must be able to handle 14 standard
fonts even if they are not embedded. We are able to do it under Unix with fontconfig, but under Windows we have at least a problem with the ZapfDingbats.
It's not completely true that poppler has no external files. At least the CID maps for CJK fonts are in the poppler data dir. So I wouldn't care, if it is recommended to install the fonts under Windows there too. Would also be nice if the fonts could be delivered with the poppler data dir, but that's probably a vain wish. At least I myself don't want to discuss that with Leonard or anybody else.

(In reply to comment #23)
> So I wouldn't care, if it is
> recommended to install the fonts under Windows there too. Would also be nice if
> the fonts could be delivered with the poppler data dir, but that's probably a
> vain wish. At least I myself don't want to discuss that with Leonard or anybody
> else.

Hmm, you want something like "/usr/share/poppler/fonts" directory to
store the fonts to be searched at the highest priority (but you don't
think it's welcomed idea)? I think it's slightly different issue from
user configuration file and worth to discuss.

If you exclude the idea, do you have any idea to give higher priority
to your genuine ZapfDingbats?

# My idea (without external configuration file) is already described
# in comment 22.

(In reply to comment #23)
> Would also be nice if the fonts could be delivered with the poppler data dir,
> but that's probably a vain wish.

There is nothing stopping anyone providing a windows installer for poppler from including the ghostscript fonts (http://sourceforge.net/projects/gs-fonts/). The fonts are GPL.

I think that searching for a ghostscript installation is the wrong approach. It is bad enough that pdftohtml has a dependency on gs without introducing another one.

My preferred solution for font substitution on windows is:

1. First check poppler_data_dir/fonts
2. If not found, call CreateFont/CreateFontIndirect/CreateFontIndirectEx.

This allows anyone creating a poppler installer for windows to either install the gs fonts to poppler_data_dir/fonts to ensure they are the first match for the standard 14 or to install the fonts to the windows font directory.

The win32 CreateFont function is the windows equivalent of fontconfig. It finds the font that is the closest match for the specified characteristics. This is required to support substituting non Standard-14 fonts. Similar to Linux it is up to the user to ensure either the non standard font is installed or a substitution is configured in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes.

I'm not sure why the code currently has hard coded font file names that it searches the system font directory for. It would be better to use the windows api to find the best matching font and use GetFontData to read the font file.

(In reply to comment #25)
> (In reply to comment #23)
> > Would also be nice if the fonts could be delivered with the poppler data dir,
> > but that's probably a vain wish.
> 
> There is nothing stopping anyone providing a windows installer for poppler from
> including the ghostscript fonts (http://sourceforge.net/projects/gs-fonts/).
> The fonts are GPL.
> 
> I think that searching for a ghostscript installation is the wrong approach. It
> is bad enough that pdftohtml has a dependency on gs without introducing another
> one.

Excuse me, do you think "lookup GS_LIB in the system registry is bad idea",
OR "lookup the gsfont directory by pathname juggling is bad idea"? Both
are bad ideas?

Anyway, I was going to ask Stefan about the frequency of the situation that
gsfonts are installed in the gs- or Unix-like directory structure, without
gs itself (the original proposal was lookup share/fonts/type1/gsfonts.

> My preferred solution for font substitution on windows is:
> 
> 1. First check poppler_data_dir/fonts
> 2. If not found, call CreateFont/CreateFontIndirect/CreateFontIndirectEx.
> 
> This allows anyone creating a poppler installer for windows to either install
> the gs fonts to poppler_data_dir/fonts to ensure they are the first match for
> the standard 14 or to install the fonts to the windows font directory.
> 
> The win32 CreateFont function is the windows equivalent of fontconfig. It finds
> the font that is the closest match for the specified characteristics. This is
> required to support substituting non Standard-14 fonts. Similar to Linux it is
> up to the user to ensure either the non standard font is installed or a
> substitution is configured in HKLM\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\FontSubstitutes.

Yes, yes, yes. I'm doing some experiments.
https://www.codeblog.org/blog/mpsuzuki/20120416.html
Although getting the font file images via GDI is not so simple
(CreateFont() does not bring us to there, more hooks are needed),
it would be better than the juggling of pathname & familynames.
However, the stabilization of the font detection by using GDI
features would spend more time.

> I'm not sure why the code currently has hard coded font file names that it
> searches the system font directory for. It would be better to use the windows
> api to find the best matching font and use GetFontData to read the font file.

Indeed.

Sorry, I posted before finishing my comments.

(In reply to comment #25)
> 1. First check poppler_data_dir/fonts

I guess this is what Thomas expects, and I agree.
The code doing such must not be fragile (in comparison
with my unaccustomed Win32 programming :-)).

However, a support for Windows "shortcut" would be
expected to prevent the duplications of the font files.

(In reply to comment #26)
> Excuse me, do you think "lookup GS_LIB in the system registry is bad idea",
> OR "lookup the gsfont directory by pathname juggling is bad idea"? Both
> are bad ideas?

Both are bad ideas. We should not be depending on gs to be installed to find our fonts. The gs fonts are less than 5MB. The space is not an issue. And if anyone doesn't want the fonts installed twice they should install them to the windows font directory. The windows font directory is the only place that fonts should be shared between applications.

What happens when the user uninstalls gs leaving poppler without the standard 14 fonts?

> Yes, yes, yes. I'm doing some experiments.
> https://www.codeblog.org/blog/mpsuzuki/20120416.html
> Although getting the font file images via GDI is not so simple

GetFontData will provide access to ttf/otf/type1 font images. It is used by cairo, libre office and many other applications.

> (CreateFont() does not bring us to there, more hooks are needed),
> it would be better than the juggling of pathname & familynames.

What else is required? The other option is to enumerate the fonts and do our own font matching like pango and firefox (the two examples I am familiar with). But I can't see that this is necessary for poppler.

> However, the stabilization of the font detection by using GDI
> features would spend more time.

Yes, doing it the right will take it bit more work but in the mean time we should not add hacks like searching for gs. If we do that we are stuck having to support that feature. What we can easily do now is add support for searching poppler_data_dir/fonts first.

(In reply to comment #28)
> Yes, doing it the right will take it bit more work but in the mean time we
> should not add hacks like searching for gs. If we do that we are stuck having
> to support that feature. What we can easily do now is add support for searching
> poppler_data_dir/fonts first.

And what is already implemented with the already uploaded patch :-) With the only difference I used the subdir name from Stefan, poppler_data_dir/share/fonts/type1/gsfonts, but that could be easily changed without creating a new patch...

(In reply to comment #29)
> (In reply to comment #28)
> > Yes, doing it the right will take it bit more work but in the mean time we
> > should not add hacks like searching for gs. If we do that we are stuck having
> > to support that feature. What we can easily do now is add support for searching
> > poppler_data_dir/fonts first.
> 
> And what is already implemented with the already uploaded patch :-) With the
> only difference I used the subdir name from Stefan,
> poppler_data_dir/share/fonts/type1/gsfonts, but that could be easily changed
> without creating a new patch...

As well as changing the subdir to "fonts" the patch should also call get_poppler_datadir() and append "\\fonts" instead of duplicating the code in get_poppler_datadir(). It should also get rid of the Debug/Release stuff. That is where the compiled executable is, not where it is installed.

And it would be a good idea for the patch to update the README or add a README.win32 explaining where the poppler data dir is located and what to put in it.

(In reply to comment #30)
> As well as changing the subdir to "fonts" the patch should also call
> get_poppler_datadir() and append "\\fonts" instead of duplicating the code in
> get_poppler_datadir(). 

I agree!

> It should also get rid of the Debug/Release stuff. 

Okay, this only helps me, using it under Visual Studio to have to different versions, release and debug. So I don't care if anyone removes it.

(In reply to comment #28)
> > (CreateFont() does not bring us to there, more hooks are needed),
> > it would be better than the juggling of pathname & familynames.
> 
> What else is required? The other option is to enumerate the fonts and do our
> own font matching like pango and firefox (the two examples I am familiar with).
> But I can't see that this is necessary for poppler.

I think the latter (our own font matching) is expected.

If we pass the familyname of available fonts to CreateFont(),
it would not be so troublesome. But if we pass the familyname
of unavailable fonts, the result is unreliable.

fontconfig checks the scripts supported by the fonts with
various informations, like, all defined character codepoints,
OpenType script/language tags, etc. But the charset/script/
language property we can pass to CreateFont() is too small;
only a codepage info in LOGFONT.lfCharSet.

LOGFONT.lfCharSet is often insufficient key to distinguish
the fonts for Japanese, Chinese, Taiwanese market.
When I specify GB2312_CHARSET to pickup Simplified Chinese font,
still Japanese fonts like "MS UI Gothic" can be listed by
EnumFontFamiliesEx() (nothing to say, Japanese fonts lack most
of simplified characters used in GB2312).

Thus, the font specification only by LOGFONT level is unsafe,
I think.

(In reply to comment #32)
> (In reply to comment #30)
> > As well as changing the subdir to "fonts" the patch should also call
> > get_poppler_datadir() and append "\\fonts" instead of duplicating the code in
> > get_poppler_datadir(). 
> 
> I agree!
> 
> > It should also get rid of the Debug/Release stuff. 
> 
> Okay, this only helps me, using it under Visual Studio to have to different
> versions, release and debug. So I don't care if anyone removes it.

In summary, future poppler on Win32 is expected to search the fonts in
${prefix}/share/fonts ? or, ${prefix}/share/poppler/fonts ?

In current automake definitions for poppler, POPPLER_DATADIR is
${prefix}/share/poppler , and cMap, cidToUnicode, nameToUnicode
and unicodeMap subdirectories are stored. Are we going to add
"fonts" directory to there?

(In reply to comment #34)
> In summary, future poppler on Win32 is expected to search the fonts in
> ${prefix}/share/fonts ? or, ${prefix}/share/poppler/fonts ?
> 
> In current automake definitions for poppler, POPPLER_DATADIR is
> ${prefix}/share/poppler , and cMap, cidToUnicode, nameToUnicode
> and unicodeMap subdirectories are stored. Are we going to add
> "fonts" directory to there?

Just add a "fonts" directory at the same level as the cMap, cidToUnicode, nameToUnicode and unicodeMap subdirectories. ie

${prefix}/share/poppler/cMap
${prefix}/share/poppler/cidToUnicode
${prefix}/share/poppler/fonts

etc

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/300.