Bug 80093

Created attachment 101172 [details] [review]
bring back ligature rendering with TeX Gyre Hermes

This little hack brings back ligature rendering entirely. It's only a proof of concept, but maybe it shows where the problem lies and hopefully helps solve the issue in a cleaner way.

Comment on attachment 101172 [details] [review]
bring back ligature rendering with TeX Gyre Hermes

Review of attachment 101172 [details] [review]:
-----------------------------------------------------------------

The concept is good.

It probably should work both ways (ie, look for /fi if /f_i is not found, et cetera).

Quoting Karl Berry on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742767

    The problem is that the ligatures are named
            f_i

Adobe wants it that way these days, as I understand it.  (Personally I
think they were terribly wrong to try to change something so fundamental
but, surprisingly, they didn't ask me. :)

See section 6 (or search for ligature) in
  http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification
(and probably other adobe documents too, that's just what I found first).

In practice, since rendering software is so random about it, perhaps
fonts should include ligatures under both names.  Sigh.

Comment on attachment 101172 [details] [review]
bring back ligature rendering with TeX Gyre Hermes

The following code would be better IMHO:

size_t const len = strlen (name);
if ((len == 02 || len == 03) && * name == 'f') 
{ /* interleave underscores */
char new_name [06] = { * name, '_', name [01], '_', name [02] };
new_name [ (len << 01) - 01 ] = 0;
codeToGID[i] = FT_Get_Name_Index(face, new_name);
}

Thank you very much, I was hoping for some more general code like this. However, please note that there are even more complex ligatures possible than just the f[f]? ones, like e.g. the o_f_f_i one mentioned in the Adobe document.

This code does both directions.

	const size_t namelen = strlen(name);

	if (!strchr(name, '_'))
	{
		// try with interleaved underscores
		int i;
		char *tempname = malloc ((2 * namelen + 1) * sizeof (*tempname));

		tempname[0] = name[0];
		for (i = 1; i < namelen; i++)
		{
			tempname[2*i]   = name[i];
			tempname[2*i-1] = '_';
		}
	}
	else
	{
		// try without interleaved underscores
		int i, j;
		char *tempname = malloc ((namelen + 1) * sizeof (*tempname));

		for (i = j = 0; i < namelen; i++)
		{
			if (name[i] != '_')
				tempname[j++] = name[i];
		}
	}

NB: This is just a concept. It should check for (namelen > 0) before processing the strings, it should explicitely add trailing '\0' to the tempname buffers and free() the tempname buffer afterwards.

Created attachment 105262 [details] [review]
if glyph name lookup failed, try alternate naming scheme for ligatures

Hi there,

I have finally found time to refine the approach and address the issues I outlined in my previous posts. This new patch works in both ways, i.e. 'fi' -> 'f_i' and 'f_i' -> 'fi' and takes the glyph name length into account. I have restricted it to 2 >= length >= 7, because we expect something in the range between 'fi' and 'o_f_f_i'.

 - Fabian

Maybe the code would be faster if I replaced *newname with newname[14].

Any comments?

Created attachment 106357 [details] [review]
if glyph name lookup failed, try alternate naming scheme for ligatures

> Maybe the code would be faster if I replaced *newname with newname[14].

Well, here it is. Also, I have simplified "glyph name contains no underscores" loop a bit.

Created attachment 106593 [details] [review]
map standard and expert ligatures to aglfn names

The problem is with the TeX Gyre Hermes fonts. It is claiming to be a drop in replacement for the Standard 14 fonts but it is using names that are not compatible with Standard 14.

It does not matter that Adobe is recommending different names for new fonts. If TeX Gyre Hermes wants to be a replacement for the Standard 14 is has to provide the same encoding as defined in ISO32000 Annex D and PS Lang Ref Appendix E. There is no reason why the TeX fonts can't include both encodings. There are only five affected glyphs so it would only be a few extra bytes added to the fonts.

We can patch poppler to add the mapping for the ligatures but there is likely to be other software that depends on the PDF/PS standard names. So the best fix would be for TeX Gyre Hermes to support both names.

I don't agree with the patches that implement a generic two way mapping. The only affected glyphs are "fi" and "fl" in the Standard encoding and "ff", "ffi", and "ffl" in the Expert encoding. PDFs that are using other ligatures will have the fonts embedded since the Standard 14 fonts won't have these other ligatures. The patches are also missing support for the splash backend.

I am attaching a new patch that maps the five ligatures in both the cairo and splash backends.

Errr, which ppdf do i use to test this? I can't find any attached or linked here.

The link is in the fontconfig bug:

http://www.cs.dartmouth.edu/~doug/mdmspe.pdf

Sorry to be the stupid guy around, but this bug description kind of leaves a bit to be desired in the "how to reproduce" and "what is wrong".

So can someone please tell me "what is wrong" with that pdf, i see rendering fine, text search works etc.

Do i need some extra step? I see "TeX Gyre fonts" being mentioned but the file doesn't seem to use them. Is this for people that somehow are using those fonts as replacements in their fontconfig?

> Is this for people that somehow are using those fonts as replacements in their fontconfig?

Exact. You need to tell fontconfig to prefer TeX Gyre Termes for rendering text that was set in Times.

Up to the latest commit to fontconfig GIT, this was the default, which is why the bug was initially assigned to fontconfig itself.

http://cgit.freedesktop.org/fontconfig/tree/conf.d/30-metric-aliases.conf

Just pushed Adrian's patch.

Finally, thank you so much!