#847935 MICRO sign does not show

#847935#5
Date:
2016-12-12 14:04:23 UTC
From:
To:
on the website https://xmlgraphics.apache.org/fop/examples.html you can
download https://xmlgraphics.apache.org/fop/fo/fonts.fo.pdf

which is a PDF file with character charts.

For the fonts Helvetica and Times Roman the micro sign µ is not
visible with PDF previewers "atril", also not on "xpdf". But for the
font Courier it is visible.

by the command:
gs -sDEVICE=pngmono -sOutputFile=test%d.png fonts.fo.pdf </dev/null
you can see the micro signs.

I have no idea if this bug is assigned to the correct package though.

you can copy the invisible micro sign on the "atril" PDF previewer to
clipboard and paste it into a terminal, where it will correctly be
visible as a micro sign.

cu
Erik

#847935#10
Date:
2016-12-28 08:10:16 UTC
From:
To:
Am Montag, den 12.12.2016, 15:04 +0100 schrieb Erik Thiele:

What makes you believe that the fonts from fonts-freefont-ttf are used
to render text that is supposed to be set in Helvetica or Times in PDFs
? Usually, the fonts from the gsfonts package are used for that.

 - Fabian

#847935#15
Date:
2017-01-09 13:21:59 UTC
From:
To:
Am Wed, 28 Dec 2016 09:10:16 +0100
schrieb Fabian Greffrath <fabian@debian.org>:

I have no clue really. I also do not know how to find out which font is
used. I only found that our workers preview PDF files and instead of
4µm they read 4m which is 4 meters instead of 4 micrometers. Thats
pretty bad...

Please someone find out where the problem is and reassign the bug
appropriately.

Thank you

Erik

#847935#20
Date:
2017-01-10 07:34:53 UTC
From:
To:
Hi Erik,

Erik Thiele wrote:

I think we can find this out. Please install the evince package and open
the affected PDF with Evince. It has a Properties->Font dialog box that
gives information about which font is used to substitute what font
requested by the PDF. There you will find the culprit.

Do you happen to have the fonts-texgyre package installed?

 - Fabian

#847935#25
Date:
2017-01-10 14:09:35 UTC
From:
To:
Hi


Am Tue, 10 Jan 2017 08:34:53 +0100
schrieb "Fabian Greffrath" <fabian@greffrath.com>:

I installed evince 3.14.1-2+deb8u1 amd64

in the attached screenshot "fontshot.png" you see in the background the
missing micro sign at µ. in the font dialog you mentioned you see
that TeXGyreHeros-Regular is used.

Yes, I have installed fonts-texgyre 20140520-1 all

Because you asked for this package, i deinstalled it. Afterwards the
Micro sign does show up correctly. I therefore attached the screenshot
"fontshot_without_texgyre_package.png".

Comparing the two screenshots you see
that /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf
does not show the micro sign

and /usr/share/fonts/X11/Type1/qhvr.pfb does show the micro sign.

Please someone decide if the problem is in fonts-texgyre or if the
problem is that this font is used for substitution and not a font with
working micro sign. I do not know, if fonts-texgyre must support the
micro sign.

Thanks for your support in this problem. I will now simply deinstall
fonts-texgyre on all hosts in our company.

cya
Erik

#847935#30
Date:
2017-01-12 11:25:08 UTC
From:
To:
Erik Thiele wrote:

Strictly speaking, it is a bug in the TeX Gyre OTF variant, because it
doesn't have the mu sign at the same code point (though it *does* have
one) as the Type1 variant. On the other hand, it is an OTF font, so it
doesn't even necessarily have to keep glyphs at the same code points as
the Type1 variant. Then it is a bug in fontconfig, because it substitutes
the TeX Gyre OTF variants for the original Base 35 Postscript fonts in
Type1 format (but it has already been decided that generally these are
proper replacements). And finally it is a bug in poppler, because it
renders text in an OTF font but expects its glyphs at the same code points
(i.e. following the same glyph naming schema) as in a Type1 font.

Although poppler isn't really the root of the problem, it is best to fix
it there. I re-assign this bug to poppler (I assume you are using the
version in stable, right?) and try to find a patch over the weekend for
upstream application.

Thanks,

 - Fabian

#847935#39
Date:
2017-01-12 15:32:53 UTC
From:
To:
Am Donnerstag, den 12.01.2017, 12:25 +0100 schrieb Fabian Greffrath:

Well, strange! I was just going to reproduce this issue on my own
testing/unstable system, but -- although I am using the fonts from
fonts-texgyre as substitutes for the base fonts -- I am not able to
reproduce this bug.

Well, there are 22 revisions between the poppler versions in stable and
testing, so I assume the bug has been fixed in between (it has not been
fixed in the fonts-texgyre package between stable and testing, I have
checked that).

So, not sure what to do with this bug report then...

 - Fabian

#847935#44
Date:
2017-01-12 17:05:19 UTC
From:
To:
Am Thu, 12 Jan 2017 16:32:53 +0100
schrieb Fabian Greffrath <fabian@debian.org>:

well. since the problem as you found out seems not to exist on
testing/unstable the remaining question is about what to do on stable.

hm. i think not many people have fonts-texgyre installed on stable.
otherwise this bug would be triggered by a lot of people maybe. So one
could argue this is an important bug if fonts-texgyre is installed, and
no bug if that package is not installed. I do not know what debian
policy says about such a problem regarding the possible fixes on
stable :-) I think poppler cannot be fixed on stable. maybe
fonts-texgyre could be removed from stable or the "wrong" font removed
from fonts-texgyre or added with different name and README.Debian sais
due to bug xxx you have to rename it manually to use that font. Hm.
Simply doing nothing is also not optimal. As for me the system worked
fine and one day I installed fonts-texgyre probably due to a maximum
tex installation and then suddenly many things broke regarding the micro
sign. Dunno.

#847935#49
Date:
2017-01-12 17:06:02 UTC
From:
To:
I believe this has been partially fixed in poppler with
https://bugs.freedesktop.org/96994, though it's probably still possible
to have missing characters, depending on the PDF and on which fonts are
chosen.

At one time I had attempted to improve on the way poppler chooses fonts,
but it's a little tricky to do that in a way that doesn't harm the
rendering of some documents.  Ideally more documents would embed the
fonts so these issues could be avoided.

#847935#54
Date:
2017-01-12 19:50:18 UTC
From:
To:
Am Donnerstag, den 12.01.2017, 11:06 -0600 schrieb Jason Crain:

This may very well be the patch that fixes the issue. Unfortunately, I
do not currently have a stable chroot at hand to see if it applies to
the package in stable and confirm if it indeed fixes the bug. :/

In my opinion, poppler should keep on relying on fontconfig and instead
get itself robust enough to porperly render even with the most unusual
fonts installed. And with commits like the one you pointed to I see
poppler on a good way towards this.

Anyway, PDFs with embedded documents are of course preferable.

Thanks!

 - Fabian

#847935#59
Date:
2017-01-13 19:43:36 UTC
From:
To:
Erik,

could you please do me a favour and test a package for me? Please find
the debdiff attached.

Please download this package and install it. You should install it
directly using dpkg and downgrade to the official package from stable
immediately once the tests are over:

https://people.debian.org/~fabian/jessie/libpoppler46_0.26.5-2+deb8u1.1_amd64.deb

Then, please install the fonts-texgyre package again and see if the
"mu" glyph on the test page you pointed to in your initial bug report
renders properly. Please make sure that the text is rendered with the
TeX Gyre OTF fonts.

Also, while at it, could you please check if the PDFs pointed to in
these bug reports render properly as well -- in Evince, that is, not in
e.g. Iceweasel's integrated PDF viewer.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773271

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807693

Thank you so much!

 - Fabian

#847935#64
Date:
2017-01-16 08:44:38 UTC
From:
To:
hi

I reinstalled fonts-texgyre

then I installed your package:

ii libpoppler46:amd64 0.26.5-2+deb8u1.1 amd64

then I found out that neither atril not evince is linking against
libpoppler by running ldd on those binaries. Some of my own software
links against libpoppler and there i find your library. maybe evince is
somehow loading libpoppler at runtime. or it does not use libpoppler!

anyway. running atril or evince does not show the micro sign.


cya
erik

#847935#69
Date:
2017-01-17 19:33:55 UTC
From:
To:
Poppler is linked to from the backend
/usr/lib/evince/4/backends/libpdfdocument.so.

I could be wrong about how poppler's build system works, but I think the
way the cairo backend is linked, you might need an updated
libpoppler-glib instead of libpoppler.

#847935#74
Date:
2017-01-17 20:10:49 UTC
From:
To:
Am Dienstag, den 17.01.2017, 13:33 -0600 schrieb Jason Crain:

That's sure possible, that would be this file:

https://people.debian.org/~fabian/jessie/libpoppler-glib8_0.26.5-2+deb8u1.1_amd64.deb

Thanks,

Fabian

#847935#79
Date:
2017-01-19 11:06:02 UTC
From:
To:
Erik,

Jason Crain wrote:

could you please repeat the tests with this package additionally installed:

https://people.debian.org/~fabian/jessie/libpoppler-glib8_0.26.5-2+deb8u1.1_amd64.deb

Thank you!

 - Fabian

#847935#84
Date:
2017-01-30 12:01:00 UTC
From:
To:
Fabian Greffrath wrote:


Sorry for the delay.

- I checked that my system is updated. debian_version is 8.7.
- first I checked that atril correctly displayed the micro sign.
- I installed fonts-texgyre
- I verified that atril does NOT display the micro sign.
- I installed libpoppler-glib8_0.26.5-2+deb8u1.1_amd64.deb from the
  link above. (md5 92f922b20537ab48da1d08920c75cd24) via dpkg -i.
- atril does now still correctly display the micro sign!

so as far as I can interpret the situation, your changes seem to fix
the problem


cya!
erik