Bug 78990

Created attachment 99454 [details]
screenshot

Created attachment 99456 [details]
Corrected pdf example

The previous pdf embedded the wrong font, ignore.

I've uploaded a corrected PDF as there was a mixup with the fonts I used
for the example.

In brief, the two fonts should render identically, and do when zoomed
in close enough. However when viewed so the type is small one renders
much darker then the other, and the differece seems only to be that one
is embedded as truetype and the other as CID.

> I've uploaded a corrected PDF as there was a mixup with the fonts I used
> for the example.

I’m interacting with bz via email, and missed the additional comments,
including that update, when I first replied.  Appologies.

b> In brief, the two fonts should render identically, and do when zoomed
b> in close enough.

There is no such thing as identical hinting between CFF and glyf fonts.

How did you generate the instructions for the glyf (aka ttf)? Fontforge?
Ttfautohint?  By hand?

I see that the metrics are different.  Did you lose kerning?

I expect a pdf viewer to disable all hinting for the rendered page.
AFAIK evince follows that philosophy.  But if not, freetype added a new
hinting engine in that last year, contributed by Adobe, which darkens
glyphs at low resolutions.  Perhaps that explains what you see?

Or, the difference between how cubic and quadratic splines render might
be noticible at those p/ex sizes.

> There is no such thing as identical hinting between CFF and glyf fonts.

Point taken. I'll rephrase to: They should render similarly enough so it 
doesn't appear as if one is black and the other regular at low zoom if
they render identically when zommed in.


> How did you generate the instructions for the glyf (aka ttf)? Fontforge?
> Ttfautohint?  By hand?

I've tried:
- straight otf->ttf via fontforge
- running ttfauthint on the ttf
- converting the results of ttfauthint back into otf via fontforge
- running authint from the adobe FDK on the otf.

and comapring against each other. It gets a little tricky (XeLatex 
and fontconfig have a will of their own) but so far the rendering is 
consistently different between otf and ttf, and so far it's by far
the dominating factor in the appearence of the rendered page.

> I see that the metrics are different.  Did you lose kerning?

You probably meant the faulty pdf. The answer is still: 
possibly, I didn't check (I'm a fontforge novice). 

Though kerning can affect color the difference in visual appearence looks to
me as being on the level of individual glyphs. 

Since the difference disappears when zooming in, I took that as a hint (pardon)
that the issue has to do with hinting, but perhaps it's something else
I'm unaware of.

The "mistaken" screenshot is actually quite close to the weight difference 
I'm seeing, even with the wrong fonts (still otf vs. ttf rendering).

>I expect a pdf viewer to disable all hinting for the rendered page.
>AFAIK evince follows that philosophy.  But if not, freetype added a new
>hinting engine in that last year, contributed by Adobe, which darkens
>glyphs at low resolutions.  Perhaps that explains what you see?

Using okular, I've disabled hinting (which does make a slight
visual difference) but the prononounced effect I described remains. 
otf is black ttf is regular.

Wouldn't you expect it to act similarly on both fonts? it's really
not a subtle visual difference I'm seeing.

> Or, the difference between how cubic and quadratic splines render might
> be noticible at those p/ex sizes.

You got me there. You're refering to a difference in how the glyph curves
are represented in each font format? Doesn't the fact that acrobat reader 
doesn't have this issue suggest otherwise? Is there a way to tell if it's patented magic on behalf of adobe or a bug in poppler's rendering (or somewhere else in the stack)?

I'm attached a new screenshot of the appearence of the pdf zoomed out
and close up taken from okular. evince looks much the same.

Created attachment 99467 [details]
Screenshots from okular with differing zoom factors

[This went to the list instead of to bz -JimC]

That new screenshot confirms that the metrics changed.

pdftocairo and pdftoppm also exibit the anomaly.

mudraw does not seem to.

All use freetype to render the fonts.

But using ftview on the two fonts also shows the cff font darker than
that glyf version.  Unless both are rendered with forced auto hinting.

That strongly suggests that it is a freetype issue.

Try the full fonts side by side in ftview, comparing the hinting modes
and gama.  Either both in the same instance, using n and p to switch
between them, or each in its own ftview.

Created attachment 99600 [details]
Comparing ttf and otf using ftview - note engine difference

I have and I can confirm the freetype renders the ttf and otf files
differently. You previously mentioned that Adobe contributed a rendering 
engine to freetype and indeed ftview shows that different engines are
used to render different fonts by type, I attached a screenshot.

Many thanks for helping to narrow down the issue. I'll open a ticket
on the freetype tracker.

Freetype ticket: https://savannah.nongnu.org/bugs/index.php?42406

Retitled issue. Was: "PDF Text hinting does not work for embedded otf fonts (CID Type 0C), does work for truetype."

Created attachment 100597 [details]
Rendering of cff vs. ttf with FT2 No_Stem_Darkening = True

The freetype devs confirme that the stem darkening used by the 
adobe engine is the cause of the overly dark rendering of cff fonts
I reported.

See issue:
https://savannah.nongnu.org/bugs/index.php?42406

Stem darkening is turned on by default, and assumes (As I understand it)
that poppler properly handles "gamma", whatever that means in this context,
which if not done has the effect of displaying very dark glyphs at small type
size.

The freetype library has an option for disabling stem darkening,
as well as several numerical parameters for controlling it, whose
defaults the FT devs plan to change in the future when stem darkening
will be added to the other (ttf) engine as well.

See:
http://www.freetype.org/freetype2/docs/reference/ft2-cff_driver.html#FT_CFF_HINTING_XXX

By turning off stem darkening in the constructor for
CairoOutputDev (And also in splash hinting control, I do not know
which had the effect):

```
CairoOutputDev::CairoOutputDev() {
  ...

  FT_Bool     no_stem_darkening = true;
  FT_Property_Set( ft_lib, "cff",
                            "no-stem-darkening", &no_stem_darkening );
```

the issue has largely been resolved for me, there's still a slight difference
perhaps, but only when comparing side to side. I've attached a screenshot which you can compare to the original I attached to the issue.

I'd like to suggest that poppler turn stem darkening off by default,
since it would:

1) Eliminate the problem of the dark glyphs.
2) Make ttf and ctf render in the same way (if they are mixed in a 
document for example).
3) Restore (roughly) the rendering behavior to what it was been
before the relatively recent introduction of the adobe engine.

If not, at least exposing an API for setting it by clients (Evince, okular)
would enable downstream to scratch their own itch.

Noting that since freetype releases are not often and this part of
the library seems to be in an interim state since one kind of font 
supports darkening it, the other does not, it might be a while before
this is resolved over there (though they were very helpful).

I also came across this issue, when mixing LaTeX Math fonts (type1) with OTF text fonts. I think the correct way to disable stem darkening is in the splash FT engine. 

I attached a small patch for poppler git head to this bug.

Created attachment 117464 [details] [review]
disable stem darkening

using freetype 2.5.2 as shipped in ubuntu i don't ever see any difference in the rendering of the two lines of https://bugs.freedesktop.org/attachment.cgi?id=99456 and using ./qt4/demos/poppler_qt4viewer at any zoom.

Do i need a newer freetype to see the difference?

Interesting little note: MuPDF does render the pdf example as expected here, using the system freetype library as poppler does. I also did not find any special handling of stem darkening in the mupdf sources. 

So does poppler try to improve contrast by playing with gamma values? The freetype people seem to call this "misusing" the library.

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